В настоящее время язык UML - это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., которая поддерживается многими объектно-ориентированными CASE-продуктами.

Стандарт UML предлагает следующий набор диаграмм для моделирования:

· диаграмма вариантов использования (use case diagram) – для моделирования бизнес-процессов организации или предприятия и определения требований к создаваемой информационной системе;

· диаграмма классов (class diagram) – для моделирования статической структуры классов системы и связей между ними;

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

· диаграмма взаимодействия (interaction diagrams);

· диаграмма последовательности (sequence diagrams) – для моделирования процесса обмена сообщениями между объектами в рамках одного варианта использования;

· диаграмма кооперации (collaboration diagram) – для моделирования процесса обмена сообщениями между объектами в рамках одного варианта использования;

· диаграмма состояний (statechart diagram) – для моделирования поведения объектов системы при переходе из одного состояния в другое;

· диаграмма видов деятельности (activity diagram) – для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей;

· диаграмма реализации (implementation diagrams):

· диаграмма компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) информационной системы;

· диаграмма развертывания (deployment diagram) – для моделирования физической архитектуры спроектированной информационной системы.

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

Рис. 1. Интегрированная модель информационной системы в нотации языка UML

4.2. Диаграмма вариантов использования

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

Рис.2. Вариант использования

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

Рис.3. Действующее лицо (актер)

Актеры делятся на три основных типа:

· пользователи;

· системы;

· другие системы, взаимодействующие с данной;

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

4.2.1. Связи между вариантами использования и актерами

В языке UML на диаграммах вариантов использования поддерживается несколько типов связей между элементами диаграммы:

· коммуникация (communication),

· включение (include),

· расширение (extend),

· обобщение (generalization).

Связь коммуникации – это связь между вариантом использования и актером. На языке UML связи коммуникации показывают с помощью однонаправленной ассоциации (сплошной линии).

Рис.4. Пример связи коммуникации

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

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

Рис.5. Пример связи включения и расширения

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

Рис.6. Пример связи обобщения

4.3.

Диаграммы взаимодействия (interaction diagrams) описывают поведение взаимодействующих групп объектов. Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой.

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

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

Сообщение-запрос (interrogative) – это сообщение, запрашивающее выдачу некоторой информации об объекте-получателе.

Императивное (imperative) сообщение – это сообщение, запрашивающее у объекта-получателя выполнение некоторых действий.

Существует два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и диаграммы кооперац (collaboration diagrams).

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

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

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

На диаграмме последовательности объект изображается в виде прямоугольника, от которого вниз проведена пунктирная вертикальная линия. Эта линия называется линией жизни (lifeline) объекта . Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.

Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице сверху вниз. Каждое сообщение помечается как минимум именем сообщения. При желании можно добавить также аргументы и некоторую управляющую информацию. Можно показать самоделегирование (self-delegation) – сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

Рис. 7. Пример диаграммы последовательности

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

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

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

Рис. 8. Пример диаграммы кооперации

4.4. Диаграмма классов

4.4.1. Общие сведения

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

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

На диаграмме классов изображаются следующие элементы:

· Пакет (package) - набор элементов модели, логически связанных между собой;

· Класс (class) - описание общих свойств группы сходных объектов;

· Интерфейс (interface) - абстрактный класс, задающий набор операций, которые объект произвольного класса, связанного с данным интерфейсом, предоставляет другим объектам.

4.4.2. Класс

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

Под поведением объекта в UML понимаются любые правила взаимодействия объекта с внешним миром и с данными самого объекта.

На диаграммах класс изображается в виде прямоугольника со сплошной границей, разделенного горизонтальными линиями на 3 секции:

Верхняя секция (секция имени) содержит имя класса и другие общие свойства (в частности, стереотип).

В средней секции содержится список атрибутов

В нижней - список операций класса, отражающих его поведение (действия, выполняемые классом).

