История создания UML

Разработка UML началась в октябре 1994 года, когда Гради Буч и Jim Rumbaugh из Rational Software Corporation приступили к совместной работе по унифицированию методов Booch и OMT (Object Modeling Technique). Оба метода развивались независимо друг от друга и были по праву названы одними из лучших методов объектно-ориентированного подхода при разработке программных систем. Было принято решение об объединении этих двух методов, и в октябре 1995 вышла бета-версия, которая получила название Unified Method.

К концу 1996 года выяснилось, что ряд крупных компаний готовы рассмотреть UML в качестве основной стратегии своего бизнеса. Был создан некоммерческий консорциум OMG (Object Modeling Group), который объединил таких ведущих производителей ПО, как DEC, HP, IBM, Microsoft, Oracle, Rational Software и др. В январе 1997 был выдан UML 1.0. Вскоре к OMG примкнули такие компании, как IBM, Objectime, Platinum Technology и Softeam. Как результат этого сотрудничества появилась версия UML 1.1. В 2003 была принята версия 1.5. 2004 г. – принята версия 2.0

Структура UML

UML (сокр. от англ. Unified Modeling Language - унифицированный язык моделирования) - язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт использующий графические обозначения для создания абстрактной модели системы, которая называется UML моделью. UML был создан для определения, визуализации, проектирования и документирования по большей части программных систем.

UML обеспечивает разработку репрезентативных моделей для организации взаимодействия заказчика и разработчика ИС, различных групп разработчиков ИС.

Прежде всего, UML наследует техники Booch, OMT и OOSE.

Во-вторых, перекрывает их.

В-третьих, надо отметить, что UML - это стандарт языка, а не стандарт процесса.

Язык UML включает набор графических элементов, используемых на диаграммах. Будучи языком, UML содержит правила для объединения этих элементов. Диаграммы используются для отображения различных представлений системы. Этот набор различных представлений называется моделью. Модель UML описывает, что должна будет делать система. В то же время, ничего не сообщается о том, как она будет реализована.

С самой общей точки зрения описание языка UML состоит из двух взаимодействующих частей, таких как:

Семантика языка UML . Она представляет собой некоторую метамодель, которая определяет абстрактный синтаксис и семантику понятий объектного моделирования на языке UML.

Нотация языка UML . Она представляет собой графическую нотацию для визуального представления семантики языка UML.

Диаграммы UML

Перейдем теперь к обзору графической нотации UML. Графическая нотация - это отображение визуального представления в семантику языка. Как упоминалось ранее, UML является квинтэссенцией трех техник моделирования, и, по существу, наследует их графическую нотацию, отвергая малоиспользуемые и невыразительные элементы и добавляя новые, отвечающие запросам современного рынка программных систем. При создании UML старались сохранить баланс между простотой, понятностью языка и его выразительной мощью и точностью. Модель разрабатываемой системы являет собой совокупность взаимосвязанных подмоделей, каждая из которых описывается набором диаграмм, описанных с помощью определенной в UML графической нотации.

Проект, создаваемый с помощью языка UML 1.x, может включать в себя следующие диаграммы (сгруппированы в соответствии с их предназначением). Таких диаграмм насчитывается восемь :

· Диаграмма вариантов (прецедентов) использования (use case diagram)

· Диаграмма классов (class diagram)

· Диаграммы поведения (behavior diagrams)

o Диаграмма состояний (statechart diagram)

o Диаграмма активности (activity diagram)

o Диаграммы взаимодействия (interaction diagrams)

§ Диаграмма последовательности (sequence diagram)

§ Диаграмма кооперации (collaboration diagram)

· Диаграммы реализации (implementation diagrams)

o Диаграмма компонентов (component diagram)

o Диаграмма размещения (развертывания) (deployment diagram)

3.1. Диаграмма вариантов (прецедентов) использования (use case diagram)

Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. «Каждая функциональность» изображается в виде «прецедентов использования» (use case) или просто прецедентов. Прецедент - это типичное взаимодействие пользователя с системой, которое при этом:

описывает видимую пользователем функцию,

может представлять различные уровни детализации,

обеспечивает достижение конкретной цели, важной для пользователя.

Прецедент обозначается на диаграмме овалом, связанным с пользователями, которых принято называть действующими лицами (актерами, actors). Действующие лица используют систему (или используются системой) в данном прецеденте. Действующее лицо выполняет некоторую роль в данном прецеденте. На диаграмме изображается только одно действующее лицо, однако реальных пользователей, выступающих в данной роли по отношению к ИС, может быть много. Список всех прецедентов фактически определяет функциональные требования к ИС, которые лежат в основе разработки технического задания на создание системы.

На диаграммах прецедентов, кроме связей между действующими лицами и прецедентами, возможно использование еще двух видов связей между прецедентами: «использование» и «расширение» (рис. 3.1.1). Связь типа «расширение» применяется, когда один прецедент подобен другому, но несет несколько большую функциональную нагрузку. Ее следует применять при описании изменений в нормальном поведении системы. Связь типа «использование» позволяет выделить некий фрагмент поведения системы и включать его в различные прецеденты без повторного описания.

