Структурные диаграммы UML. Диаграмма объектов. Диаграмма композитных структур.

Диаграммы языка UML делятся на две группы:

1) Структурные диаграммы;

2) Диаграммы поведения.

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

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

• Диаграммы классов (class diagram) - предназначены для моделирования структуры объектно-ориентированных приложений – классов (интерфесов классов, коопераций, отношений между классами), их атрибутов и заголовков методов, наследования, а также связей классов друг с другом;

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

• Диаграммы компонентов (component diagram) - используются при моделировании компонентной структуры распределенных приложений; внутри каждая компонента может быть реализована с помощью множества классов;

• Диаграммы развёртывания (deployment diagram) - предназначены для моделирования аппаратной части системы, с которой ПО непосредственно связано (размещено или взаимодействует);

• Диаграммы композитных стурктур (Composite structure diagram) - используются для моделирования составных структурных элементов моделей - коопераций, композитных компонент и т.д.;

• Диаграммы пакетов ( package diagram) - служат для разбиения объемных моделей на составные части, а также (традиционно) для группировки классов моделируемого ПО, когда их слишком много.

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

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

• Отношение зависимости (dependency relationship);
• Отношение ассоциации (association relationship);
• Отношение обобщения (generalization relationship).

Диаграмма композитной/составной структуры (Composite structure diagram) — статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса.

Подвидом диаграмм композитной структуры являются диаграммы кооперации (Collaboration diagram, введены в UML 2.0), которые показывают роли и взаимодействие классов в рамках кооперации. Кооперации удобны при моделировании шаблонов проектирования.

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

 

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

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

Рис. 3.4. Диаграмма прецедентов использования, описывающая субъекты системы управле­ния магазином видеокассет

Модели, показанные на рис. 3.3 и 3.4, демонстрируют, что действующее лицо Сотрудник непосредственно связано со всеми прецедентами использова­ния. Действующее лицо Клиент может достичь своих целей лишь с помощью действующего лица Сотрудник, поэтому между ними существует зависимость (dependency). Прямая связь между действующим лицом Клиент и прецедентом использования Списание денег со счета означает, что клиент должен вве­сти PIN-код и подтвердить оплату с помощью сканирующего устройства.

В целом диаграммы прецедентов использования допускают использование нескольких отношений между элементами. Отношение «расширить» («extend») на рис. 3.3 и 3.4 означает, что функциональное свойство Принятие платежа иногда может быть расширено (поддержано) пре­цедентом использования Списание денег со счета.

3.1.4. Документирование прецедентов использования

Динамика каждого прецедента использования должна быть описана с по­мощью других моделей UML и/или с помощью спецификации потока событий (flow of events document), т.е. текстового документа, определяющего, что должна делать система, когда действующее лицо инициирует прецедент использования. Структура спецификации прецедента использования (use case document) может варьироваться, однако типичное описание должно содержать следующую инфор­мацию (Quatrani, 2000).

■ Краткое описание.

■ Участвующие действующие лица.

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

■ Детализированное описание потока событий, включающее в себя:

■ основной поток событий, который можно разбить на несколько частей, чтобы показать подчиненные потоки событий (подчиненные потоки могут быть разделены затем на еще более мелкие потоки, с целью улуч­шить читабельность документа);

■ альтернативные потоки для определения исключительных ситуаций.

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

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

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

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

Диаграмма деятельности (activity diagram) показывает потоки между дейст­виями и узлами (nodes), например решениями, разветвлениями, соединениями, слияниями и объектами. Обычно между видами деятельности и диаграммами деятельности существует взаимно однозначное соответствие, т.е. деятельность изображается с помощью диаграмм деятельности.

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

Потоки могут разветвляться (branch) в зависимости от условий и сливаться (merge). В результате возникают альтернативные потоки вычислений (alternative computation thread). Условие ветвления обозначается ромбом. Выход из условия ветвления управляется событием, например Да или Нет, или сторожевым услови­ем (guard condition), например [светло-зеленый], [высокий рейтинг].

Кроме того, потоки могут разделяться (fork) и воссоединяться (rejoin). В ре­зультате возникают параллельные потоки вычислений (concurrent computation threads). Разделение и воссоединение потоков представляется в виде жирной ли­нии. Диаграмма деятельности, в которой отсутствуют параллельные процессы, похожа на обычную блок-схему (в этом разделе параллельное функционирование системы не рассматривается).

Для того чтобы нарисовать диаграмму, демонстрирующую работу магазина ви­деокассет, достаточно соединить действия, идентифицированные на рис. 3.5, со­ответствующими потоками, как показано на рис. 3.6. Начальным является дейст­вие Вывести на экран информацию о транзакции. Рекурсивный поток (recursive flow), связанный с этим действием, отражает тот факт, что изображение дисплея постоянно обновляется, пока вычисления не перейдут в следующий узел.

На протяжении действия Вывести на экран информацию о транзакции заказчик может предложить оплату наличными или с помощью кредитной кар­точки. Это приводит к выполнению одного из двух возможных потоков вычис­лений. В узле Обработать платеж по карточке (см. рис. 3.6) объединено несколько действий, связанных с принятием платежа по кредитной карточке. Это вложение удобно, когда источником потока действий может быть любое из вло­женных действий. В таком случае поток может исходить из узла действий. При­мером может служить поток, входящий в узел ветвления Есть ли проблемы с оплатой?

Необходимость проверки условия Есть ли проблемы с оплатой? объяс­няется возможной нехваткой денег у заказчика. Если проблем нет, то транзакция подтверждается и процесс переходит к заключительному действию. В противном случае следует проверить рейтинг заказчика. В зависимости от рейтинга тран­закция отменяется (если выполняется сторожевое условие [Плохой]), допус­кается частичная оплата (если выполняется сторожевое условие [Хороший]) или допускается прокат без оплаты (если выполняется сторожевое условие [Отличный]).

 

Рис. 3.6. Диаграмма активности

 

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

⇐ Предыдущая12345678910Следующая ⇒

Поделиться:

Воспользуйтесь поиском по сайту: