- •Абстаркция и абсттрагирование
- •Архитектура программной системы.
- •Объектно-ориентированный анализ
- •Объектно-ориентированное проектирование
- •Объектно-ориентированное программирование
- •Аналитическая модель
- •Алгоритмическая и объектно-ориентированная декомпозиция
- •Сложность программных систем. Основные причины, признаки сложной системы.
- •Понятие итеративного цикла разработки. Участники процесса разработки программного обеспечения.
- •Класс, объект. Состояние объекта. Поведение объекта.
- •Расширения uml: ограничения (constraint), стереотипы (stereotypes) и именованные
- •Агрегация и композиция. Их назначение и отличия
- •Понятие итеративного цикла разработки. Участники процесса разработки программного
- •Основные этапы разработки программного обеспечения (Анализ, проектирование,
- •Понятие стереотипов концептуальной модели (boundary, control, entity)
- •16. Язык um, назначение и структура языка uml. Визуальное моделирование
- •17. Интегрированная модель сложной системы
- •18. Модель системы в Rational Rose (Use Case View, Logical View, Component View, Deployment View)
- •Назначение диаграммы компонентов.
- •Диаграммы размещения (Deployment Diagram). Назначение, основные элементы (Processor, Device, Connection).
- •19. Анализ предметной области. Идентификация и систематизация функций системы. Атрибуты системы. Скрытые и типовые функции. Функции бизнес-логики
- •20. Модульность программной системы. Понятие и назначение Package. Отношения между Package. Организационные диаграммы.
- •21. Вариант использования (Use Case). Абстрактный вариант использования.
- •22. Диаграммы вариантов использования. Назначение. Основные элементы (Text Box, Use Case, Note, Anchor Note, Actor, Package)
- •23. Связи на диаграмме Вариантов Использования (Association, Unidirectional Association, Generalization, Extend use case, Include use case).
- •24. Сценарии use case. Описание (потоки событий) и назначение сценариев
- •25 Диаграммы деятельности. Назначение. Основные элементы (Activity, State, Start State, Stop State, State Transition, State to self, Synchronization, Decision, Swimlane)
- •26. Диаграммы последовательности (Sequence Diagram). Назначение, основные элементы (Object, Object Message, Message to Self) Соотнесение объектов с классами, сообщение с операциями.
- •27. Кооперативные диаграммы (Collaboration). Назначение, основные элементы (Object, Class Instance, Object Link, Link to Self, (Reverse) Link Message, (Reverse) Data Flow
- •28. Диаграммы классов (Class Diagram). Назначение, основные элементы (Class, Association, Dependency, Aggregation, Generalization). Атрибуты и операции, множественность (multiplicity) и роли
- •Назначение диаграммы вариантов использования (Use Case Diagram)
- •30. Диаграммы вариантов использования для моделирования предметной области. Назначение, основные элементы (Business Actor, Business Use Case, Association).
- •31. Назначение диаграммы компонентов
- •32. Диаграммы размещения (Deployment Diagram). Назначение, основные элементы (Processor, Device, Connection).
- •33. Последовательность разработки программной системы
- •34. Диаграммы анализа и проектирования
- •35. Основные задачи анализа. Функциональные и нефункциональные требования.
30. Диаграммы вариантов использования для моделирования предметной области. Назначение, основные элементы (Business Actor, Business Use Case, Association).
Диаграмма вариантов использования иллюстрирует функциональные требования к системе, она показывает, что и для кого должна делать система.
Цели при создании диаграмм вариантов использования
• определение общих границ моделируемой предметной области;
• документирование общих требований к функциональному поведению системы;
• определение круга пользователей системы и их связей с системой;
• подготовка исходной документации для взаимодействия разработчиков системы с ее заказчиками.
Отношения на диаграммах вариантов использования
Ассоциация (association relationship) – единственное возможное отношение между актером и прецедентом. Каждая ассоциация подразумевает наличие взаимодействия и соответственно канала связи и интерфейса (граничного объекта, boundary) между актером и программной системой. Ассоциация бывает двунаправленной (сообщение посылается от актера к системе и от системы к актеру), а также однонаправленной (изображается линией со стрелкой). В случае, если стрелка направлена в сторону варианта использования, то это означает, что актер инициирует исполнение данного прецедента. Если стрелка направлена к актеру, то это показывает, что он получает от системы справочную информацию. Ассоциация может иметь некоторые дополнительные обозначения, например, имя и кратность
Включение (include relationship ) -- каждый экземпляр первого варианта использования всегда включает в себя функциональное поведение или выполнение второго варианта использования. В этом смысле поведение второго варианта использования является частью поведения первого варианта использования. Графически данное отношение обозначается пунктирной линией со стрелкой, направленной от базового варианта использования к включаемому варианту использования, которая помечается стереотипом <<include>>. Расширение (extend relationship) -- определяет взаимосвязь базового варианта использования с другим вариантом использования, функциональное поведение которого задействуется базовым не всегда, а только при выполнении дополнительных условий. Графически обозначается в форме пунктирной линии со стрелкой, направленной от расширяющего прецедента к базовому варианту использования и помеченой стереотипом <<extend>>
Отношения на диаграммах вариантов использования (продолжение)
Семантика отношения расширения (extend relationship) определяется следующим образом. Если базовый вариант использования выполняет некоторую последовательность действий, которая определяет его поведение, и при этом имеется точка расширения на экземпляр другого варианта использования, которая является первой из всех точек расширения у базового варианта, то проверяется логическое условие данного отношения. Если это условие выполняется, исходная последовательность действий расширяется посредством включения действий другого варианта использования. Следует заметить, что условие отношения расширения проверяется лишь один раз — при первой ссылке на точку расширения, и если оно выполняется, то все расширяющие варианты использования вставляются в базовый вариант.
Обобщение (generalization relationship) – аналогично наследованию и применяется в том случае, когда необходимо отметить, что дочерние варианты использования кроме присущего им специфического поведения обладают всеми особенностями поведения родительских вариантов использования. Стрелка отношения обобщения указывает на родительский вариант использования.
Стереотипы для моделирования бизнес-актеров и бизнес-функций Моделированием функционеров предметной области (бизнес-актеров), их функциональных обязанностей, а также бизнес-процессов выделяется в отдельный раздел аналитики – бизнес-анализ. В представлении use-case view в соответствии с USDP создается папка business use-case, а для моделирования предметной области используются следующие стереотипы: Бизнес-актер (business actor) – индивидуум (штатная должность), группа, организация или система, которые взаимодействуют с моделируемой бизнес-системой, но не являются ее частью. Примерами бизнес-актеров являются клиенты, покупатели, поставщики, партнеры. Общее свойство бизнес-актеров состоит в том, что они являются инициаторами или клиентами бизнес-процессов моделируемой системы. Сотрудник (business worker) – индивидуум (штатная должность), группа, организация или система, которые действуют внутри моделируемой бизнес-системы, взаимодействуют с другими сотрудниками и являются участниками бизнес-процесса моделируемой системы. Примерами сотрудников являются менеджеры, администраторы, кассиры, инженеры. Общее свойство сотрудников заключается в том то, что они являются субъектами и входят в состав моделируемой системы.
Бизнес-вариант использования (business use case) – определяет последовательность действий моделируемой системы, направленную на выполнение отдельного бизнес-процесса.
