
- •1 Понятия технологии, методологии и методов проектирования ис.
- •Методы проектирования информационных систем
- •2 Классификация методов проектирования систем.
- •3 Средства проектирования, их классификация.
- •4 Понятие жц, модели жц. Каскадная модель.
- •5 Понятие жц, модели жц. Поэтапная модель с промежуточным контролем.
- •6 Понятие жц, модели жц. Спиральная модель.
- •7 Процессы жц ис. Основные, вспомогательные и организационные процессы.
- •8 Современные технологии и методы разработки приложений. Rapid Application Development (rad).
- •9 Современные технологии и методы разработки приложений. Extreme Programming (xp). Extreme Programming – Экстремальное программирование
- •10 Современные технологии и методы разработки приложений. Rational Unified Process (rup).
- •1. Начало (Inception)
- •2. Уточнение (Elaboration)
- •3. Построение (Construction)
- •4. Внедрение (Transition)
- •11 Современные технологии и методы разработки приложений. Microsoft Solution Framework (msf).
- •12 Каноническое проектирование. Стадии и этапы. Каноническое проектирование ис. Стадии и этапы проектирования ис.
- •13 Состав и содержания тз.
- •14 Состав и содержание технического проекта.
- •15 Типовое проектирование. Понятие типового проектного решения. Классификация тпр. Достоинства и недостатки классов тпр.
- •16 Параметрически-ориентированное проектирование. Технологическая сеть.
- •17 Модельно-ориентированное проектирование. Технологическая сеть.
- •18 Системный подход к проектированию ис.
- •19 Структурный анализ. Основные методы.
- •21 Модели сущность-связь. Понятие и виды сущностей. Соглашения об именовании сущностей. Описание сущности.
- •22 Модели сущность-связь. Понятие и виды атрибутов. Именование атрибутов. Описание атрибутов
- •23 Модели сущность-связь. Отношения. Свойства отношений.
- •24 Модели сущность-связь. Графические нотации модели: Чена, Мартина, Баркера, idef1x (Information Engineering)
- •Нотация Чена.
- •Нотация Мартина
- •Нотация idef1x.
- •Нотация Баркера.
- •25 Сущности uml. Виды сущностей.
- •26 Отношения uml. Виды отношений.
- •27 Диаграммы uml. Виды диаграмм.
- •28 Диаграммы классов.
- •29 Диаграммы прецедентов.
- •30 Диаграммы последовательности.
- •31 Диаграммы кооперации
- •32 Диаграммы состояний.
- •33 Диаграммы деятельностей.
- •35 Назначение и архитектура case средств.
32 Диаграммы состояний.
Главное предназначение этой диаграммы - описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий. Системы, которые реагируют на внешние действия от других систем или от пользователей, иногда называют реактивными. Если такие действия инициируются в произвольные случайные моменты времени, то говорят об асинхронном поведении модели.
Хотя диаграммы состояний чаще всего используются для описания поведения отдельных экземпляров классов (объектов), но они также могут быть применены для спецификации функциональности других компонентов моделей, таких как варианты использования, подсистемы, операции и методы
33 Диаграммы деятельностей.
Для моделирования процесса выполнения операций в языке UML используются диаграммы деятельности. Применяемая в них графическая нотация во многом похожа на нотацию диаграммы состояний, поскольку на этих диаграммах также присутствуют обозначения состояний и переходов. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние выполняется только при завершении этой операции.
Таким образом, диаграммы деятельности можно считать частным случаем диаграмм состояний.
В контексте языка UML деятельность (activity) представляет собой совокупность отдельных вычислений, выполняемых автоматом, приводящих к некоторому результату или действию (action). На диаграмме деятельности отображается логика и последовательность переходов от одной деятельности к другой, а внимание аналитика фокусируется на результатах. Результат деятельности может привести к изменению состояния системы или возвращению некоторого значения.
Состояние действия (action state) является специальным случаем состояния с некоторым входным действием и, по крайней мере, одним выходящим из состояния переходом. Этот переход неявно предполагает, что входное действие уже завершилось. Состояние действия не может иметь внутренних переходов, поскольку оно является элементарным. Обычное использование состояния действия заключается в моделировании одного шага выполнения алгоритма (процедуры) или потока управления.
Переход как элемент языка UML был рассмотрен в диаграммах состояний. При построении диаграммы деятельности используются только нетриггерные переходы, то есть такие, которые выполняются сразу после завершения деятельности или выполнения соответствующего действия. Этот переход переводит деятельность в последующее состояние сразу, как только закончится действие в предыдущем состоянии. На диаграмме такой переход изображается сплошной линией со стрелкой.
В общем случае действия на диаграмме деятельности выполняются над теми или иными объектами. Эти объекты либо инициируют выполнение действий, либо определяют некоторый их результат. Действия специфицируют вызовы, которые передаются от одного объекта графа деятельности к другому. Поскольку в таком ракурсе объекты играют определенную роль в понимании процесса деятельности, иногда возникает необходимость явно указать их на диаграмме.