Любая из секций атрибутов и операций может не изображаться (а также обе сразу). Для отсутствующей секции не нужно рисовать разделительную линию и как-либо указывать на наличие или отсутствие элементов в ней.

На усмотрение конкретной реализации могут быть введены дополнительные секции, например, исключения (Exceptions).

Рис. 9. Пример диаграммы классов

4.4.2.1.Стереотипы классов

Стереотипы классов – это механизм, позволяющий разделять классы на категории.

В языке UML определены три основных стереотипа классов:

Boundary (граница);

Entity (сущность);

Control (управление).

4.4.2.2.Граничные классы

Граничными классами (boundary classes) называются такие классы, которые расположены на границе системы и всей окружающей среды. Это экранные формы, отчеты, интерфейсы с аппаратурой (такой как принтеры или сканеры) и интерфейсы с другими системами.

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

4.4.2.3.Классы-сущности

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

4.4.2.4.Управляющие классы

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

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

Помимо упомянутых выше стереотипов можно создавать и свои собственные.

4.4.2.5.Атрибуты

Атрибут – это элемент информации, связанный с классом. Атрибуты хранят инкапсулированные данные класса.

Так как атрибуты содержатся внутри класса, они скрыты от других классов. В связи с этим может понадобиться указать, какие классы имеют право читать и изменять атрибуты. Это свойство называется видимостью атрибута (attribute visibility).

У атрибута можно определить четыре возможных значения этого параметра:

Public (общий, открытый). Это значение видимости предполагает, что атрибут будет виден всеми остальными классами. Любой класс может просмотреть или изменить значение атрибута. В соответствии с нотацией UML общему атрибуту предшествует знак « + ».

Private (закрытый, секретный). Соответствующий атрибут не виден никаким другим классом. Закрытый атрибут обозначается знаком « – » в соответствии с нотацией UML.

Protected (защищенный). Такой атрибут доступен только самому классу и его потомкам. Нотация UML для защищенного атрибута – это знак « # ».

Package or Implementation (пакетный). Предполагает, что данный атрибут является общим, но только в пределах его пакета. Этот тип видимости не обозначается никаким специальным значком.

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

4.4.2.6.Операции

Операции реализуют связанное с классом поведение. Операция включает три части – имя, параметры и тип возвращаемого значения.

Параметры – это аргументы, получаемые операцией «на входе». Тип возвращаемого значения относится к результату действия операции.

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

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

Имя Операции (аргумент: тип данных аргумента, аргумент2:тип данных аргумента2,...): тип возвращаемого значения

Следует рассмотреть четыре различных типа операций:

Операции реализации;

Операции управления;

Операции доступа;

Вспомогательные операции.

Операции реализации

Операции реализации (implementor operations) реализуют некоторые бизнес-функции. Такие операции можно найти, исследуя диаграммы взаимодействия. Диаграммы этого типа фокусируются на бизнес-функциях, и каждое сообщение диаграммы, скорее всего, можно соотнести с операцией реализации.

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

Операции управления

Операции управления (manager operations) управляют созданием и уничтожением объектов. В эту категорию попадают конструкторы и деструкторы классов.

Операции доступа

Атрибуты обычно бывают закрытыми или защищенными. Тем не менее, другие классы иногда должны просматривать или изменять их значения. Для этого существуют операции доступа (access operations). Такой подход дает возможность безопасно инкапсулировать атрибуты внутри класса, защитив их от других классов, но все же позволяет осуществить к ним контролируемый доступ. Создание операций Get и Set (получения и изменения значения) для каждого атрибута класса является стандартом.

Вспомогательные операции

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

Чтобы идентифицировать операции, выполните следующие действия:

1. Изучите диаграммы последовательности и кооперативные диаграммы. Большая часть сообщений на этих диаграммах является операциями реализации. Рефлексивные сообщения будут вспомогательными операциями.

2. Рассмотрите управляющие операции. Может потребоваться добавить конструкторы и деструкторы.