UML – это унифицированный графический язык моделирования для описания, визуализации, проектирования и документирования ОО систем. UML призван поддерживать процесс моделирования ПС на основе ОО подхода, организовывать взаимосвязь концептуальных и программных понятий, отражать проблемы масштабирования сложных систем. Модели на UML используются на всех этапах жизненного цикла ПС, начиная с бизнес-анализа и заканчивая сопровождением системы. Разные организации могут применять UML по своему усмотрению в зависимости от своих проблемных областей и используемых технологий.

Краткая история UML

К середине 90-х годов различными авторами было предложено несколько десятков методов ОО моделирования, каждый из которых использовал свою графическую нотацию. При этом любой их этих методов имел свои сильные стороны, но не позволял построить достаточно полную модель ПС, показать ее «со всех сторон», то есть, все необходимые проекции (См. статью 1). К тому же отсутствие стандарта ОО моделирования затрудняло для разработчиков выбор наиболее подходящего метода, что препятствовало широкому распространению ОО подхода к разработке ПС.

По запросу Object Management Group (OMG) – организации, ответственной за принятие стандартов в области объектных технологий и баз данных назревшая проблема унификации и стандартизации была решена авторами трех наиболее популярных ОО методов – Г.Бучем, Д.Рамбо и А.Джекобсоном, которые объединенными усилиями создали версию UML 1.1, утвержденную OMG в 1997 году в качестве стандарта.

UML – это язык

Любой язык состоит из словаря и правил комбинирования слов для получения осмысленных конструкций. Так, в частности, устроены языки программирования, таковым является и UML. Отличительной его особенностью является то, что словарь языка образуют графические элементы. Каждому графическому символу соответствует конкретная семантика, поэтому модель, созданная одним разработчиком, может однозначно быть понята другим, а также программным средством, интерпретирующим UML. Отсюда, в частности, следует, что модель ПС, представленная на UML, может автоматически быть переведена на ОО язык программирования (такой, как Java, C++, VisualBasic), то есть, при наличии хорошего инструментального средства визуального моделирования, поддерживающего UML, построив модель, мы получим и заготовку программного кода, соответствующего этой модели.

Следует подчеркнуть, что UML – это именно язык, а не метод. Он объясняет, из каких элементов создавать модели и как их читать, но ничего не говорит о том, какие модели и в каких случаях следует разрабатывать. Чтобы создать метод на базе UML, надо дополнить его описанием процесса разработки ПС. Примером такого процесса является Rational Unified Process, который будет рассматриваться в последующих статьях.

Словарь UML

Модель представляется в виде сущностей и отношений между ними, которые показываются на диаграммах.

Сущности – это абстракции, являющиеся основными элементами моделей. Имеется четыре типа сущностей – структурные (класс, интерфейс, компонент, вариант использования, кооперация, узел), поведенческие (взаимодействие, состояние), группирующие (пакеты) и аннотационные (комментарии). Каждый вид сущностей имеет свое графическое представление. Сущности будут подробно рассмотрены при изучении диаграмм.

Отношения показывают различные связи между сущностями. В UML определены следующие типы отношений:

• Зависимость показывает такую связь между двумя сущностями, когда изменение одной из них – независимой – может повлиять на семантику другой – зависимой. Зависимость изображается пунктирной стрелкой, направленной от зависимой сущности к независимой.
• Ассоциация – это структурное отношение, показывающее, что объекты одной сущности связаны с объектами другой. Графически ассоциация показывается в виде линии, соединяющей связываемые сущности. Ассоциации служат для осуществления навигации между объектами. Например, ассоциация между классами «Заказ» и «Товар» может быть использована для нахождения всех товаров, указанных в конкретном заказе – с одной стороны, или для нахождения всех заказов в которых есть данный товар, – с другой. Понятно, что в соответствующих программах должен быть реализован механизм, обеспечивающий такую навигацию. Если требуется навигация только в одном направлении, оно показывается стрелкой на конце ассоциации. Частным случаем ассоциации является агрегирование – отношение вида «целое» – «часть». Графически оно выделяется с помощью ромбика на конце около сущности-целого.
• Обобщение – это отношение между сущностью-родителем и сущностью-потомком. По существу, это отношение отражает свойство наследования для классов и объектов. Обобщение показывается в виде линии, заканчивающейся треугольничком направленным к родительской сущности. Потомок наследует структуру (атрибуты) и поведение (методы) родителя, но в то же время он может иметь новые элементы структуры и новые методы. UML допускает множественное наследование, когда сущность связана более чем с одной родительской сущностью.
• Реализация – отношение между сущностью, определяющей спецификацию поведения (интерфейс) с сущностью, определяющей реализацию этого поведения (класс, компонент). Это отношение обычно используется при моделировании компонент и будет подробнее описано в последующих статьях.

Диаграммы. В UML предусмотрены следующие диаграммы:

• Диаграммы, описывающие поведение системы:
• Диаграммы состояний (State diagrams),
• Диаграммы деятельностей (Activity diagrams),
• Диаграммы объектов (Object diagrams),
• Диаграммы последовательностей (Sequence diagrams),
• Диаграммы взаимодействия (Collaboration diagrams);
• Диаграммы, описывающие физическую реализацию системы:
• Диаграммы компонент (Component diagrams);
• Диаграммы развертывания (Deployment diagrams).

Представление управления моделью. Пакеты.

Мы уже говорили о том, что для того чтобы модель была хорошо понимаемой человеком необходимо организовать ее иерархически, оставляя на каждом уровне иерархии небольшое число сущностей. UML включает средство организации иерархического представления модели – пакеты. Любая модель состоит из набора пакетов, которые могут содержать классы, варианты использования и прочие сущности и диаграммы. Пакет может включать другие пакеты, что позволяет создавать иерархии. В UML не предусмотрено отдельных диаграмм пакетов, но они могут присутствовать на других диаграммах. Пакет изображается в виде прямоугольника с закладкой.

Что обеспечивает UML.

• иерархическое описание сложной системы путем выделения пакетов;
• формализацию функциональных требований к системе с помощью аппарата вариантов использования;
• детализацию требований к системе путем построения диаграмм деятельностей и сценариев;
• выделение классов данных и построение концептуальной модели данных в виде диаграмм классов;
• выделение классов, описывающих пользовательский интерфейс, и создание схемы навигации экранов;
• описание процессов взаимодействия объектов при выполнении системных функций;
• описание поведения объектов в виде диаграмм деятельностей и состояний;
• описание программных компонент и их взаимодействия через интерфейсы;
• описание физической архитектуры системы.

И последнее…

Несмотря на всю привлекательность UML, его было бы затруднительно использовать при реальном моделировании ПС без инструментальных средств визуального моделирования. Такие средства позволяют оперативно представлять диаграммы на экране дисплея, документировать их, генерировать заготовки программных кодов на различных ОО языках программирования, создавать схемы баз данных. Большинство из них включают возможности реинжиниринга программных кодов – восстановления определенных проекций модели ПС путем автоматического анализа исходных кодов программ, что очень важно для обеспечения соответствия модели и кодов и при проектировании систем, наследующих функциональность систем-предшественников.

Создавать для программы дополнительное визуальное и документальное сопровождение – процесс трудоемкий и утомительный: отнимает много времени и кажется совершенно излишним, если архитектура программного обеспечения проста или является эталонной. Однако на практике программисты далеко не всегда сталкиваются с такими задачами.

Почему не «взлетел» UML

В большинстве случаев при разработке программного обеспечения, если система требует правок, то программисты просто берут код и исправляют ошибки так, как им удобно, а затем демонстрируют результат заказчику.

«Сегодня программирование - это не инженерная наука, а прикладная математика. При этом программисты сразу учатся писать код», - уточняет заведующий кафедрой Технологии программирования Университета ИТМО Анатолий Шалыто.

Чаще всего архитектура решения объясняется на словах или с применением простейших блок-диаграмм. Универсальный язык моделирования (UML), основанный на базе нескольких предыдущих стандартов, таких как метод Гради Буча (Booch), метод Джима Румбаха (OMT) и метод Айвара Джекобсона (OOSE), должен был помочь в этом вопросе. И на него возлагали определенные надежды.

Люди пробовали работать с UML, надеясь, что тот станет своеобразной «серебряной пулей», однако он не приобрел широкой популярности. Исследователи выделяют три главных препятствия, которые помешали массовому распространению диаграмм состояний в качестве общепринятого средства описания алгоритмов и сложных поведений программ.

Во-первых, для описания поведения, кроме диаграмм состояний, предлагалось использовать и другие типы диаграмм, однако правила, определяющие их взаимодействие, не были регламентированы.

«Многие считают, что этот язык слишком объемный, - говорит исследователь и предприниматель Хорди Кабот (Jordi Cabot). - Это связано с большим количеством диаграмм, доступных в UML».

Во-вторых, не было предложено подходов для совместного использования диаграмм, описывающих структуру и поведение программ. В-третьих, диаграммы для описания поведения в основном использовались разработчиками для общения друг с другом, в то время как назначение UML - составление спецификации с последующим её воплощением в программном коде.

Подобная судьба ожидала и множество других решений, которые, однако, не являются полноценными альтернативами UML. Речь идет о системе условных обозначений для моделирования бизнес-процессов (BPMN), моделях сущность-связь (ERM), диаграммах потоков данных (DFD), диаграммах состояний и др. Как отмечает Крис Фурман (Cris Fuhrman), все это не более, чем инструменты общения.

Переход к автоматам

Однако спецификации проектов нужны, поскольку они фиксируют результат процесса проектирования, освобождая ум разработчика для решения других задач, а также используются в качестве входных данных на этапе реализации.

Этапы разработки программной системы со сложным поведением

Автоматное программирование является подходом, способным облегчить процесс формирования спецификации. Во время работы создаются графы, в которых под влиянием внешних или любых других входных воздействий осуществляются переходы между состояниями и формируются выходные «импульсы». Для этого сперва формируется текстовая версия технического задания, в котором заказчик прописывает подробную работу желаемого решения.

После этого объявляются условные обозначения входных и выходных воздействий, источников и приемников информации, а затем рисуется схема. Графы переходов позволяют заказчику лучше понять то, что будет делать программист.

Имея схему связей и диаграмму переходов, с помощью формального преобразования можно построить код, реализующий автомат на языке программирования. После этого спецификации становятся частью проектной документации системы. Проектная документация составляется на естественном языке и обычно содержит постановку задачи, описание структуры и поведения системы, примеры ее использования.

Автоматное описание в ООП

Принципы автоматного подхода находят применение и в объектно-ориентированном программировании. Это возможно благодаря концепции «автоматы и объекты управления как классы». Такая модель принята, например, в инструментальном средстве автоматного программирования UniMod. Архитектура системы со сложным поведением, построенная согласно этому принципу представлена на рисунке ниже.

Сопоставление отдельного класса каждому объекту управления приводит к тому, что усилия разработчиков по выделению этих объектов на стадии моделирования не пропадают на этапе реализации. При этом каждый запрос или команда имеет доступ только к строго определенной части вычислительного состояния.

В целом же процесс проектирования системы со сложным поведением можно описать следующим образом:

1. Проведение объектной декомпозиции, когда система разбивается на множество самостоятельных взаимодействующих сущностей.
2. Сопоставление сущностей с классами, определение интерфейсов классов и отношений.
3. Выделение тех сущностей, которые обладают сложным поведением, - именно для их описания будет применяться автоматный подход.
4. Задание набора управляющих состояний для каждой сущности. Запросы и команды сопоставляются с входными и выходными переменными управляющего автомата, а компоненты интерфейса - с его событиями. На их основе строится сам управляющий автомат.
5. Реализация неавтоматизированных классов на выбранном объектно-ориентированном языке. Генерация кода может выполняться как автоматически, так и вручную.

Этот алгоритм не ограничивает программиста в выборе модели процесса разработки (водопадная, итеративная, кластерная и т. д.) и легко модифицируется в многоитерационный. При этом он также позволяет вносить изменения в уже существующую объектно-ориентированную систему и не требует проведения разработки «с чистого листа».

Язык Unified Modelling Language (UML) можно считать результатом довольно длинной и еще не завершившейся эволюции методологий моделирования и дизайна.

В 90-х годах наиболее популярными были три объектно-ориентированных подхода:

В результате соперничества этих методов авторы вышеперечисленных методологий создали унифицированный язык моделирования UML (рис. 1), который унаследовал присутствовавшие в других языках элементы. Далее приведена оригинальная терминология заимствованных/унаследованных элементов языка этой методологии - дело в том, что сейчас существует несколько вариантов переводов этих терминов на русский язык.

Рис. 1. UML и его предшественники

Данная унификация преследовала три основные цели:

Моделирование системы, начиная с концепции и заканчивая исполняемым модулем, с применением объектно-ориентированных методик;

Разрешение проблем масштабирования в сложных системах;

Создание языка моделирования, используемого и человеком, и компьютером.

Официальной датой начала работ по UML считают октябрь 1994 года, когда Рамбо перешел в компанию Rational (ныне Rational - одно из подразделений корпорации IBM). Последним стандартом этого языка является версия UML1.3, вышедшая в 1999 году.

Средства UML-моделирования

Является ли UML необходимым компонентом RUP? Да, безусловно. Но практика использования UML как средства описания процесса моделирования и разработки программного обеспечения не ограничивается RUP. Как и любой другой язык, UML - это всего только средство. В RUP предусмотрен ряд утилит, позволяющих довольно легко использовать UML, но их набор не ограничивается лишь продуктами IBM/Rational. Ниже приводится далеко не полный список некоторых продуктов, поддерживающих UML:

Rational Rose (Rational Software, Windows 98/NT/2000/XP, Linux Red Hat 6.2, 7.0, Solaris 2.5.1, 2.6, 7, 8, HP-UX 10.20, 11.0, 11.i);

Microsoft Visual Studio .NET Enterprise Architect, Microsoft Visio (Microsoft, платформы: Windows 98/NT/2000/XP/Server 2003);

Describe Enterprise (Embarcadero technologies, платформы: Windows 98/NT/2000/XP);

Семейство продуктов Together (Borland, платформы: Windows 98/NT/2000/XP, Linux, Solaris);

Bold for Delphi (Borland, платформы: Windows 98/NT/2000/XP);

