
- •Модели жизненного цикла программных систем.
- •4.Фазы, рабочие процессы, модели уп.
- •Модель развертывания (DeploymentModel)
- •5.Концептуальная модель uml. Сущности языка. (Новикова)
- •1. Структурные:
- •15. Диаграмма коммуникации (кооперации) (когда разрабатывается, преимущества, недостатки, система обозначений).
- •16. Классификация шаблонов (patterns).
- •17. Обязанности объектов. Шаблон Information Expert.
- •18. Шаблон Creator.
- •19. Шаблон Low Coupling.
- •20. Шаблон High Cohesion.
- •21. Шаблон Controller.
- •22. Шаблон Polymorphism.
- •23. Диаграмма классов (что отображает, когда разрабатывается, процесс создания).
- •24. Дополнительные обозначения диаграммы классов (обобщение, агрегация, квалификатор ассоциации, класс ассоциации).
- •25. Использование пакетов для организации элементов модели.
- •26. Архитектура программной системы (логическая архитектура).
- •27. Подход все (Boundary – Control – Entity).
- •28. Диаграмма состояний (что отображает, для каких элементов модели создается, описание состояний, описание переходов).
- •29. Диаграмма видов деятельности (для каких элементов модели разрабатывается, что отображает, основные элементы нотации).
27. Подход все (Boundary – Control – Entity).
Подход BCE (Boundary-Control-Entity – граница-управление-сущность) представляет собой подход к объектному моделированию, основанный на трехфакторном представлении классов.
В правильно спроектированной иерархии пакетов актер может взаимодействовать только с пограничными объектами из пакета BoundaryPackage, объекты-сущности из пакета EntityPackage могут взаимодействовать только с управляющими объектами из ControlPackage и управляющие объекты из ControlPackage могут взаимодействовать с объектами любого типа.
Основным преимуществом подхода BCE является группирование классов в виде иерархических уровней. Это способствует лучшему пониманию модели и уменьшает ее сложность.
В языке UML для классов определены 3 основных стереотипа:
-
Boundary. Пограничные классы, классы, которые представляют интерфейс между субъектом и системой.
-
Control - управляющие классы, описывают объект, который перехватывает входные события инициированные пользователем и контролирует выполнение бизнес-процессов.
-
Entity - сущности, которые описывают семантику сущностей. Для каждого класса-сущности создают таблицу в БД, каждый атрибут становится полем БД.
28. Диаграмма состояний (что отображает, для каких элементов модели создается, описание состояний, описание переходов).
На диаграмме состояний отображается ЖЦ 1-го объекта, начиная с момента его создания и до его разрушения. На диаграмме состояний показаны состояния объекта, переходы из 1-ого состояния в другое, события, инициирующие переход и виды действий. Может описывать как прецедент, экземпляр класса, так и систему в общем.
Состояние - абстракция значений связей объекта. Состояние определяется следующими элементами:
-
Имя
-
Действие при вх/вых.(При моделировании часто встречаются ситуации, когда необходимо выполнить некоторые действия, независимо от того, по какому переходу было выполнен вход в состояние, либо выполнено одно и тоже действие при выходе из состояния.
-
Деятельность. Поведение внутри состояния реализации в виде операции.
Переход - мгновенная смена одного состояния другим.
Элементы, которые определяют переход:
1) Событие – кратковременное явление, воздействующее на объект. Могут быть сигнала, изменения и события времени.
2) Guard Condition – определяет, когда переход может быть выполнен.
3) Действие.
29. Диаграмма видов деятельности (для каких элементов модели разрабатывается, что отображает, основные элементы нотации).
Диаграмма видов деятельности показывает шаги выполнения, каждый шаг, показывает состояние, а также что выполняется, поэтому шаги выполнения называются состоянием видов деятельности.
Деятельность - продолжающийся во времени не атомарный шаг вычисления. Деятельность приводит к выполнению некоторого действия, составленного из атомарных вычислений, каждый из которых либо изменяет состояние системы, либо возвращает некоторое значение.
Диаграммы деятельности (Activity diagram), называемые также диаграммами активности или диаграммами видов деятельности, были введены в язык UML сравнительно недавно. Диаграмма деятельности - это, по существу, блок-схема, которая показывает, как поток управления переходит от одной деятельности к другой, при этом внимание фиксируется на результате деятельности. Результат может привести к изменению состояния системы или возвращению некоторого значения. Диаграмма деятельности отличается от традиционной блок-схемы
· более высоким уровнем абстракции,
· возможностью представления с помощью диаграмм деятельности управления параллельными потоками наряду с последовательным управлением.
Одно из основных направлений использования диаграмм деятельности - отображение внутрисистемной точки зрения на прецедент. Диаграммы деятельности применяют для описания шагов, которые должна предпринять система после того, как инициирован прецедент.
При моделировании программных систем бывает необходимость промоделировать рабочий процесс или функционирование системы. Диаграмму поведения системы можно промоделировать с помощью диаграммы видов деятельности, в которой внимание сосредоточено на содержание деятельности, в которых принимают участия объекты.