maran program engineering (Маран Программная инженерия), страница 6

Отсутствует25руководитель проекта, который распределяет задания и проверяет их выполнение.Критерии применимости гибких методик четко изложены в [4]. Важныдва параметра: критичность и масштаб. Критичность определяется последствиями потери работоспособности программного обеспечения.

Выделены4 уровня:С — потеря удобства.D — потеря восстанавливаемых ресурсов (материальных, финансовых).E — потеря невосстанавливаемых ресурсов (материальных, финансовых).L — угроза техногенных катастроф.Масштаб определяется количеством занятых в разработке специалистов:• 1–6 — малый;• 7–20 — средний;• Более 20 — большой.Гибкие методики могут применяться при критичности C и D и при малыхи средних разработках.263. Языки UML и OCL3.1. Общие понятияЯзык UML (Unified Modeling Language) — это язык графического моделирования, широко применяемый при разработке программных средств по объектно-ориентированной методике.

Авторами языка являются «три друга», каких часто именуют в литературе, — G. Booch, J. Rumbaugh и I. Jacobson. ЯзыкUML предназначен для выполнения этапов анализа и проектирования программных средств. Кроме того, язык UML может быть использован при тестировании и для управления выполнением проекта. С помощью языка UML можно выполнять следующие задачи:• описание требований к разрабатываемой системе;• описание структуры и бизнес-процессов предметной области;• проектирование архитектуры программного продукта;• проектирование размещения программного продукта в сети;• генерация структуры объектно-ориентированной программы.Как любой язык, UML имеет различные реализации. Так как UML является языком проектирования программных средств, то его реализации выполненыв виде CASE-средств (Computer Aided Software Engineering). Кроме того, дляпользования им необходимо освоить методику работы с UML.

Эти вопросы будут рассмотрены в следующих главах данного пособия. В этой главе рассмотрим структуру диаграмм.В настоящее время последней версией является UML 2.5, полное описание которой приведено в [7], а сжатое описание ее диаграмм в [6]. Ограничимсярассмотрением базовых его средств. По мнению автора, удачное описание UMLс множеством рекомендаций по его применению имеется в [8].UML — это язык диаграмм. Приведем классификацию диаграмм, рассматриваемых далее (полную классификацию можно найти в [6]). Приведем ихназвания и на английском языке, потому что многие CASE-средства не русифицированы.1.

Структурные диаграммы:• диаграмма классов (Class Diagram);• диаграмма компонентов (Component Diagram);• диаграмма размещения (Deployment Diagram).2. Диаграммы поведения:• диаграмма вариантов использования (Use Case Diagram);• диаграмма деятельности (Activity Diagram);• диаграмма состояний (State Machine Diagram);• диаграммы взаимодействия (Interaction Diagram):o диаграмма коммуникации (Communication Diagram);o диаграмма последовательностей (Sequence Diagram).27Язык объектных ограничений (Object Constraint Language, OCL) [6] является формальным языком описания ограничений, которые могут быть использованы при различных компонентах языка UML. OCL может применяться как совместно с UML, так и самостоятельно. Средства OCL позволяют задавать нетолько объектные ограничения, но и другие логико-лингвистические выражения.Приступим к рассмотрению упомянутых средств.3.2.

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

При проведении системного анализа с целью определения требований к новому программномупродукту можно исследуемую предметную область разделить на подсистемы,каждой подсистеме поставить в соответствие пакет и на первом этапе рассматривать только связи между подсистемами. Простейшая диаграмма с использованием пакетов показана на рис. 3.1.Package_1Package_2Рис. 3.1Между пакетами допускается только одна разновидность отношений −отношение зависимости.

В данном случае это означает, что пакет 1 зависит отпакета 2. Допускается использование и нескольких уровней пакетов: внутри пакета могут находиться пакеты следующего уровня.Примечание. Пакеты могут использоваться не только в диаграммах вариантов использования, но и в других диаграммах.Основными компонентами диаграммы вариантов использования являютсядействующие лица (в литературе используют равнозначные термины − актер,актант), варианты использования (равнозначный термин — прецедент) и отношения между ними. На рис.

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

Варианты использования соответствуют задачам, для решениякоторых и разрабатывается программный продукт. В ходе дальнейшей работыих необходимо детализировать с помощью других диаграмм. На диаграмме вариантов использования нас их реализация не интересует.На диаграмме вариантов использования могут быть применены (и показаны на ней) следующие виды отношений:• отношение ассоциации (association relationship);• отношение расширения (extend relationship);• отношение включения (include relationship);• отношение обобщения (generalization relationship).Отношение ассоциации используется для задания взаимодействия действующего лица и вариантов использования: какое действующее лицо какие варианты использует. Пример этого отношения приведен на рис. 2.2.

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

Отношения расширения и включения представлены на рис. 3.3.Отношение обобщения связывает менее общее с более общим. Подробнорассмотрим это отношение при обсуждении диаграмм классов. Пример отношения обобщения приведен на рис. 3.4.<<extend>>Вариант 1<<include>>РасширениеВключениеВариант 3Вариант 2Рис. 3.3КлиентФизическоелицоЮридическоелицоРис.

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

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

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