Лекция 4. Объектно-ориентированный анализ

Объектно-ориентированный анализ (ООА) ― методология разработки программных систем, в основу которой положена концепция представления моделей предметной области в форме классов, обладающих структурными свойствами и поведением.

Класс ― абстракция совокупности реальных объектов, которые имеют общий набор свойств и обладают одинаковым поведением.

Базовые принципы ООАП: наследование, инкапсуляция, полиморфизм.

Классы организуются в виде иерархической структуры. Иерархия служит иллюстрацией принципа наследования.

Инкапсуляция ― сокрытие отдельных деталей реализации. Для осуществления взаимодействия экземпляров класса с внешним окружением формируется интерфейс (рис.1).

Рисунок 1

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

Усилия Гради Буча (Grady Booch), Джима Румбаха (Jim Rumbaugh) и Айвара Джекобсона (Ivar Jacobson) привели к появлению языка UML (Unified Modeling language) ― унифицированного языка моделирования.

UML ‑ унифицированный язык визуального моделирования, предназначенный для спецификации, визуализации и документирования объектно-ориентированных систем во время их проектирования и разработки.

Состояние последней версии языка UML 2.1.1 и ход работы по его развитию отражается на официальном сайте консорциума OMG www.omg.org.

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

Диаграммы структуры (Structure Diagrams):

· диаграмма классов (Class Diagram);

· диаграмма композитной структуры (Composite Structure Diagram);

· диаграмма пакетов (Package Diagram);

· диаграмма объектов(Object Diagram);

· диаграмма компонентов(Component Diagram);

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

Диаграммы поведения (Behavior Diagrams):

· диаграмма вариантов использования(Use Case Diagram);

· диаграмма деятельности(Activity Diagram);

· диаграмма конечного автомата (State Machine Diagram).

Диаграммы взаимодействия (Interaction Diagram):

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

· диаграмма коопераций (Collaboration Diagram);

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

В нотации UML 2.1.1 для диаграмм Use Case различают понятия:

· актер (actor),

· вариант использования (use case),

· субъект (subject).

Если проектируемая система является масштабной, то возможна ее декомпозиция на отдельные подсистемы ― субъекты вариантов использования. Графически субъект изображается прямоугольником с именем. Использование этого понятия необязательно.

Вариант использования (use case[1]) описывает, с точки зрения действующего лица, группу действий в системе, которые приводят к конкретному результату. Варианты использования являются описаниями типичных взаимодействий между пользователями системы и самой системой. Они отображают внешний интерфейс системы и указывают то, что система должна сделать (именно что, а не как).

При работе с вариантами использования важно помнить некоторые правила:

· Каждый вариант использования относится как минимум к одному действующему лицу.

· Каждый вариант использования имеет инициатора.

· Каждый вариант использования приводит к соответствующему результату (результату с «бизнес-значением»).

Графическим изображением варианта использования является эллипс, внутри которого или ниже его записывается имя в форме строки текста, начинающегося, как правило, с существительного или глагола.

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

Действующее лицо (actor)[2] является внешним источником, который взаимодействует с системой через вариант использования. Действующие лица могут быть пользователями системы или другими компьютерными системами. Актер обязательно имеет имя.

Комментарий (comment, note) предназначен для описания произвольной текстовой информации, которая может быть присоединена к одному или нескольким элементам модели. Графически комментарии изображаются прямоугольниками с «загнутым» верхним уголком.

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

В диаграмме Use Case ассоциация (association) является бинарной, обозначается сплошной линией (рис 2.а). Если направление отношения имеет смысл, то используется направленная ассоциация (рис. 2,3).

Рисунок 2

Рисунок 3

Направленная ассоциация позволяет ввести понятие основного актера (он является инициатором ассоциации) и второстепенного актера (прецедент является инициатором, т.е. передает актеру справочные сведения или отчет о выполненной работе).

Особенности использования отношения ассоциации в модели вариантов использования:

1. Один прецедент может иметь несколько ассоциаций с различными актерами.

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

Общее отношение зависимости (dependency) определяет, что изменение одного элемента модели приводит к изменению другого элемента. Зависимость является направленным бинарным отношением, которое связывает между собой независимый и зависимый элементы отношения. Графическое изображение ­ пунктирная стрелка (рис. 4).

Рисунок 4

Отношение включения (include)- частный случай общего отношения зависимости между двумя вариантами использования, при котором один вариант использования содержит поведение, определенное в другом варианте использования. Графическое изображение ­ пунктирная стрелка с ключевым словом <<include>> (рис.5).

Рисунок 5

Зависимый прецедент называют базовым, независимый ­ включаемым. На рис.5 каждое выполнение прецедента А всегда будет включать в себя выполнение прецедента Б[3].

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

Особенности использования отношения включения:

1. Один базовый вариант использования может быть связан отношением включения с несколькими включаемыми вариантами использования.

2. Один вариант использования может быть включен в другие варианты использования.

3. На одной диаграмме вариантов использования не может быть замкнутого пути по отношению включения.

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

Отношение расширения является бинарным отношением, графически изображаемым с помощью направленной пунктирной линии со стрелкой, направленной от зависимого варианта (расширяющего) к независимому варианту (базовому) (рис.6). Отношение помечается ключевым словом <<extend>>.

Рисунок 6

На рис.6 прецедент «Оформление заказа» – базовый прецедент, он может быть расширен прецедентом «Предоставление скидки» при наличии, например, у покупателя бонусной карточки.

В общем случае отношение расширения позволяет моделировать тот факт, что базовый вариант использования А может присоединять к своему поведению некоторое дополнительное поведение, определенное в форме расширения в варианте Б.

Наличие данного отношения предполагает проверку условия в точке расширения в базовом варианте использования. Графически точка расширения может быть изображена с помощью примечания (рис.7).

Рисунок 7

Особенности использования отношения расширения:

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

2. Расширяющий вариант использования может быть связан отношениями расширения с несколькими базовыми вариантами использования.

3. Расширяющий вариант использования может иметь собственные расширяющие варианты использования.

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

Отношение обобщения (generalization) предназначено для спецификации того факта, что один элемент модели является специальным или частным случаем другого элемента модели.

Графическое изображение отношения обобщения показано на рис.8. Применительно к этому фрагменту можно сказать, что прецедент Б является специализацией прецедента А. При этом прецедент А называется предком или родителем, а прецедент Б ­ потомком или дочерним по отношению к прецеденту А.

Рисунок 8

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

Особенности использования отношения обобщения:

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

2. Один прецедент может иметь несколько родительских прецедентов (множественное наследование).

3. Один вариант использования может быть предком для нескольких дочерних вариантов использования (таксономический характер отношений).

Между актерами также могут существовать отношения обобщения. Данное отношение является направленным и указывает на факт специализации одних актеров относительно других (рис.9).

Рисунок 9

Рассмотрим диаграмму вариантов использования для интернет-магазина (рис.10).

Рисунок 10

Спецификация требований с помощью текстовых сценариев

[1] В литературе можно встретить различные переводы термина use case, например ­ прецедент, функция.

[2] В литературе можно встретить различные переводы термина actor, например ­ пользователь, субъект, роль, актант, эктор.

[3] Аналогично выполнению подпрограммы в программировании.

Поиск по сайту: