Идеи системного подхода и их реализация в объектно-ориентированной методологии являются естественной базой современного проектирования и управления сложными системами. Такие понятия как сложная система, структура, состояние, иерархия, событие, пришедшие из системотехники, дополненные понятиями класса, объекта, атрибута, инкапсуляции, отношений обобщения, агрегации и др. стали основой парадигмы объектно-ориентированного проектирования (ООП), широко используемого в современных автоматизированных системах. Идеи ООП воплощены в основных языках, составляющих лингвистическое обеспечение CALS, таких как Express, или UML.
Среди языков, используемых в системах CASE на стадии концептуального проектирования сложных систем, господствующее положение в последнее время занял язык Unified Modeling Language (UML). Он был разработан по инициативе компании Rational Software, основные разработчики Гради Буч (Grady Booch), Ивар Якобсон (Ivar Jacobson) и Джим Рамбо (Jim Rumbaugh). Язык UML поддерживается и развивается консорциумом OMG (Object Management Group), первую версию языка (UML 1.0) OMG выпустила в 1997 г.
Язык UML предназначен для описания, визуализации и документирования объектно-ориентированных систем в процессе их разработки, в первую очередь, программного обеспечения систем.
Разработка модели приложения с помощью языка UML начинается с построения диаграмм использования (use case diagram). Эти диаграммы характеризуют функциональность создаваемой системы с позиций пользователя и служат для отображения взаимодействия пользователей с проектируемой системой. В диаграммах в виде овалов представлены варианты использования, т.е. те функции, которые должна выполнять система (рис. 1). Пользователи изображаются в виде стилизованных фигурок, ими могут быть не только люди, но и любые внешние образования, пользующиеся услугами проектируемой системы. Благодаря диаграммам использования, определяется и согласовывается внешняя функциональность системы и в итоге формируется техническое задание на разработку этой системы
Рис. 1.  Фрагмент диаграммы использования
Далее разрабатываются диаграммы взаимодействия "пользователь-система", при этом выявляются необходимые объекты приложения, строятся диаграммы классов, формируется компонентная структура ПО.
Для изображения классов ООП используют прямоугольники, которые разделяются на секции. В верхней секции записывают имя класса, в средней секции — атрибуты класса и в нижней секции — процедуры класса, как это сделано в примере на рис. 2. Знаки +, - или # ставится перед именем атрибута или метода, если элемент имеет статус соответственно public, private или protected.
Рис. 2.  Пример изображения класса
Классы и их отношения составляют сущность диаграмм классов (class diagram). Связи (ассоциации) в этих диаграммах показывают линиями между связанными классами, причем у концов линии можно указать характер отношения ("один — к одному", "один — ко многим" и т.п.). Отношения зависимости (влияния одного класса на другой, зависимость можно обнаружить по изменению описания подчиненного элемента, если изменяется описание влияющего элемента) изображают стрелкой с пунктирной линией, направленной к зависимому элементу. Если отношением связаны равноправные элементы, то такая ассоциация изображается сплошной линией, если отношением связано более двух классов, то в диаграмму добавляется ромбовидная связка, как показано на рис. 3,а.
Рис. 3.  Отношения тернарной ассоциации (а), агрегирования и наследования (б) в диаграммах классов
Частные случаи ассоциаций — обобщение и агрегирование. Отношение обобщения (наследования) изображают сплошной линией, заканчивающейся незакрашенной стрелкой около родительского элемента. Отношение агрегирования (отношение "часть — целое") показывают такой же линией, но с ромбовидной стрелкой, заканчивающейся у элемента "целое". Ромбовидная стрелка закрашивается, если части не могут существовать без целого, т.е. если при ликвидации класса "целое" ликвидируются и все его "части". Отметим, что в этом случае отношение агрегирования иногда называют отношением композиции.
Пример фрагмента диаграммы классов с отношениями обобщения и агрегирования приведен на рис. 3,б.
На основе диаграмм классов можно в дальнейшем получить имитационную модель описываемого приложения на терминальном объектно-ориентированном языке программирования.
Диаграммы взаимодействия объектов (interaction diagrams) относятся к диаграммам процессов, отражающим поведенческий аспект моделирования. Диаграммы взаимодействия представлены диаграммами последовательностей и кооперации. Кроме них, к диаграммам процессов относятся диаграммы состояний и деятельности.
В диаграммах последовательностей (sequence diagram), называемых также диаграммами сценариев, отражается последовательность событий, заключающихся в воздействиях одного объекта на некоторый другой объект. В этих диаграммах объекты изображаются прямоугольниками и располагаются каждый в своей вертикальной колонке диаграммы. Ось времени направлена вертикально вниз. От каждого объекта параллельно оси времени идут так называемые их линии жизни. Каждое событие изображается горизонтальной линией со стрелкой от линии жизни объекта, посылающего сообщение, к линии жизни объекта, принимающего сообщение. Над этими линиями возможен поясняющий текст. Линии располагаются одна над другой в порядке, в котором события совершаются. Пример диаграммы сценариев дан на рис. 4, где прямоугольники объектов расположены в верхней части своих колонок.
Следует отметить, что в диаграммах взаимодействия фигурируют объекты, а не классы, что отмечается подчеркиванием имени объекта внутри прямоугольника объекта (на рис. 4 имена не показаны).
Рис. 4.  Вид диаграммы сценариев
В диаграммах кооперации (collaboration diagram) объекты, представленные прямоугольниками, связаны между собой линиями, изображающими сообщения (поток управления). Сообщения упорядочены по времени появления. Около линии указываются порядковый номер сообщения, направление потока и, возможно, некоторые другие пояснения.
Диаграмма состояний (statechart diagram) представляет собой граф перехода состояний, известный по использованию во многих приложениях, но изображаемый по правилам языка UML. С помощью диаграммы состояний моделируется последовательность событий, происходящих в системе.
Вершины графа перехода состояний соответствуют состояниям и в UML изображаются прямоугольниками с указанием внутри прямоугольников имен состояний и, возможно, списков внутренних действий, допустимых в данном состоянии. Дуги графа соответствуют переходам из одного состояния в другое и изображаются линиями с обычными стрелками. Около линии может быть записано имя события и (или) указаны действия, выполняемые при переходе. Переход срабатывает после выполнения внутренних действий соответствующего состояния. После имени события можно в прямых скобках записать так называемое сторожевое условие — булево выражение . Переход может сработать только, если выражение принимает значение .
Диаграммы деятельности (activity diagram) близки по своей семантике к диаграммам состояний. Отличаются они тем, что каждой вершине графа соответствует некоторое элементарное действие и переход в новое состояние происходит по завершении этого действия. Вершины изображаются прямоугольниками с округлыми боковыми сторонами, переходы — линиями с обычными стрелками, переходы из нескольких вершин в одну последующую (переходы типа слияния — join) или из одной вершины в несколько последующих (переходы типа разделения — fork) — утолщенными короткими линиями так же, как изображаются переходы в сетях Петри. Переход по условию в одну из альтернативных вершин изображается с помощью ромба, из которого выходят дуги переходов к альтернативным вершинам.
В UML используются также диаграммы компонентов (Component Diagram). и развертывания (Deployment Diagram), используемые для моделирования физической организации системы. Например, к компонентам программной системы могут относиться программные модули, библиотеки, файлы. В диаграммах развертывания показывают распределение классов по аппаратным средствам.
Примером программной системы, поддерживающей язык UML, является система Rational Rose компании Rational Software.