MagicDraw (Magic, Inc., платформы: Windows 98/Me/NT/2000/XP, Solaris, OS/2, Linux, HP-UX, AIX, Mac OS);

QuickUML (ExcelSoftware, платформы: Windows 98/NT/2000/XP) - неплохая утилита для начинающих.

Отметим также некоторые продукты OpenSourse, например ArgoUML, Novosoft UML Library.

Документ, который содержит списки продуктов, поддерживающих UML, компаний-производителей, платформ, а также информацию о примерных ценах продуктов, можно найти по адресу: http://www.objectsbydesign.com/tools/umltools_byCompany.html .

Следует также отметить, что, несмотря на факт существования стандарта UML 1.3, поддерживаемые перечисленными продуктами реализации UML или обладают собственными особенностями, или не полностью следуют стандарту, поэтому при выборе средства моделирования следует обращать внимание на поддерживаемые типы диаграмм и особенности синтаксиса. Кроме того, возможности прямого и обратного проектирования (Round-Trip Engineering) в разных продуктах весьма различны. Не все вышеуказанные продукты могут поддерживать языки программирования Java, C++, CORBA IDL, поэтому следует обращать особое внимание на то, какую модель сможет сгенерировать тот или иной продукт из имеющегося у вас кода, на каком языке может быть получен код из вашей UML-модели и какого она должна быть типа.

Таблица, показывающая, какие диаграммы UML реализованы в том или ином продукте, находится по адресу: http://www.jeckle.de/umltools.htm .

Для чего применяется UML

UML — прежде всего язык, и, как всякое языковое средство, он предоставляет словарь и правила комбинирования слов в этом словаре. В данном случае словарь и правила фокусируются на концептуальном и физическом представлениях системы. Язык диктует, как создать и прочитать модель, однако не содержит никаких рекомендаций о том, какую модель системы необходимо создать, — это выходит за рамки UML и является прерогативой процесса разработки программного обеспечения. В связи с этим, видимо, UML довольно часто ассоциируют с RUP — одним из возможных процессов, рекомендующих, какие модели, как и когда нужно создавать для успешной разработки продукта.

UML — это язык визуализации. Написание моделей на UML преследует одну простую цель — облегчение процесса передачи информации о системе. За каждым символом UML стоит строго определенная семантика, что позволяет избегать ошибок интерпретации (ответы на вопросы типа «а что имел в виду разработчик Х, когда он описал иерархию классов Y…» и т.п. будут достаточно прозрачны).

UML — это язык спецификаций и точных определений. В этом смысле моделирование на UML означает построение моделей, которые точны, недвусмысленны и полны.

UML — это язык конструирования. UML не является визуальным языком программирования, но модели в терминах UML могут быть отображены на определенный набор объектно-ориентированных языков программирования. UML предоставляет возможности прямого (существующая модель ® новый код) и обратного (существующий код ® новая модель) проектирования. Достаточно часто средства UML-моделирования реализуют отображения UML-моделей в коде на языках Java, C++, CORBA, VB, Smalltalk.

UML — это язык документирования. Процесс разработки программного обеспечения предусматривает не только написание кода, но и создание таких артефактов, как список требований, описание архитектуры, дизайн, исходный код системы, планирование проекта, тесты, набор прототипов, релизы продукта. В зависимости от культуры разработки продукта в той или иной компании степень формализации данных документов существенно различается, варьируясь от строго определенных шаблонов и формата документов до разговоров на произвольную тему по e-mail или лично. Тем не менее все эти артефакты критичны для успешного процесса разработки продукта. UML предоставляет средства отображения требований к системе, построения документации, тестов, моделирования необходимых действий для планирования проекта и для управления поставленными конечному пользователю релизами.

Элементы языка

Основными элементами UML являются сущности (Thing), отношения (Relationship), диаграммы (Diagram). Сущности являются ключевыми абстракциями языка, отношения связывают сущности вместе, диаграммы группируют коллекции сущностей, которые представляют интерес.

Сущности

Структурные сущности являются существительными языка (рис. 2). К ним относятся:

классы (Class) — это набор объектов, разделяющих одни и те же атрибуты, операции, отношения и семантику. Класс реализует один или несколько интерфейсов и изображается виде прямоугольника, включающего имя класса, имена атрибутов, операций, примечание;

интерфейсы (Interface) — это набор операций, которые определяют сервис класса или компоненты. Интерфейс графически изображается в виде круга и, как правило, присоединяется к классу или к компоненту, который реализует данный интерфейс;

кооперации (Collaboration) — определяют взаимодействие и служат для объединения ролей и других элементов, которые взаимодействуют вместе так, что получающееся в результате поведение объекта оказывается большим, чем просто сумма всех элементов. Изображается в виде эллипса с пунктирной границей;

Прецеденты (Use case) — описание набора последовательностей действий, которые выполняются системой и имеют значение для конкретного действующего лица (Actor). Прецеденты изображаются в виде эллипса и используются для структурирования поведенческих сущностей в модели;