3. Рассмотрите операции доступа. Для каждого атрибута класса, с которым должны будут работать другие классы, надо создать операции Get и Set.

4.4.2.7.Связи

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

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

Связь ассоциация

Ассоциация (association) – это семантическая связь между классами. Их рисуют на диаграмме классов в виде обыкновенной линии.

Рис. 10. Связь ассоциация

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

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

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

Связь зависимость

Связи зависимости (dependency) также отражают связь между классами, но они всегда однонаправлены и показывают, что один класс зависит от определений, сделанных в другом. Например, класс A использует методы класса B. Тогда при изменении класса B необходимо произвести соответствующие изменения в классе A.

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

Рис. 11. Связь зависимость

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

Связь агрегация

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

Рис. 11. Связь агрегация

В дополнение к простой агрегации UML вводит более сильную разновидность агрегации, называемую композицией. Согласно композиции, объект-часть может принадлежать только единственному целому, и, кроме того, как правило, жизненный цикл частей совпадает с циклом целого: они живут и умирают вместе с ним. Любое удаление целого распространяется на его части.

Такое каскадное удаление нередко рассматривается как часть определения агрегации, однако оно всегда подразумевается в том случае, когда множественность роли составляет 1..1; например, если необходимо удалить Клиента, то это удаление должно распространиться и на Заказы (и, в свою очередь, на Строки заказа).

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

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

В UML 2 по сравнению с UML 1 произошло значительное изменение, а именно, понятие "компонент" было разделено на две составляющие: логическую и физическую. Логическая составляющая, продолжающая носить имя компонент (component), является элементом логической модели системы, в то время как физическая составляющая, называемая артефактом (artifact), олицетворяет физический элемент проектируемой системы, размещающийся на вычислительном узле (node).

Диаграммы компонентов и размещения имеют много общего, объединяя воедино следующие, теснейшим образом связанные, вещи:

• структуру логических элементов (компонентов);
• отображения логических элементов (компонентов) на физические элементы (артефакты);
• структуру используемых ресурсов (узлов) с распределенными по ним физическими элементами (артефактами).

В данном разделе мы отступим от правила, принятого нами при описании остальных диаграмм. А именно, мы не будем раздельно для каждой диаграммы рассматривать сущности, применяемые на ней. Более правильным нам кажется совместное рассмотрение всех сущностей и отношений в одном разделе, чем мы и займемся.

3.4.1. Интерфейс

∇ Встречающиеся в литературе варианты перевода: "реализованный", "предоставляемый".

∇∇ Встречающийся в литературе вариант перевода ‒ "запрашиваемый"

Однако, нельзя забывать, что сам по себе интерфейс ‒ это просто описание контракта, а обеспеченным или требуемым он становиться в зависимости от того, как этот интерфейс используется:

• если классификатор реализует интерфейс ‒ то для данного классификатора это обеспеченный интерфейс и данный факт показывается с помощью отношения реализации 3 ;
• если классификатор вызывает операции интерфейса - то для данного классификатора это требуемый интерфейс и данный факт показывается с помощью отношения зависимости 4 .

Разобравшись с интерфейсами, давайте перейдем к компонентам.

3.4.2. Компоненты, артефакты и узлы

Компонент (component) ‒ это модульный фрагмент логического представления системы, взаимодействие с которым описывается набором обеспеченных и требуемых интерфейсов.

С понятием "компонент" часто ассоциируют компонентное или сборочное программирование, однако для UML это соответствие не правомерно. Компонент UML является частью модели, и описывает логическую сущность, которая существует только во время проектирования (design time), хотя в дальнейшем ее можно связать с физической реализацией (артефактом) времени исполнения (run time).

Стандартом UML для компонентов предусмотрены стереотипы, приведенные в следующей таблице.

Табл. Стандартные стереотипы компонентов

Аналогом компонента в смысле сборочного программирования является понятие артефакта в UML. Причем не любого артефакта, а только некоторых из его стереотипов.

Артефакт ‒ это любой созданный искусственно элемент программной системы.

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

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

