Контрольная работа по дисциплине "Технология разработки программного обеспечения "

    Обычно  расширения используют:

• для моделирования вариантных частей элементов Use Case;
• для моделирования сложных и редко выполняемых альтернативных последовательностей;
• для моделирования подчиненных последовательностей, которые выполняются только в определенных случаях;
• для моделирования систем с выбором на основе меню.

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

Уточнение модели требований

 

    Уточнение модели сводится к выявлению одинаковых частей в элементах Use Case и извлечению этих частей. Любые изменения в  такой части, выделенной в отдельный  элемент Use Case, будут автоматически  влиять на все элементы Use Case, которые  используют ее совместно.

    Извлеченные элементы Use Case называют абстрактными. Они не могут быть конкретизированы сами по себе, применяются для описания одинаковых частей в других, конкретных элементах Use Case. Таким образом, описания абстрактных элементов Use Case используются в описаниях конкретных элементов Use Case. Говорят, что конкретный элемент Use Case находится в отношении «включает» с абстрактным элементом Use Case.

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

    

    Рис. 6. Применение отношения включения

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

    Выделение абстрактных элементов Use Case можно  упростить с помощью абстрактных  актеров.

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

    

    Рис. 7. Выделение абстрактного актера

Выводы

 

    Абстрактные элементы Use Case находят извлечением  общих последовательностей из различных  элементов Use Case.

    Отношение «включает» применяется, если несколько  элементов Use Case имеют общее поведение. Цель: устранить повторения, ликвидировать  избыточность.

    Кроме того, это отношение часто используют для ограничения сложности большого элемента Use Case.

    Отношение «расширяет» применяется, когда  описывается вариация, дополняющая  нормальное поведение.

Кооперации  и паттерны

 

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

    В терминологии фирмы Rational (вдохновителя и организатора побед языка UML) кооперации называют реализациями элементов Use Case, да и обозначения их весьма схожи (рис. 8).

    

    Рис. 8. Элемент Use Case и его реализация

    Обратите  внимание на то, что и связаны  эти элементы отношением реализации: кооперация реализует конкретный элемент Use Case.

    Кооперации  содержат две составляющие — статическую (структурную) и динамическую (поведенческую).

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

    Таким образом, если заглянуть под «обложку»  кооперации, мы увидим набор разнообразных  диаграмм. Например, требования к информационной системе авиакассы задаются множеством элементов Use Case, каждый из которых реализуется  отдельной кооперацией. Все эти  кооперации применяют одни и те же классы, но все же имеют разную функциональную организацию. В частности, поведение  кооперации для заказа авиабилета может  описываться диаграммой последовательности, показанной на рис. 9.

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

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

    

    Рис. 9. Динамическая составляющая кооперации Заказ авиабилета

    

    Рис. 10. Статическая составляющая кооперации Заказ авиабилета

    

    Рис. 11. Обозначение паттерна

    Параметризованные, то есть настраиваемые кооперации называют паттернами (образцами). Паттерн является решением типичной проблемы в определенном контексте. Обозначение паттерна имеет  вид, представленный на рис. 11.

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

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

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

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

    Таблица 1. Описание паттерна

    Обсудим применение нескольких паттернов из каталога «Команды четырех».

    Паттерн Наблюдатель

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

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

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

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

    

    Рис. 12. Различные графические  отображения состояния  субъекта

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

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

    Динамическая  составляющая паттерна Наблюдатель  показана на рис. 14. На рисунке представлено поведение паттерна при взаимодействии субъекта с двумя наблюдателями.

    

    Рис. 13. Структурная составляющая паттерна Наблюдатель

    

    Рис. 14. Динамическая составляющая паттерна Наблюдатель

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