активные классы (Active class) — это классы, чьими экземплярами являются активные объекты, которые владеют процессом или потоком управления и могут инициировать управляющее воздействие. Стереотипами конкретного класса являются процесс (Process) и поток (Thread). Графически такой класс изображается как класс с жирной границей;

компоненты (Component) — это физически заменяемые части системы, обеспечивающие реализацию ряда интерфейсов. Компонент — это физическое представление таких логических элементов, как классы, интерфейсы и кооперации. Предметная область компонентов относится к реализации. Изображаются компоненты в виде прямоугольника с ярлыками слева и, как правило, имеют только имя и примечание;

узлы (Node) — физические объекты, которые существуют во время исполнения программы и представляют собой коммуникационный ресурс, обладающий, по крайней мере, памятью, а зачастую и процессором. На узлах могут находиться выполняемые объекты и компоненты. Изображаются узлы в виде куба, имеют имя и примечание.

Данные перечисленных семи типов объектов являются базовыми структурными объектами UML. Существуют также вариации данных объектов, такие как действующие лица (Actor), сигналы (Signal), утилиты (Utility - вид класса), процессы и нити (Process и Thread - виды активного класса), приложения (Application), документы (document), файлы (File), библиотеки (Library), страницы (Page), таблицы (Table).

Поведенческие сущности — это динамические части моделей UML (рис. 3). К ним относятся:

взаимодействия (Interaction) — включают набор сообщений, которыми обмениваются указанные объекты с целью достижения указанной цели. Взаимодействие описывается в контексте кооперации и изображается направленной линией, маркируется именем операции сверху;

автоматы (State machine) — спецификации поведения, представляющие собой последовательности состояний, через которые проходит в течение своей жизни объект, или взаимодействие в ответ на происходящие события (а также ответные действия объекта на эти события). Автомат прикреплен к исходному элементу (классу, кооперации или методу) и служит для определения поведения его экземпляров. Изображается автомат как прямоугольник с закругленными углами.

Группирующие сущности — это организационные составляющие моделей UML. К ним относятся пакеты (Package) — обобщенный механизм для организации элементов в группы. Структурные, поведенческие, группирующие сущности могут быть помещены в пакет. Пакеты являются чисто концептуальными сущностями — в отличие от компонентов, существующих во время исполнения программы. Изображается пакет как папка с ярлыком сверху и, как правило, имеет только имя.

Аннотационные сущности — это пояснительные составляющие моделей UML, к которым относятся примечания (Note) — пояснительные элементы языка (рис. 4). Они содержат текст комментария, изображаются в виде прямоугольника с загнутым уголком страницы.

Отношения

К базовым отношениям между объектами, которые позволяют строить блоки UML, можно отнести следующие (рис. 5):

зависимость (Dependency) — это семантическое отношение между двумя сущностями, при котором изменение одной из них (независимой сущности) может отразиться на семантике другой (зависимой). Виды зависимостей, которые соответствуют нескольким видам отношений между объектами, перечислены ниже:

- абстракция (Abstraction) — представляет собой изменение уровня абстрактности для некоторого понятия. Как правило, один из элементов, более абстрактный, а второй — более конкретный, хотя возможны ситуации, когда оба элемента являются двумя возможными вариантами понятия, существующими на одном уровне абстракции. К зависимости абстракции относятся следующие стереотипы (в порядке возрастания специфичности отношений): трассировать (Trace), уточнять (Refine), реализовать (есть собственная нотация) и выводить (Derive),

- связывание (Binding) — связывает элемент с шаблоном. Аргументы, необходимые для параметров шаблона, прикреплены к зависимости связывания в виде списка,

- комбинирование (Combination) — соотносит две части описания классификатора (любой элемент модели, описывающий определенные черты структуры и поведения системы), чтобы получить полное описание элемента,

- разрешение (Permission) — зависимость (всегда изображается в виде особого стереотипа), связывающая тот или иной пакет (или класс) с другим пакетом (или классом), которому он предоставляет разрешение использовать свое содержимое. Стереотипами зависимости разрешения являются: быть доступным (Access), быть дружественным (Friend) и импортировать (Import),

- использование (Usage) — описывает ситуацию, когда одному элементу для правильной реализации или функционирования требуется присутствие другого элемента. К стереотипам этого вида зависимости относятся: вызывать (Call), создать экземпляр (Instantiate), параметр (Parameter) и отправить (Send);