Табл. Стандартные стереотипы артефактов

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

Самым важным аспектом использования понятия артефакта в UML является то, что артефакт может участвовать в отношении манифестации.

Манифестация ‒ это отношение зависимости со стереотипом «manifest» , связывающее элемент модели (например, класс или компонент) и его физическую реализацию в виде артефакта.

Ниже представлен класс Company , который связан отношением манифестации (зависимость со стереотипом «manifest») с двумя артефактами со стереотипом «source» , которые в свою очередь определяют артефакт времени выполнения динамическую библиотеку (со стереотипом «library») Company .

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

Манифестацию графически изображают отношением зависимости со стереотипом «manifest» от артефакта к реализуемой сущности. Поскольку манифестация ‒ это отношение типа "многие ко многим", для полного описания отношения манифестации могут потребоваться несколько отношений зависимости в модели.

Третья сущность, рассматриваемая в этом параграфе ‒ узел.

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

В UML предусмотрено два стереотипа для узлов «executionEnvironment» и «device» .

Узел со стереотипом «executionEnvironment» позволяет моделировать аппаратно-программную платформу, на которой происходит выполнение приложения. Примерами среды выполнения являются: операционная система, система управления базами данных и т.д.

Узел со стереотипом «device» также моделирует аппаратно-программную платформу, но допускает возможность вложение одного узла в другой, как это показано на следующем рисунке.

Артефакты системы во время ее работы размещаются на узлах, что графически выражается либо их перечислением внутри узла 1 (см. рисунок выше), либо отношением зависимости со стереотипом «deploy» между артефактом и узлом 1 (см. рисунок ниже), либо изображением артефакта внутри изображения узла 2 (см. рисунок ниже). Все варианты нотации равноправны.

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

Спецификация развертывания изображается, как и классификатор (в виде прямоугольника), но со стереотипом «deploymentSpec» и связывается отношением зависимости с артефактом.

Последнее, что нам осталось рассмотреть в рамках данного параграфа ‒ это отношение ассоциации между узлами.

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

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

3.4.3. Применение диаграмм компонентов и размещения

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

Основное назначение проектируемой информационной системы ‒ хранить данные о кадрах и выполнять по указанию пользователя некоторые операции с этими данными. Анализируя состав операций, мы видим, что они сводятся к созданию, модификации и удалению хранимых элементов данных. Стандартным решением в таких ситуациях является применение готовой СУБД (DBMS ‒ Data Base Management System). С точки зрения проектирования информационной системы отдела кадров целесообразно считать используемую СУБД готовым компонентом с заранее определенными интерфейсами и протоколом взаимодействия. Мы можем не заострять внимания на структуре этого компонента ‒ она стандартна и, наверное, достаточно хорошо описана вне нашей модели.

СУБД возьмет на себя все функции по непосредственному манипулированию данными: создание, удаление и поиск записей в таблицах и т.д. Реализация операций нашей информационной системы отдела кадров сводится к некоторой последовательности элементарных операций с данными. Например, операция перевода сотрудника с одной должности на другую, видимо, потребует изменения в трех элементах данных: в данных о сотруднике и в данных о старой и новой должностях. Однако целесообразно ли считать, что определение и выполнение самой последовательности элементарных операций с данными также является прерогативой выделенного нами компонента ‒ СУБД? Общепринятая практика отвечает на этот вопрос отрицательно. По многим причинам лучше выделить это в отдельный компонент, обычно называемый бизнес-логикой ∇ . Кроме этого, мы должны предположить, что в нашей системе должен быть компонент, ответственный за пользовательский интерфейс. В первом приближении мы приходим к структуре компонентов, приведенной ниже, которая называется «трехуровневая архитектура».

∇ Крайне неудачный, но часто используемый термин, являющийся калькой английского business logic. Бизнес-логика не имеет никакого отношения ни к бизнесу (в российском понимании этого слова), ни к логике. Правильнее было бы использовать сложное словосочетание "правила обработки данных", но мы боимся оказаться непонятыми.

