
- •Информационные системы. Классификация. Предметная направленность. Корпоративные информационные системы. Стадия проектирования, разработки, внедрения, поддержки.
- •Типы документов для представления проектных решений.
- •Основные схемы декомпозиции действий и данных функциональной модели.
- •Понятие и иерархия моделей данных. Уровни представления моделей данных.Виды концептуальных моделей данных.
- •Нормализация концептуальной модели данных и целостность данных.
- •Bcnf - нормальная форма Бойса-Кодда вводит дополнительное ограничение в сравнении с 3нф.
- •Анализ информационной связности действий и систем.
- •Анализ функциональной связности данных и систем.
- •Анализ производительности ис
- •Психологические аспекты принятия решений в процессе проектирования.
- •Организационные формы управления проектами
- •Архитектура корпоративных информационных систем (кис)
- •Mrp/erp системы. Современная структура модели mrp/erp
- •Тестирование. Методы тестирования. Категории тестов и оценок системы. Планирование тестирования и оценки системы.
- •Тестирование программного обеспечения
- •Уровни тестирования
- •Верификация и валидация – цели и задачи. V – модель как основа организации процесса верификации.
- •Основные принципы
- •Достоинства
- •Ограничения
- •Аутсорсинг и определение поставщиков.
- •Язык uml (Unificed Moeling Language). Основные модели uml (схема). Виды диаграмм.
- •Диаграмма вариантов использования. Виды отношений между актерами и вариантами использования. Отношения ассоциации, расширения, включения, обобщения
- •Диаграмма классов
- •Диаграмма состояний
- •Диаграмма деятельности. Диаграммы взаимодействия
- •Диаграмма последовательности. Диаграмма кооперации
- •Диаграмма компонентов. Диаграмма развертывания
- •23) Языки и среды моделирования архитектуры предприятия. Языки моделирования предприятий. Idеf, dfd- технология, aris, bpml.
- •24) Структурный (функциональный) и процессный подходы к разработке информационных систем
- •25) Управление требованиями к информационной системе. ГосТы и методология rup.
- •Принципы
- •Жизненный цикл разработки
- •1. Начало (Inception)
- •2. Уточнение (Elaboration)
- •3. Построение (Construction)
- •4. Внедрение (Transition)
- •Автоматизированное создание документов серии гост 34 и 19 с помощью инструментальных средств фирмы ibm Rational
- •26) Моделирование потоков данных. Основные компоненты диаграмм
- •1. Внешние сущности
- •2. Системы и подсистемы
- •3. Процессы
- •4. Накопители данных
- •5. Потоки данных
- •6. Построение иерархии диаграмм потоков данных
- •27) Диаграмма «сущность–связь» (erd). Сущность (Entity). Связь (Relationship). Атрибут. Виды идентификации. Подтипы и супертипы
- •28) Стадии разработки информационных систем. Модели представления для описания проектных решений. Уровни детализации, регламентирующие методики проектирования. Этапы создания информационных систем
- •29) Модели жизненного цикла программного продукта. Виды и особенности. Процессы жизненного цикла систем по iso 15288:2002
- •V модель (разработка через тестирование)
- •Iso / iec 15288 - Инженерные системы стандартных охватывающих процессы и этапы жизненного цикла.
- •30) Понятие требования. Классификация требований. Свойства требований
Диаграмма состояний
Диаграммы состояний – хорошо известное средство описания поведения систем. Они определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых событий. В большинстве объектно-ориентированных методов диаграммы состояний строятся для единственного класса и отражают динамику поведения единственного объекта.
Существует много форм диаграмм состояний, незначительно отличающихся друг от друга семантикой. Наиболее популярная форма, используемая в объектно-ориентированных методах, впервые применялась в методе ОМТ и впоследствии была адаптирована Гради Бучем.
На рисунке показана диаграмма состояний UML, отражающая поведение заказа в системе обработки заказов. На диаграмме изображены различные состояния, в которых может находиться заказ.
Процесс начинается с начальной точки, затем следует самый первый переход в состояние Проверка позиции заказа. Метка этого перехода – «получить первую позицию заказа». Синтаксически метка перехода состоит из трех частей, каждая из которых является необязательной: <Событие> [<Условие>]/<Действие>. В данном случае метка включает только действие «получить первую позицию заказа». После выполнения этого действия мы попадаем в состояние Проверка позиции заказа. С этим состоянием связана деятельность, которая обозначается меткой со следующим синтаксисом: выполнить/деятельность. В данном случае деятельность называется «проверить позицию».
Следует отметить, что термин «действие» (action) используется для перехода, а термин «деятельность» (activity) – для состояния. Хотя и то, и другое – это процессы, реализуемые, как правило, некоторым методом класса Заказ, они трактуются различным образом. Действия связаны с переходами и рассматриваются как мгновенные и непрерываемые процессы. Деятельности связаны с состояниями и могут длиться достаточно долго. Деятельность может быть прервана в результате наступления некоторого события.
Смысл определения «мгновенный» зависит от типа разрабатываемой системы. Для системы реального времени оно может соответствовать нескольким машинным командам, а для обычной информационной системы – нескольким секундам и менее.
Если метка перехода не содержит никакого события, это означает, что переход происходит, как только завершается любая деятельность, связанная с данным состоянием. В данном случае – как только завершится Проверка позиции заказа. Из состояния Проверка позиции заказа возможны три перехода. Метка каждого из них включает только условие. Условие – это логическое условие, которое может принимать два значения: «истина» или «ложь». Условный переход выполняется только в том случае, если условие принимает значение «истина».
Из конкретного состояния в данный момент времени может быть осуществлен только один переход. Таким образом, условия являются взаимно исключающими для любого события. На рисунке показано три условия:
– если проверены не все позиции, входящие в заказ, то получаем следующую позицию и возвращаемся в состояние Проверка позиции заказа;
– если проверены все позиции и все они имеются на складе, то переходим в состояние Выдача заказа на поставку;
если проверены все позиции, но не все из них имеются на складе, то переходим в состояние Ожидание.
Рассмотрим сначала состояние Ожидание. Для этого состояния не существует деятельностей, поэтому данный заказ находится в состоянии ожидания, пока не наступит некоторое событие. Оба перехода из состояния ожидания помечены событием Позиция Получена. Это означает, что заказ ожидает до тех пор, пока он не обнаружит наступление данного события. При этом оцениваются условия переходов и выполняется тот переход, для которого условие «истинно» (либо в состояние Выдача заказа на поставку, либо обратно в состояние Ожидание).
В состоянии Выдача заказа на поставку имеется деятельность, которая инициирует поставку. Из этого состояния имеется единственный безусловный переход, управляемый событием Поставлен. Это означает, что данный переход обязательно произойдет, если произойдет данное событие. При этом переход никак не связан с завершением деятельности; наоборот, когда деятельность «инициировать поставку» завершится, то данный заказ останется в состоянии Выдача заказа на поставку, пока не наступит событие Поставлен.