ассоциация (Association) — структурное отношение, описывающее множество связей между объектами классификаторов, где связь (Link) — это соединение между объектами, которое описывает связи между их экземплярами. Ассоциации являются как бы клеем, который связывает систему воедино. Без ассоциаций мы имели бы просто некоторое количество классов, не способных взаимодействовать друг с другом. У ассоциации может быть имя, однако основную информацию об ассоциации следует искать у ее полюсов, где описывается, каким образом каждый объект участвует в ассоциации: у ассоциации есть список, состоящий из двух или более полюсов ассоциации: каждый из них определяет роль, которую играет данный классификатор в этой ассоциации. Один и тот же классификатор может играть несколько ролей, которые не являются взаимозаменяемыми. Каждый полюс ассоциации описывает свойства, применимые к конкретному объекту этой ассоциации, например сколько раз один объект может появляться в связях (множественность). Некоторые свойства (такие как допустимость навигации) применимы только к бинарным ассоциациям, хотя большинство свойств относится и к бинарным, и к n-арным ассоциациям;

обобщение (Generalization) — это отношение специализации/обобщения, при котором объекты специализированного элемента (потомка — Child) можно подставить вместо объектов обобщенного элемента (родителя, предка — Parent). В случае обобщения классов прямой предок может именоваться суперклассом, а прямой потомок — подклассом;

реализация (Realization) — отношение между спецификацией и ее программной реализацией; указание на то, что поведение наследуется без структуры.

Мы перечислили четыре основных отношения. В UML также существуют их варианты: уточнение (Refinement), трассировка (Trace), включение (Include), расширение (Extend).

Диаграммы UML

Визуализация представления проектируемой системы с различных точек зрения в UML реализована посредством диаграмм - проекций системы. Диаграмма (Diagram) - это графическое представление множества элементов, которое изображается в виде связного графа с вершинами (сущностями) и ребрами (отношениями).

Чаще всего UML рассматривает систему с пяти взаимосвязанных точек зрения (рис. 6).

Представление с точки зрения прецедентов (Use case view) включает пользовательские истории, описывающие систему с точки зрения конечного пользователя, аналитика, тестера. Это представление не определяет структуру программного обеспечения, а существует для передачи общего представления о системе. В UML это отображается посредством диаграмм прецедентов (Use case diagram), динамический аспект представлен в диаграммах взаимодействий (Interaction diagram), состояний (Statechart diagram), активности (Activity diagram).

Представление с точки зрения дизайна (Design view) включает классы, интерфейсы и кооперации, которые формируют словарь задачи и ее решение. Данное представление в первую очередь осуществляет поддержку функциональных требований к системе, значение сервисов, которые система должна предоставить конечному пользователю. В UML это отображается посредством диаграмм классов (Class diagram) и объектов (Object diagram), динамический аспект отображается в диаграммах взаимодействий, состояний, активности.

Представление с точки зрения процессов (Process view) включает нити и процессы, которые формируют параллельную обработку и синхронизацию в системе. Данное представление в первую очередь относится к производительности, масштабируемости и пропускной способности системы. В UML статический и динамический аспекты отображаются теми же диаграммами, что и в Design view, но внимание акцентируется на активных классах, представляющих процессы и нити.

Представление с точки зрения реализации (Implementation view) включает компоненты и файлы, используемые при сборке системы. Подобное представление в первую очередь относится к управлению конфигурациями (Configuration management) релизов продукта. Статический аспект в UML отображен диаграммой компонентов (Component diagram), а динамический - диаграммами взаимодействий, состояний, активности.

Представление с точки зрения внедрения (Deployment view) включает узлы и их взаимодействие - они определяют аппаратную топологию, на которой выполняется программное обеспечение. Это представление в первую очередь относится к распространению, доставке, установке компонентов, из которых строится физическая система. Статический аспект в UML отображается диаграммой внедрения (Deployment diagram), а динамический - диаграммами взаимодействий, состояний, активности.

Ниже приведены определения и примеры диаграмм:

диаграмма классов (Class diagram) — структурная диаграмма, на которой показано множество классов, интерфейсов, коопераций и отношений между ними (рис. 7);

диаграмма объектов (Object diagram) — структурная диаграмма, на которой показано множество объектов и отношений между ними. Ее можно считать особым случаем диаграммы классов. Инструментам моделирования не нужно поддерживать отдельный формат для диаграмм объектов. На них изображены объекты, поэтому диаграмма классов, на которой нет классов, но есть принадлежащие им объекты, может считаться диаграммой объектов;

диаграмма прецедентов (Use case diagram) — диаграмма поведения, на которой показано множество прецедентов и актеров, а также отношений между ними (рис. 8);

диаграммы взаимодействий (Interaction diagram) :

- диаграмма последовательностей (Sequence diagram) — диаграмма поведения, на которой показано взаимодействие и подчеркнута временная последовательность событий (рис. 9),

- диаграмма кооперации (Collaboration diagram) — диаграмма поведения, на которой показано взаимодействие и подчеркнута структурная организация объектов, посылающих и принимающих сообщения (рис. 10);

диаграмма состояний (Statechart diagram) — диаграмма поведения, на которой показан автомат и подчеркнуто поведение объектов с точки зрения порядка получения событий (рис. 11);

диаграмма активности (Activity diagram) — диаграмма поведения, на которой показан автомат и подчеркнуты переходы потока управления от одной деятельности к другой (рис. 12);