В версии UML 2 произошли следующие изменения в нотации диаграмм компонентов.

Во-первых, компоненты, как и любой классификатор, можно изображать единообразно, в виде прямоугольников, в которых, указывается либо стереотип «component» 1 , либо один из уточняющих стереотипов, приведенных в табл. Стандартные стереотипы компонент в параграфе 3.4.2 2 , либо соответствующий значок в правом верхнем углу прямоугольника 3 .

Во-вторых, требуемые и обеспеченные интерфейсы можно изображать с помощью нотации "чупа-чупс" 4 (см. параграф 3.3.1), так что отношение взаимодействия компонентов через некоторый интерфейс выглядит естественным и симметричным.

Сказанное иллюстрирует рисунок ниже на котором указаны те же сущности и отношения, что и на рисунке выше.

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

Допустим, что в проектируемой информационной системе отдела кадров требуется разграничить права на выполнение операций и доступ к данным для различных категорий пользователей. Хотя в нашем техническом задании про это не сказано ни слова, но для современных систем данное требование стало общим местом (иногда явно лишним), так что пример не является надуманным. Нам известно множество способов реализации разграничения прав доступа к данным, а неизвестных нам способов, наверное, существует еще больше. Мы не будем вдаваться в их описание и обсуждение, а ограничимся одним - очень простым, но действенным. У нашего приложения два действующих лица (см. параграф 2.2.1), т.е. две категории пользователей. Допустим, что достаточно разграничить права на уровне категорий пользователей. Тогда можно поступить следующим образом: сделать просто два различных приложения (или, как обычно говорят в таких случаях, два автоматизированных рабочих места ‒ АРМа). Пользователи, имеющие доступ к АРМу в целом, могут выполнять все операции АРМа и, таким образом, имеют те и только те права на доступ к данным, которые обеспечиваются операциями, реализованными в АРМе.

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

Принятое решение легко выражается на диаграмме компонентов.

Все что осталось сделать ‒ это определить состав компонентов, т.е. показать какие классы в какие компоненты входят.

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

Другой способ определения состава компонента ‒ рассматривать его как структурированный классификатор и использовать диаграмму внутренней структуры (см. параграф 1.6.2 и параграф 3.5.1).

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

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

∇ Программисты заимствовали название раздела математики (топология) как термин. Например, часто можно встретить выражение "топология локальной сети". Нельзя сказать, что такое заимствование совершенно неверно, но в то же время оно и не совсем по существу. Речь идет просто об описании структуры связей конечного множества узлов, т.е. о графе.

Продолжим рассмотрение информационной системы отдела кадров в этом аспекте. Допустим, что мы приняли архитектуру, приведенную выше на рисунке "Диаграмма компонентов ИС OK". Сколько компьютеров будет использоваться при работе данного приложения? На этот вопрос нужно отвечать также вопросом: а сколько пользователей будет у системы и сколько из них будут работать с приложением одновременно? Если имеется только один пользователь (или, хуже того, нашу систему установят "для галочки", а использовать не будут), то проблем нет ‒ настольное приложение ‒ один компьютер и диаграмма размещения не нужна. Допустим, что у нашей системы должно быть много пользователей, и они могут работать одновременно. Тогда ответ очевиден: узлов должно быть не меньше, чем число одновременно работающих пользователей, потому что вдвоем за одним персональным компьютером обычным пользователям работать неудобно. Скорее всего, узлов должно быть на единицу больше чем пользователей, т.к. в большинстве организаций есть специально выделенный компьютер (сервер) для хранения корпоративных данных. Там мы и поместим нашу базу данных, в расчете на то, что нужная СУБД, скорее всего, на сервере уже установлена. Остается вопрос о размещении артефактов, реализующих бизнес-логику. Здесь возможны разные варианты: на компьютере пользователя, на промежуточной машине (сервере приложений), на корпоративном сервере баз данных. Если мы остановимся на последнем варианте (который на жаргоне называется "архитектура клиент/сервер с тонким клиентом"), то получим диаграммы, приведенные на следующих двух рисунках.

