 |
Уточнение модели требований
|
|
|
|
Уточнение модели сводится к выявлению одинаковых частей в элементах Use Case и извлечению этих частей. Любые изменения в такой части, выделенной в отдельный элемент Use Case, будут автоматически влиять на все элементы Use Case, которые используют ее совместно.
Извлеченные элементы Use Case называют абстрактными. Они не могут быть конкретизированы сами по себе, применяются для описания одинаковых частей в других, конкретных элементах Use Case. Таким образом, описания абстрактных элементов Use Case используются в описаниях конкретных элементов Use Case. Говорят, что конкретный элемент Use Case находится в отношении «включает» с абстрактным элементом Use Case.
Вернемся к нашему примеру. В этом примере два конкретных элемента Use Case Возврат элемента и Создание дневного отчета имеют общую часть — действия, обеспечивающие печать квитанции. Поэтому, как показано на рис. 12.40, можно выделить абстрактный элемент Use Case Печать. Этот элемент Use Case будет специализироваться на выполнении распечаток.
Рис. 12.40. Применение отношения включения
В свою очередь, абстрактные элементы Use Case могут использоваться другими абстрактными элементами Use Case. Так образуется иерархия. При построении иерархии абстрактных элементов Use Case руководствуются правилом: выделение элементов Use Case прекращается при достижении уровня отдельных операций над объектами.
Выделение абстрактных элементов Use Case можно упростить с помощью абстрактных актеров.
Абстрактный актер — это общий фрагмент роли в нескольких конкретных актерах. Абстрактный актер выражает подобия в элементах Use Case. Конкретные актеры находятся в отношении наследования с абстрактным актером. Так, в машине утилизации конкретные актеры имеют одно общее поведение: они могут получать квитанцию. Поэтому можно определить одного абстрактного актера — Получателя квитанции. Как показано на рис. 12.41, наследниками этого актера являются Потребитель и Оператор.
|
|
|
Рис. 12.41. Выделение абстрактного актера
Выводы:
1. Абстрактные элементы Use Case находят извлечением общих последовательностей из различных элементов Use Case.
2. Отношение «включает» применяется, если несколько элементов Use Case имеют общее поведение. Цель: устранить повторения, ликвидировать избыточность.
3. Кроме того, это отношение часто используют для ограничения сложности большого элемента Use Case.
4. Отношение «расширяет» применяется, когда описывается вариация, дополняющая нормальное поведение.
Кооперации и паттерны
Кооперации (сотрудничества) являются средством представления комплексных решений в разработке ПО на высшем, архитектурном уровне. С одной стороны, ^ кооперации обеспечивают компактность цельной спецификации программного продукта, с другой стороны — несут в себе реализации потоков управления и данных, а также структур данных.
В терминологии фирмы Rational (вдохновителя и организатора побед языка UML) кооперации называют реализациями элементов Use Case, да и обозначения их весьма схожи (рис. 12.42).
Рис. 12.42. Элемент Use Case и его реализация
Обратите внимание на то, что и связаны эти элементы отношением реализации: кооперация реализует конкретный элемент Use Case.
Кооперации содержат две составляющие — статическую (структурную) и динамическую (поведенческую).
Статическая составляющая кооперации задает структуру совместно работающих классов и других элементов (интерфейсов, компонентов, узлов). Чаще всего для этого используют одну или несколько диаграмм классов. Динамическая составляющая кооперации определяет поведение совместно работающих элементов. Обычно для определения применяют одну или несколько диаграмм последовательности.
|
|
|
Таким образом, если заглянуть под «обложку» кооперации, мы увидим набор разнообразных диаграмм. Например, требования к информационной системе авиакассы задаются множеством элементов Use Case, каждый из которых реализуется отдельной кооперацией. Все эти кооперации применяют одни и те же классы, но все же имеют разную функциональную организацию. В частности, поведение кооперации для заказа авиабилета может описываться диаграммой последовательности, показанной на рис. 12.43.
Соответственно, структура кооперации для заказа авиабилета может иметь вид, представленный на рис. 12.44.
Важно понимать, что кооперации отражают понятийный аспект архитектуры системы. Один и тот же элемент может участвовать в различных кооперациях. Ведь речь здесь идет не о владении элементом, а только о его применении.
Рис. 12.43. Динамическая составляющая кооперации Заказ авиабилета
Рис. 12.44. Статическая составляющая кооперации Заказ авиабилета
Рис. 12.45. Обозначение паттерна
Параметризованные, то есть настраиваемые кооперации называют паттернами (образцами). Паттерн является решением типичной проблемы в определенном контексте. Обозначение паттерна имеет вид, представленный на рис. 12.45.
На место параметров настройки паттерна подставляются различные фактические параметры, в результате создаются разные кооперации.
Паттерны рассматриваются как крупные строительные блоки. Их использование приводит к существенному сокращению затрат на анализ и проектирование ПО. повышению качества и правильности разработки на логическом уровне, ведь паттерны создаются опытными профессионалами и отражают проверенные и оптимизированные решения [26], [31], [68].
Итак, паттерны — это наборы готовых решений, рецепты, предлагающие к повторному использованию самое ценное для разработчика — сплав мирового опыта по созданию ПО.
Наиболее распространенные паттерны формализуют и сводят в единые каталоги. Самым известным каталогом проектных паттернов, обеспечивающих этап проектирования ПО, считают каталог «Команды четырех» (Э. Гамма и др.). Он включает в себя 23 паттерна, разделенные на три категории [31]. Как показано в табл. 12.1, по мнению «Команды четырех», описание паттерна должно состоять из четырех основных частей.
|
|
|
Таблица 12.1. Описание паттерна
| Раздел | Описание |
| Имя Проблема Решение Результаты | Выразительное имя паттерна дает возможность указать проблему проектирования, ее решение и последствия ее решения. Использование имен паттернов повышает уровень абстракции проектирования Формулируется проблема проектирования (и ее контекст), на которую ориентировано применение паттерна. Задаются условия применения Описываются элементы решения, их отношения, обязанности, сотрудничество. Решение представляется в обобщенной форме, которая должна конкретизироваться при применении. Фактически приводится шаблон решения — его можно использовать в самых разных ситуациях Перечисляются следствия применения паттерна и вытекающие из них компромиссы. Такая информация позволяет оценить эффективность применения паттерна в данной ситуации |
Обсудим применение нескольких паттернов из каталога «Команды четырех».
Паттерн Наблюдатель
Паттерн Наблюдатель (Observer) задает между объектами такую зависимость «один-ко-многим», при которой изменение состояния одного объекта приводит к оповещению и автоматическому обновлению всех зависящих от него объектов.
Проблема. При разбиении системы на набор совместно работающих объектов появляется необходимость поддерживать их согласованное состояние. При этом желательно минимизировать сцепление, так как высокое сцепление уменьшает возможности повторного использования. Например, во многих случаях требуется отображение данных состояния в различных графических формах и форматах. При этом объекту, формирующему состояние, не нужно знать о формах его отображения — отсутствие такого интереса благотворно влияет на необходимое сцепление. Паттерн Наблюдатель можно применять в следующих случаях:
q когда необходимо организовать непрямое взаимодействие объектов уровня логики приложения с интерфейсом пользователя. Таким образом достигается низкое сцепление между уровнями;
|
|
|
q когда при изменении состояния одного объекта должны изменить свое состояние все зависимые объекты, причем количество зависимых объектов заранее неизвестно;
q когда один объект должен рассылать сообщения другим объектам, не делая о них никаких предположений. За счет этого образуется низкое сцепление между объектами.
Решение. Принцип решения иллюстрирует рис. 12.46. Ключевыми элементами решения являются субъект и наблюдатель. У субъекта может быть любое количество зависимых от него наблюдателей. Когда происходят изменения в состоянии субъекта, наблюдатели автоматически об этом уведомляются. Получив уведомление, наблюдатель опрашивает субъекта, синхронизуя с ним свое отображение состояния.
Рис. 12.46. Различные графические отображения состояния субъекта
Такое взаимодействие между элементами соответствует схеме издатель-подписчик. Издатель рассылает сообщения об изменении своего состояния, не имея никакой информации о том, какие объекты являются подписчиками. На получение таких уведомлений может подписаться любое количество наблюдателей.
Структурная составляющая паттерна Наблюдатель представлена на рис. 12.47. В ней определены два абстрактных класса, Субъект и Наблюдатель. Кроме того, здесь показаны два конкретных класса, КонкрСубъект и КонкрНаблюдатель, которые наследуют свойства и операции абстрактных классов. Они подключаются к паттерну в процессе его настройки. Состояние формируется Конкретным субъектом, который унаследовал от Субъекта операции, позволяющие ему добавлять и удалять Конкретных наблюдателей, а также уведомлять их об изменении своего состояния. Конкретный наблюдатель автоматически отображает состояние и реализует абстрактную операцию Обновить() Наблюдателя, обеспечивающую обновление отображаемого состояния.
ПРИМЕЧАНИЕ
Курсивом в данном абзаце отображены имена абстрактных классов и операций (это требование языка UML).
Динамическая составляющая паттерна Наблюдатель показана на рис. 12.48. На рисунке представлено поведение паттерна при взаимодействии субъекта с двумя наблюдателями.
Рис. 12.47. Структурная составляющая паттерна Наблюдатель
Рис. 12.48. Динамическая составляющая паттерна Наблюдатель
Результаты. Субъекту известно только об абстрактном наблюдателе, он ничего не знает о конкретных наблюдателях. В результате между этими объектами устанавливается минимальное сцепление (это достоинство). Изменения в субъекте могут привести к неоправданно большому количеству обновлений наблюдателей — ведь наблюдателю неизвестно, что именно изменилось в субъекте, затрагивают ли его произошедшие изменения (это недостаток).
|
|
|
Обозначение паттерна Наблюдатель приведено на рис. 12.49, где показано, что у него два параметра настройки — субъект и наблюдатель.
Рис. 12.49. Обозначение паттерна Наблюдатель
Эти параметры обозначают роли, которые будут играть конкретные классы, используемые при настройке паттерна на конкретное применение. Например, настройку паттерна на отображение текущего фильма кинофестиваля иллюстрирует рис. 12.50.
Рис. 12.50. Настройка паттерна Наблюдатель
Видим, что подключаемые конкретные классы (Кинопрограмма, Текущий фильм) соединяются с символом паттерна пунктирными линиями. Каждая пунктирная линия подписана ролью (именем параметра), которую играет конкретный класс в формируемой кооперации. Таким образом, в данном случае класс Кинопрограмма становится подклассом абстрактного класса Субъект в паттерне, а класс Текущий фильм — подклассом абстрактного класса Наблюдатель в паттерне.
Паттерн Компоновщик
Паттерн Компоновщик (Composite) обеспечивает представление иерархий часть-целое, объединяя объекты в древовидные структуры.
Проблема. Очень часто возникает необходимость создавать маленькие компоненты (примитивы), объединять их в более крупные компоненты (контейнеры), более крупные компоненты соединять в большие компоненты, большие компоненты — в огромные и т. д. При этом клиентам приходится различать компоненты-примитивы и компоненты-контейнеры, работать с ними по-разному. Это усложняет приложение. Паттерн Компоновщик позволяет ликвидировать это различие, его можно применять в следующих случаях:
q необходимо построить иерархию объектов вида часть-целое;
q нужно унифицировать использование как составных, так и индивидуальных объектов.
Решение. Ключевым элементом решения является абстрактный класс Компонент, который является одновременно и примитивом, и контейнером. В нем объявлены:
q абстрактная операция примитива Работать ();
q абстрактные операции контейнера — управления примитивами-потомками Добавить(Компонент) и Удалить(Компонент), а также доступа к потомку Получить-Потомка ().
Структурная составляющая паттерна Компоновщик представлена на рис. 12.51.
Рис. 12.51. Структурная составляющая паттерна Компоновщик
Из рисунка видно, что с помощью паттерна организуется рекурсивная композиция.
Класс Компонент служит простым элементом дерева, класс Компоновщик является рекурсивным элементом, а класс Лист — конечным элементом дерева. Класс Компонент служит родителем классов Лист и Компоновщик. Отметим, что класс Компоновщик является агрегатом составных частей — экземпляров класса Компонент (таким образом задается рекурсия).
Клиенты используют интерфейс класса Компонент для взаимодействия с объектами дерева. Если получателем запроса клиента является объект-лист, то он и обрабатывает запрос. Если же получателем является составной объект-компоновщик, то он перенаправляет запрос своим потомкам, возможно выполняя дополнительные действия до или после перенаправления.
Результаты. Паттерн определяет иерархии, состоящие из классов-примитивов и классов-контейнеров, облегчает добавление новых разновидностей компонентов. Он упрощает организацию клиентов (клиент не должен учитывать специфику адресуемого объекта). Недостаток применения паттерна — трудность в наложении ограничений на объекты, которые можно включать в композицию.
Обозначение паттерна Компоновщик приведено на рис. 12.52, где показано, что у него три параметра настройки — компонент, компоновщик и лист.
Настройку паттерна на графическое приложение иллюстрирует рис. 12.53.
Рис. 12.52. Обозначение паттерна Компоновщик
Рис. 12.53. Настройка паттерна Компоновщик
В этом случае основной операцией приложения становится операция Рисовать(). Подразумевается, что такая операция входит в состав каждого из подключаемых классов, то есть классов Рисунок, Прямоугольник и Графический элемент. Операции Рисовать() должны заместить операции Работать() в классах паттерна.
Паттерн Команда
Паттерн Команда (Command) выполняет преобразование запроса в объект, обеспечивая:
q параметризацию клиентов с различными запросами;
q постановку запросов в очередь и их регистрацию;
q поддержку отмены операций.
Проблема. Достаточно часто нужно посылать запрос, не зная, выполнение какой конкретной операции запрошено и кто является получателем запроса. В этих случаях следует отделить объект, инициирующий запрос, от объекта, способного выполнить запрос. В результате обеспечивается высокая гибкость разработки пользовательского интерфейса — можно связывать различные пункты меню с определенной функцией, динамически подменять команды и т. д. Паттерн Команда применяется в следующих случаях:
q объекты параметризируются действием. В процедурных языках параметризация осуществляется при помощи функции обратного вызова, которая регистрируется для последующего вызова. Паттерн Команда предлагает объектно-ориентированную замену функций обратного вызова;
q необходимо обеспечить отмену операций. Это возможно благодаря хранению истории выполнения операций;
q необходимо регистрировать изменения состояния для восстановления системы в случае аварийного отказа;
q необходимо создание сложных операций, которые строятся на основе примитивных операций.
Решение. Основным элементом решения является абстрактный класс Команда, обеспечивающий одну абстрактную операцию Выполнять (). Конкретные подклассы этого класса реализуют операцию Выполнять(). Они задают пару получатель-действие. Получатель запоминается в экземплярной переменной подкласса. Запрос получателю посылается в ходе исполнения конкретной операции Выполнять().
Структурная составляющая паттерна Команда показана на рис. 12.54. Классы этой структуры имеют следующие обязанности:
q Команда объявляет интерфейс для выполнения операции;
q КонкрКоманда определяет связь между экземпляром класса Получатель и действием, реализует Выполнять(), вызывая нужную операцию получателя;
q Клиент создает объект класса КонкрКоманда и устанавливает его получателя;
q Инициатор просит команду выполнить запрос;
q Получатель умеет выполнять запрашиваемые операции.
Рис. 12.54. Структурная составляющая паттерна Команда
В качестве конкретной команды могут выступать команда Открыть, команда Вставить. Инициатором может быть Пункт Меню, а получателем — Документ.
Объекты этого паттерна осуществляют следующие взаимодействия:
q клиент создает объект класса КонкрКоманда и задает его получателя;
q объект класса Инициатор сохраняет объект класса КонкрКоманда;
q инициатор вызывает операцию Выполнять() объекта класса КонкрКоманда;
q объект класса КонкрКоманда вызывает операцию своего получателя для исполнения запроса.
Результаты. Применение паттерна Команда приводит к следующему:
q объект, запрашивающий операцию, отделяется от объекта, умеющего выполнять запрос;
q объекты-команды являются полноценными объектами. Их можно использовать и расширять обычным способом;
q из простых команд легко компонуются составные команды;
q легко добавляются новые команды (изменять существующие классы при этом не требуется).
Обозначение паттерна Команда приведено на рис. 12.55, где показано, что у него четыре параметра настройки — клиент, команда, инициатор и получатель.
Рис. 12.55. Обозначение паттерна Команда
Настройку паттерна на приложение с графическим меню иллюстрирует рис. 12.56.
Рис. 12.56. Настройка паттерна Команда
Очевидно, что в получаемой кооперации конкретный класс Редактор играет роль клиента, классы КомандаОткрыть и КомандаВставить становятся классами Конкретных Команд (и подклассами абстрактного класса Команда), класс ПунктМеню замещает класс Инициатор паттерна, а конкретный класс Документ замещает класс Получатель паттерна.
Бизнес-модели
Достаточно часто перед тем, как решиться на заказ ПО, организация проводит бизнес-моделирование. Цели бизнес-моделирования:
q отобразить структуру и процессы деятельности организации;
q обеспечить ясное, комплексное и, главное, одинаковое понимание нужд организации как сотрудниками, так и будущими разработчиками ПО;
q сформировать реальные требования к программному обеспечению деятельности организации.
Для достижения этих целей разрабатываются две модели: Q бизнес-модель Use Case; а бизнес-объектная модель.
Бизнес-модель Use Case задает внешнее представление бизнес-процессов организации (с точки зрения внешней среды — клиентов и партнеров).
Как показано на рис. 12.57, бизнес-модель Use Case строится с помощью бизнес-актеров и бизнес-элементов Use Case — простого расширения средств, используемых в обычных диаграммах Use Case.
Рис. 12.57. Фрагмент бизнес-модели Use Case для аэропорта
Бизнес-актеры определяют внешние сущности и людей, с которыми взаимодействует бизнес. Бизнес-актер представляет собой человека, но информационная система, взаимодействующая с бизнесом, также может играть роль такого актера.
Бизнес-элементы Use Case изображают различные рабочие потоки бизнеса. Последовательности действий в бизнес-элементах Use Case обычно описываются диаграммами деятельности.
Бизнес-объектная модель отражает внутреннее представление бизнес-процессов организации (с точки зрения ее сотрудников).
Как показано на рис. 12.58, бизнес-объектная модель строится с помощью бизнес-работников и бизнес-сущностей — классов со специальными стереотипами. Эти классы имеют специальные графические обозначения.
Рис. 12.58. Фрагмент бизнес-объектной модели аэропорта
Бизнес-работник — абстракция человека, действующего в бизнесе. Бизнес-сущности являются «предметами», обрабатываемыми или используемыми бизнес-работниками по мере выполнения бизнес-элемента Use Case. Например, бизнес-сущность представляет собой документ или существенную часть продукта. Фактически бизнес-объектная модель отображается с помощью диаграмм классов.
Контрольные вопросы
1. Поясните два подхода к моделированию поведения системы. Объясните достоинства и недостатки каждого из этих подходов.
2. Охарактеризуйте вершины и дуги диаграммы схем состояний. В чем состоит назначение этой диаграммы?
3. Как отображаются действия в состояниях диаграммы схем состояний?
4. Как показываются условные переходы между состояниями?
5. Как задаются вложенные состояния в диаграммах схем состояний?
6. Поясните понятие исторического подсостояния.
7. Охарактеризуйте средства и возможности диаграммы деятельности.
8. Когда не следует применять диаграмму деятельности?
9. Какие средства диаграммы деятельности позволяют отобразить параллельные действия?
10. Зачем в диаграмму деятельности введены плавательные дорожки?
11. Как представляется имя объекта в диаграмме сотрудничества?
12. Поясните синтаксис представления свойства в диаграмме сотрудничества.
13. Какие стереотипы видимости используются в диаграмме сотрудничества? Поясните их смысл.
14. В какой форме записываются сообщения в языке UML? Поясните смысл сообщения.
15. В каком отношении находятся сообщения и действия? Перечислите разновидности действий.
16. Чем отличается процедурный поток от асинхронного потока сообщений?
17. Как указывается повторение сообщений?
18. Как показать ветвление сообщений?
19. Что общего в диаграмме последовательности и диаграмме сотрудничества? Чем они отличаются друг от друга?
20. Как отображается порядок передачи сообщений в диаграмме последовательности?
21. Когда удобнее применять диаграммы последовательности?
22. Из каких элементов состоит диаграмма Use Case?
23. Какие отношения разрешены между элементами диаграммы Use Case?
24. Для чего применяют диаграммы Use Case?
25. Чем отличаются друг от друга отношения включения и расширения с точки зрения управления?
26. Каково назначение спецификации элемента Use Case и как она оформляется?
27. Что такое сценарий элемента Use Case?
28. Как документируется отношение включения?
29. Как документируется отношение расширения?
30. Каков порядок построения модели требований?
31. Каково назначение кооперации? Какие составляющие ее образуют?
32. Могут ли разные кооперации использовать одинаковые классы? Обоснуйте ответ.
33. Что такое паттерн?
34. Чем паттерн отличается от кооперации? Чем они схожи?
35. Как описывается паттерн?
36. Что нужно сделать для применения паттерна?
37. Каковы цели бизнес-моделирования?
38. Из каких частей состоит бизнес-модель? На что похожи эти части? В чем их своеобразие?
|
|
|