диаграмма компонентов (Component diagram) — диаграмма, на которой изображена организация некоторого множества компонентов и зависимости между ними, — относится к статистическому виду системы (рис. 13);

диаграмма топологии системы (Deployment diagram) — структурная диаграмма, на которой показаны узлы и отношения между ними (рис. 14).

Продолжение следует.

Сегодня процесс создания сложных программных приложений невозможно представить без разделения на этапы жизненного цикла. Под жизненным циклом программы будем понимать совокупность этапов:

• Анализ предметной области и создание ТЗ (взаимодействия с заказчиком)
• Проектирование структуры программы
• Кодирование (набор программного кода согласно проектной документации)
• Тестирование и отладка
• Внедрение программы
• Сопровождение программы
• Утилизация

Остановимся детально на процессе проектирования. В ходе проектирования архитектором или опытным программистом создается проектная документация, включающая текстовые описания, диаграммы, модели будущей программы. В этом нелегком деле нам поможет язык UML.

UML - является графическим языком для визуализации, описания параметров, конструирования и документирования различных систем (программ в частности). Диаграммы создаются с помощью специальных CASE средств, например Rational Rose (http://www-01.ibm.com/software/rational/) и Enterprise Architect (http://www.sparxsystems.com.au/). На основе технологии UML строится единая информационная модель. Приведенные выше CASE средства способны генерировать код на различных объектно-ориентированных языках, а так же обладают очень полезной функцией реверсивного инжиниринга. (Реверсивный инжиниринг позволяет создать графическую модель из имеющегося программного кода и комментариев к нему.)

Рассмотрим типы диаграмм для визуализации модели (это must have, хотя типов гораздо больше):

Диаграмма вариантов использования (use case diagram)

Проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью, так называемых прецедентов. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.

Диаграмма классов (class diagram)

Диаграмма классов служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру (поля, методы…) и типы отношений (наследование, реализация интерфейсов …). На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы. На этом этапе принципиально знание ООП подхода и паттернов проектирования.

Диаграмма состояний (statechart diagram)

Главное предназначение этой диаграммы - описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий.

Диаграмма последовательности (sequence diagram)

Для моделирования взаимодействия объектов в языке UML используются соответствующие диаграммы взаимодействия. Взаимодействия объектов можно рассматривать во времени, и тогда для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности. Взаимодействующие объекты обмениваются между собой некоторой информацией. При этом информация принимает форму законченных сообщений. Другими словами, хотя сообщение и имеет информационное содержание, оно приобретает дополнительное свойство оказывать направленное влияние на своего получателя.

Диаграмма кооперации (collaboration diagram)

На диаграмме кооперации в виде прямоугольников изображаются участвующие во взаимодействии объекты, содержащие имя объекта, его класс и, возможно, значения атрибутов. Как и на диаграмме классов, указываются ассоциации между объектами в виде различных соединительных линий. При этом можно явно указать имена ассоциации и ролей, которые играют объекты в данной ассоциации.
В отличие от диаграммы последовательности, на диаграмме кооперации изображаются только отношения между объектами, играющими определенные роли во взаимодействии.

Диаграмма компонентов (component diagram)

Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код. Во многих средах разработки модуль или компонент соответствует файлу. Пунктирные стрелки, соединяющие модули, показывают отношения взаимозависимости, аналогичные тем, которые имеют место при компиляции исходных текстов программ. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.

Диаграмма развертывания (deployment diagram)

Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime). При этом представляются только компоненты-экземпляры программы, являющиеся исполнимыми файлами или динамическими библиотеками. Те компоненты, которые не используются на этапе исполнения, на диаграмме развертывания не показываются.
Диаграмма развертывания содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, диаграмма развертывания является единой для системы в целом, поскольку должна всецело отражать особенности ее реализации. Эта диаграмма, по сути, завершает процесс ООАП для конкретной программной системы и ее разработка, как правило, является последним этапом спецификации модели.

На этом закончим обзорный экскурс по диаграммам в частности и проектированию в общем. Стоит отметить, что процесс проектирования уже давно стал стандартом разработки ПО, но часто приходится сталкиваться с великолепно написанной программой, которая из за отсутствия нормальной документации обрастает ненужным побочным функционалом, костылями, становится громоздкой и теряет былое качество. =(

Я убежден, что программист в первую очередь это кодер – он НЕ должен общаться с заказчиком, НЕ должен задумываться об архитектуре системы, не должен изобретать интерфейс к программе, он только должен кодировать – реализовывать алгоритмы, функционал, внешний вид, юзабилити, но не более…. Проектировщик же должен начиная от абстрактных диаграмм (описывающих предметную область) до диаграмм представляющих структуру данных, классов и процессов их взаимодействия, детально шаг за шагом все расписать. То есть сложность работы и зарплата проектировщика должна быть на порядок выше чем у программиста == кодера. Простите за крамолу....