Обе эти диаграммы являются диаграммами размещения, но каждая из них имеет свои особенности. На первой диаграмме упор сделан на указание соответствия между компонентами и артефактами, выражающийся в наличии большого количества отношений зависимости со стереотипом «manifest» (см., например, 1 на первой диаграмме). Вторая диаграмма показывает отношения между артефактами, или, другими словами, определяет, какой артефакт от какого зависит, например, запрашивает данные (в качестве примера см. 1 на второй диаграмме). На обеих диаграммах показаны вычислительные узлы и отношения между ними (2 на обоих диаграммах). Заметим, что на диаграмме появился дополнительный артефакт ‒ Help (например, 3 на второй диаграмме). Это документ, содержащий справочную информацию.

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

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

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

При разработке приложений, которые должны взаимодействовать с так называемыми унаследованными (legacy) приложениями и данными, без диаграмм компонентов трудно обойтись. Дело в том, что фактически единственным средством UML, позволяющим как-то описать и включить в модель унаследованные приложения и данные являются компоненты (и их интерфейсы). Сюда же относится случай моделирования доступа к данным из "неродной" СУБД.

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

∇ Отметим еще раз, что во время выполнения мы имеем дело не с самими классификаторами, а с их экземплярами. Представлению экземпляров классификаторов посвящен параграф 3.5.4 .

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

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

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

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

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

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

Зачем она нужна?

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

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

Также стоит отметить, что есть несколько видов таких диаграмм.

Диаграмма классов

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

Стоит отметить тот факт, что есть несколько точек зрения на построение таких диаграмм в зависимости от того, каким образом они будут использоваться:

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

Диаграмма компонентов

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

Диаграмма композитной/составной структуры

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

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

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

Диаграмма развертывания

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

Между артефактом и тем компонентом, который он реализует, формируется зависимость манифестации.

Диаграмма объектов

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

Диаграмма пакетов

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

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

Диаграмма деятельности

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

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

Диаграмма автомата

Этот вид называется и несколько иначе - диаграмма состояний UML. Имеет представленный конечный автомат с простыми и композитными состояниями, а также переходами.

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

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

Диаграммы сценариев использования

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

Если диаграмма вариантов использования UML используется в процессе моделирования системы, то аналитик собирается:

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

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

Коммуникации

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

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

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

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

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

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

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

Диаграмма сотрудничества

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

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

Диаграммы обзора взаимодействия

Это диаграммы языка UML, которые относятся к разновидности диаграмм деятельности и включают в себя одновременно элементы Sequence и конструкции потока управления.

Стоит отметить тот факт, что данный формат объединяет в себе Collaboration и Sequence diagram, которые предоставляют возможность с разных точек зрения рассматривать взаимодействие между несколькими объектами в формируемой системе.

Диаграмма синхронизации

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

В чем преимущества?

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

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

Недостатки

Несмотря на то что построение UML-диаграмм отличается массой своих плюсов, довольно часто их и критикуют за следующие недостатки:

• Избыточность. В преимущественном большинстве случаев критики говорят о том, что UML является слишком большим и сложным, и зачастую это неоправданно. В него входит достаточно много избыточных или же практически бесполезных конструкций и диаграмм, причем наиболее часто подобная критика идет в адрес второй версии, а не первой, потому что в более новых ревизиях присутствует большее количество компромиссов «разработанных комитетом».
• Различные неточности в семантике. По той причине, что UML определяется комбинацией себя, английского и OCL, у него отсутствует скованность, которая является присущей для языков, точно определенных техникой формального описания. В определенных ситуациях абстрактный синтаксис OCL, UML и английский начинают друг другу противоречить, в то время как в других случаях они являются неполными. Неточность описания самого языка одинаково отражается как на пользователях, так и на поставщиках инструментов, что в конечном итоге приводит к несовместимости инструментов из-за уникального способа трактовки различных спецификаций.
• Проблемы в процессе внедрения и изучения. Все указанные выше проблемы создают определенные сложности в процессе внедрения и изучения UML, и в особенности это касается тех случаев, когда руководство заставляет инженеров насильно его использовать, в то время как у них отсутствуют предварительные навыки.
• Код отражает код. Еще одним мнением является то, что важность имеют не красивые и привлекательные модели, а непосредственно рабочие системы, то есть код и есть проект. В соответствии с данным мнением есть потребность в том, чтобы разработать более эффективный способ написания программного обеспечения. UML принято ценить при подходах, компилирующих модели для регенерирования выполнимого или же исходного кода. Но на самом деле этого может быть недостаточно, потому что в данном языке отсутствуют свойства полноты по Тьюрингу, и каждый сгенерированный код в конечном итоге будет ограничиваться тем, что может предположить или же определить интерпретирующий UML инструмент.
• Рассогласование нагрузки. Данный термин происходит из теории системного анализа для определения неспособности входа определенной системы воспринять выход иной. Как в любых стандартных системах обозначений, UML может представлять одни системы в более эффективном и кратком виде по сравнению с другими. Таким образом, разработчик больше склоняется к тем решениям, которые являются более комфортными для переплетения всех сильных сторон UML, а также других языков программирования. Данная проблема является более очевидной в том случае, если язык разработки не соответствует основным принципам объектно-ориентированной ортодоксальной доктрины, то есть не старается работать в соответствии с принципами ООП.
• Пытается быть универсальным. UML представляет собой язык моделирования общего назначения, который старается обеспечить совместимость с любым существующим на сегодняшний день языком обработки. В контексте определенного проекта, для того, чтобы команда проектировщиков смогла добиться конечной цели, нужно выбирать применимые возможности этого языка. Помимо этого возможные пути ограничения сферы использования UML в какой-то определенной области проходят через формализм, который является не полностью сформулированным, а который сам представляет собой объект критики.

Таким образом, использование данного языка является актуальным далеко не во всех ситуациях.

Язык UML

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

UML пригоден для моделирования любых систем: от информационных систем масштаба предприятия до распределенных Web -приложений и даже встроенных систем реального времени. UML – это язык для визуализации, специфицирования, конструирования и документирования артефактов программных систем. Язык моделирования, подобный UML, является стандартным средством для составления «чертежей» программного обеспечения.

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

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

UML – это язык конструирования, и модели, созданные с его помощью, могут быть непосредственно переведены на различные языки программирования. Иными словами, UML-модель можно отобразить на такие языки, как Java , C++, Visual Basic , и даже на таблицы реляционной базы данных.

Такое отображение модели на язык программирования позволяет осуществлять прямое проектирование: генерацию кода из модели UML в какой-то конкретный язык. Можно решить и обратную задачу: реконструировать модель по имеющейся реализации.

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

Использование UML эффективно в:

· информационных системах масштаба предприятия;

· банковских и финансовых услугах;

· телекоммуникациях;

· на транспорте;

· оборонной промышленности, авиации и космонавтике;

· розничной торговле;

· медицинской электронике;

· науке;

· распределенных Web -системах.

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

1 Структура и компоненты языка UML

1.1 Общие принципы

Конструктивное использование языка UML основывается на понимании общих принципов моделирования сложных систем и особенностей процесса объектно-ориентированного анализа и проектирования (ООАП). Выбор выразительных средств для построения моделей сложных систем основывается на нескольких принципах.

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

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

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

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

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

1.2 Сущности

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

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

Класс (Class ) – это описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой (рис. 3). Класс реализует один или несколько интерфейсов.

Рис. 3 Классы

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

Рис. 4 Интерфейс

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

Рис. 5 Кооперация

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

Рис. 6 Прецедент

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

