СиППО (24, 29-41) (Ответы на все вопросы), страница 3

34.  Общая характеристика и назначение языка UML.

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

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

∙        Описание требований к разрабатываемой системе.

∙        Описание структуры и бизнес-процессов предметной области.

∙        Проектирование архитектуры программного продукта.

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

∙        Генерация  структуры объектно-ориентированной программы.

Как любой язык, так и UML имеет различные реализации. Так как UML является языком проектирования программных средств, то его реализации выполнены в виде CASE-средств (Computer Aided Software Engineering). Кроме того, для пользования им необходимо освоить методику работы с UML.

Язык UML это язык диаграмм и его использование заключается в их составлении. Каждая диаграмма состоит из компонентов и отношений между ними. Основные диаграммы языка UML:

∙        Диаграмма вариантов использования (Use Case Diagram), равнозначный термин - диаграмма прецедентов.

∙        Диаграмма последовательностей (Sequence Diagram).

∙        Диаграмма кооперации (Collaboration Diagram).

∙        Диаграмма классов (Class Diagram).

∙        Диаграмма деятельности (Activity Diagram).

∙        Диаграмма компонентов (Component Diagram).

∙        Диаграмма развертывания (Deployment Diagram).

∙        Диаграмма состояний (Statechart Diagram).

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

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

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

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

Рис. 2.1.

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

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

Рис. 2.2.

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

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

На диаграмме вариантов использования могут быть применены (и показаны на диаграммы) следующие виды отношений:

·        Отношение ассоциации (association relationship).

·        Отношение расширения (extend relationship).

·        Отношение включения (include relationship).

·        Отношение обобщения (generalization relationship).

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

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

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

Отношение обобщения связывает менее общее с более общим. Подробно рассмотрим это отношение при обсуждении диаграмм классов. Пример отношения обобщения приведен на рис. 2.4.

Рис. 2.3.

Рис. 2.4.

Главное назначение диаграммы вариантов использования заключается в формализации функциональных требований к системе с помощью действующих лиц – потенциальных пользователей и вариантов использования – задач, с которыми они будут обращаться к разрабатываемому программному продукту. Рекомендуемые ограничения: действующих лиц не более 20, вариантов использования не более 50. В противном случае диаграмма теряет наглядность; в таком случае следует составить несколько диаграмм или использовать пакеты для структурирования модели. Важно сконцентрироваться исключительно на том, что должен делать создаваемый программный продукт, а не на том, как он это будет делать. Построение диаграммы вариантов использования специфицирует не только функциональные требования к проектируемой системе, но и выполняет исходную структуризацию предметной области.

Составление диаграммы вариантов использования позволяет:

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

2.     Варианты использования позволяют разработчикам понять назначение разрабатываемой системы.

3.     Варианты использования являются основой тестирования элементов программного продукта на всем протяжении его жизненного цикла; они позволяют проверять корректность их реализации.

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

1.     Выделить действующие лица. При этом надо четко ответить на вопрос: чем отличаются друг от друга отдельные действующие лица?

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

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

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

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

Действующие лица:

1.     менеджер,

2.     консультант у справочного телефона магазина,

3.     продавец,

4.     кладовщик,

5.     сотрудник на выдаче.

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

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

Консультант на телефоне:

1.     получение справок о характеристиках продаваемых товаров,

2.     получение справок о наличии товара на складе,

3.     резервирование товара,

4.     аннулирование резервирований по желанию покупателя или после закрытия магазина.

Продавец:

1.     получение справок о характеристиках продаваемых товаров,

2.     получение справок о наличии товара на складе,

3.     резервирование товара,

4.     выписывание счета,

5.     передача копии счета на склад.

Кладовщик:

1.     Изменение количества товара на складе после отпуска,

2.     Изменение количества товара на складе после возврата с выдачи.

Менеджер:

1.     получение справок о наличии товара на складе,

2.     анализ хода продаж отдельных видов товаров,

3.     анализ времени нахождения товара на складе.

Сотрудник на выдаче не осуществляет  ввод данных и поэтому он не рассматривается в дальнейшем как действующее лицо. Составленные диаграммы вариантов использования представлены на рис. 2.5 и 2.6.

Рис. 2.5.

Рис. 2.6.

36.  Диаграмма последовательности и кооперативная диаграмма, их назначение, компоненты.

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

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