Поможем написать учебную работу
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.

Предоплата всего

Подписываем
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Цели и задачи темы:
Объектно-ориентированный анализ (ООА) ― методология разработки программных систем, в основу которой положена концепция представления моделей предметной области в форме классов, обладающих структурными свойствами и поведением.
Класс ― абстракция совокупности реальных объектов, которые имеют общий набор свойств и обладают одинаковым поведением.
Базовые принципы ООАП: наследование, инкапсуляция, полиморфизм.
Классы организуются в виде иерархической структуры. Иерархия служит иллюстрацией принципа наследования.
Инкапсуляция ― сокрытие отдельных деталей реализации. Для осуществления взаимодействия экземпляров класса с внешним окружением формируется интерфейс (рис.1).
ИНТЕРФЕЙС
РЕАЛИЗАЦИЯ
ПОЛЬЗОВАТЕЛЬ
РАЗРАБОТЧИК
Рисунок 1
Полиморфизм ― свойство одноименных методов выполнять различные действия в зависимости от того, к какому из классов они относятся.
Усилия Гради Буча (Grady Booch), Джима Румбаха (Jim Rumbaugh) и Айвара Джекобсона (Ivar Jacobson) привели к появлению языка UML (Unified Modeling language) ― унифицированного языка моделирования.
UML унифицированный язык визуального моделирования, предназначенный для спецификации, визуализации и документирования объектно-ориентированных систем во время их проектирования и разработки.
Состояние последней версии языка UML 2.1.1 и ход работы по его развитию отражается на официальном сайте консорциума OMG www.omg.org.
В терминах языка UML определены следующие типы диаграмм:
Диаграммы структуры (Structure Diagrams):
Диаграммы поведения (Behavior Diagrams):
Диаграммы взаимодействия (Interaction Diagram):
Исходной моделью, с которой начинается процесс моделирования в ООА, является диаграмма вариантов использования. Диаграмма описывает функциональное назначение системы в общем виде с точки зрения всех ее пользователей.
В нотации UML 2.1.1 для диаграмм Use Case различают понятия:
Если проектируемая система является масштабной, то возможна ее декомпозиция на отдельные подсистемы ― субъекты вариантов использования. Графически субъект изображается прямоугольником с именем. Использование этого понятия необязательно.
Вариант использования (use case2) описывает, с точки зрения действующего лица, группу действий в системе, которые приводят к конкретному результату. Варианты использования являются описаниями типичных взаимодействий между пользователями системы и самой системой. Они отображают внешний интерфейс системы и указывают то, что система должна сделать (именно что, а не как).
При работе с вариантами использования важно помнить некоторые правила:
Графическим изображением варианта использования является эллипс, внутри которого или ниже его записывается имя в форме строки текста, начинающегося, как правило, с существительного или глагола.
Примеры названий вариантов использования: Проконсультировать, Заключить договор страхования, Выплата страхового возмещения.
Действующее лицо (actor)3 является внешним источником, который взаимодействует с системой через вариант использования. Действующие лица могут быть пользователями системы или другими компьютерными системами. Актер обязательно имеет имя.
Комментарий (comment, note) предназначен для описания произвольной текстовой информации, которая может быть присоединена к одному или нескольким элементам модели. Графически комментарии изображаются прямоугольниками с «загнутым» верхним уголком.
Между элементами диаграммы могут быть установлены различные отношения. Это отношения ассоциации, обобщения, зависимости (частные случаи зависимости: включение и расширение).
В диаграмме Use Case ассоциация (association) является бинарной, обозначается сплошной линией (рис 2.а). Если направление отношения имеет смысл, то используется направленная ассоциация (рис. 2,3).
Рисунок 2
Рисунок 3
Направленная ассоциация позволяет ввести понятие основного актера (он является инициатором ассоциации) и второстепенного актера (прецедент является инициатором, т.е. передает актеру справочные сведения или отчет о выполненной работе).
Особенности использования отношения ассоциации в модели вариантов использования:
Общее отношение зависимости (dependency) определяет, что изменение одного элемента модели приводит к изменению другого элемента. Зависимость является направленным бинарным отношением, которое связывает между собой независимый и зависимый элементы отношения. Графическое изображение пунктирная стрелка (рис. 4).
Рисунок 4
Отношение включения (include)- частный случай общего отношения зависимости между двумя вариантами использования, при котором один вариант использования содержит поведение, определенное в другом варианте использования. Графическое изображение пунктирная стрелка с ключевым словом <<include>> (рис.5).
Рисунок 5
Зависимый прецедент называют базовым, независимый включаемым. На рис.5 каждое выполнение прецедента А всегда будет включать в себя выполнение прецедента Б4.
На практике отношение включения используется для моделирования ситуации, когда существует общая часть поведения двух или более прецедентов. Общая часть выносится в отдельный прецедент, т.е. типичный пример повторного использования функциональности.
Особенности использования отношения включения:
Отношение расширения (extend) другой частный случай общего отношения зависимости между двумя вариантами использования. Отношение расширения определяет взаимосвязь одного прецедента с некоторым другим прецедентом, функциональность которого задействуется первым не всегда, а только при выполнении некоторых дополнительных условий.
Отношение расширения является бинарным отношением, графически изображаемым с помощью направленной пунктирной линии со стрелкой, направленной от зависимого варианта (расширяющего) к независимому варианту (базовому) (рис.6). Отношение помечается ключевым словом <<extend>>.
Рисунок 6
На рис.6 прецедент «Оформление заказа» базовый прецедент, он может быть расширен прецедентом «Предоставление скидки» при наличии, например, у покупателя бонусной карточки.
В общем случае отношение расширения позволяет моделировать тот факт, что базовый вариант использования А может присоединять к своему поведению некоторое дополнительное поведение, определенное в форме расширения в варианте Б.
Наличие данного отношения предполагает проверку условия в точке расширения в базовом варианте использования. Графически точка расширения может быть изображена с помощью примечания (рис.7).
Рисунок 7
Особенности использования отношения расширения:
Отношение обобщения (generalization) предназначено для спецификации того факта, что один элемент модели является специальным или частным случаем другого элемента модели.
Графическое изображение отношения обобщения показано на рис.8. Применительно к этому фрагменту можно сказать, что прецедент Б является специализацией прецедента А. При этом прецедент А называется предком или родителем, а прецедент Б потомком или дочерним по отношению к прецеденту А.
Рисунок 8
Отношение обобщения показывает, что дочерние варианты использования обладают всеми особенностями поведения родительских вариантов, но могут иметь новые свойства поведения, которые отсутствуют у родительских прецедентов, а также могут изменять наследуемые от родителей свойства поведения.
Особенности использования отношения обобщения:
Между актерами также могут существовать отношения обобщения. Данное отношение является направленным и указывает на факт специализации одних актеров относительно других (рис.9).
Рисунок 9
Рассмотрим диаграмму вариантов использования для интернет-магазина (рис.10).
Рисунок 10
Спецификация требований с помощью текстовых сценариев
Действия актеров |
Отклик системы |
|
|
|
|
|
|
|
|
|
|
2 В литературе можно встретить различные переводы термина use case, например прецедент, функция.
3 В литературе можно встретить различные переводы термина actor, например пользователь, субъект, роль, актант, эктор.
4 Аналогично выполнению подпрограммы в программировании.