Рис. 7 Активный класс

Компоненты и узлы соответствуют физическим сущностям системы.

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

Рис. 8 Компонент

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

Рис. 9 Узел

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

Поведенческие сущности (Behavioral things ) являются динамическими составляющими модели UML. Это глаголы языка: они описывают поведение модели. Существует всего два типа поведенческих сущностей.

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

Рис. 10 Сообщение

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

Рис. 11 Состояние

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

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

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

Рис. 12 Пакеты

Существуют также вариации пакетов, например каркасы ( Frameworks ), модели и подсистемы.

Аннотационные сущности – пояснительные части модели UML. Это комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели. Имеется только один базовый тип аннотационных элементов – примечание.

Примечание (Note ) – это символ для изображения комментариев, присоединенных к элементу или группе элементов (рис. 13).

Рис. 13 Примечание

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

1.2 Отношения

В языке UML определены четыре типа отношений : зависимость, ассоциация, обобщение, реализация. Эти отношения являются основными связующими строительными блоками в UML .

Зависимость (Dependency ) – это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой (рис. 14).

Рис . 14 Отношения зависимости

Ассоциация (Association ) – отношение, описывающее совокупность связей между объектами. Разновидностью ассоциации является агрегирование ( Aggregation ) – структурное отношение между целым и его частями (рис. 15). Графическое изображение ассоциации может включать кратность и имена ролей (рис. 16).

Рис . 1 5 Агрегирование

Рис . 16 Имена ассоциаций

Обобщение (Generalization ) – это отношение “специализация/обобщение” (рис. 17), при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка). Таким образом, потомок ( Child ) наследует структуру и поведение своего родителя ( Parent ).

Рис. 17 Обобщение

Наконец, реализация ( Realization ) – это отношение между классификаторами, при котором один классификатор определяет “контракт”, а другой гарантирует его выполнение (рис. 18).

Рис. 18 Реализация

Отношения реализации встречаются в двух случаях: во-первых, между интерфейсами и реализующими их классами или компонентами, а во-вторых, между прецедентами и реализующими их кооперациями.

1.2 Диаграммы

Диаграмма в UML – это графическое представление набора элементов, изображаемое в виде связанного графа с вершинами (сущностями) и ребрами (отношениями), используемое для визуализации системы с разных точек зрения. В UML выделяют 8 типов диаграмм (рис. 1 9 ).

Рис. 19 Интегрированная модель сложной системы в нотации UML

На диаграмме классов ( C lass diagram) изображаются классы, интерфейсы, объекты и кооперации, а также их отношения. Используется при моделировании объектно-ориентированных систем.

На диаграмме вариантов использования (Use case diagram) представлены прецеденты и актеры (частный случай классов), а также отношения между ними. Они используются при моделировании поведения системы.

Диаграммы последовательностей (Sequence diagram) и кооперации (Collaboration diagram) являются частными случаями диаграмм взаимодействия. На диаграммах взаимодействия представлены связи между объектами (сообщения, которыми объекты могут обмениваться). Диаграммы взаимодействия относятся к динамическому виду системы. При этом диаграммы последовательности отражают временную упорядоченность сообщений, а диаграммы кооперации – структурную организацию обменивающихся сообщениями объектов. Эти диаграммы могут быть преобразованы друг в друга.

На диаграммах состояний ( S tatechart diagrams ) представлен автомат, включающий состояния, переходы, события и виды действий. Диаграммы состояний используются при моделировании поведения интерфейса, класса или кооперации, зависящем от последовательности событий.

Диаграмма деятельности (Activity diagram) представляют переходы потока управления между объектами от одной деятельности к другой внутри системы.

Диаграмма компонентов (Component diagram) представляет зависимости между компонентами. Диаграммы компонентов отображаются на один или несколько классов, интерфейсов или коопераций.

На диаграмме развертывания (Deployment diagram) представлена конфигурация обрабатывающих узлов системы и размещенных в них компонентов.