- •Проектирование информационных систем
- •Для студентов пятого курса специальности 071900 – Информационные системы в технике и технологиях
- •1Введение
- •1.1Классификация методов проектирования
- •1.2Виды информационных систем
- •1.2.1Системы обработки данных
- •1.2.2Системы управления
- •1.2.3Офисные системы
- •1.2.4Системы поддержки принятия решений
- •1.2.5Экспертные системы
- •1.3Структура информационной системы
- •1.4Архитектура системы
- •1.4.1Общее понятие системной архитектуры
- •1.4.2Архитектурные уровни
- •2Проектирование информационных систем на основе объектно-ориентированного подхода
- •2.1Представления системы
- •2.2Uml-модель информационной системы
- •2.3Представления системы в rational rose
- •2.4Проектирование в rational rose
- •2.5Моделирование предметной области
- •2.5.1Моделирование организационной структуры
- •2.5.2Моделирование бизнес-процессов
- •2.5.3Моделирование бизнес-функций
- •2.5.4Моделирование документов и бизнес-сущностей
- •2.6Использование бизнес-модели на этапах разработки
- •2.7Диаграмма вариантов использования – use case diagram
- •2.7.1Обозначения в диаграмме вариантов использования
- •2.7.2Идентификация актёров и вариантов использования
- •2.7.3Категории вариантов использования
- •2.7.4Абстрактные варианты использования
- •2.7.5Конкретные варианты использования
- •2.7.6Запись актёров и вариантов использования
- •2.7.7.4Альтернативные потоки событий
- •2.7.7.5Постусловия варианта использования
- •2.8Диаграммы взаимодействия – interaction diagrams
- •2.8.1Идентификация объектов
- •2.8.2Использование диаграмм взаимодействия
- •2.8.3Диаграмма последовательности – Sequence diagram
- •2.8.4Подход к разработке диаграммы последовательности
- •2.8.5Диаграмма кооперации – Collaboration Diagram
- •2.9Диаграммы классов – class diagrams
- •2.9.1Классы
- •2.9.1.1Параметризованный класс – parameterized class
- •2.9.1.2Класс-наполнитель – instantiated class
- •2.9.1.3Утилита - utility
- •2.9.1.4Метакласс – metaclass
- •2.9.1.5Абстрактный класс – abstract class
- •2.9.2Стереотип класса
- •2.9.2.1Пограничные классы – boundary classes
- •2.9.2.2Управляющие классы – control classes
- •2.9.2.3Классы-сущности – entity classes
- •2.9.3Видимость класса – Visibility
- •2.9.4Пакеты – packages
- •2.9.5Диаграммы классов
- •2.9.6Создание диаграммы классов
- •2.9.6.1Идентификация программных классов
- •2.9.6.2Идентификация атрибутов
- •2.9.6.3Идентификация операций
- •2.9.6.4Идентификация ассоциаций
- •2.10Диаграммы состояний – statechart diagrams
- •2.10.1Основные сведения о диаграмме состояний
- •2.10.2События
- •2.10.2.1Сигнал
- •2.10.2.2С обытие вызова
- •2.10.2.3События времени и изменения
- •2.10.3Правила построения диаграммы состояний
- •2.10.4Диаграммы состояний для вариантов использования
- •2.10.5Классы и типы для диаграммы состояний
- •2.11Диаграммы компонентов – component diagrams
- •2.11.1Компоненты
- •2.11.2Основные виды компонентов
- •2.11.3Основные стереотипы компонентов
- •2.11.4Диаграмма компонентов
- •2.11.5Правила построения диаграммы компонентов
- •2.12Диаграмма развёртывания – deployment diagram
- •2.12.1Узлы - Nodes
- •2.12.2Соединения
- •2.12.3Диаграмма развёртывания
- •2.12.4Использование диаграмм развёртывания
- •2.12.4.1Встроенные системы
- •2.12.4.2Клиент-серверные системы
- •2.12.4.3Распределённые системы
- •3Системное проектирование сложных систем
- •3.1Цель и задачи системного проектирования
- •3.1.1Цель системного проектирования
- •3.1.2Задачи системного проектирования
- •3.2Структура и содержание документов системного проекта
- •3.2.1Техническое задание
- •3.2.2Описание архитектуры программного и информационного обеспечения системы
- •3.2.3Описание жизненного цикла, технологии и инструментария проектирования программного средства и базы данных
- •3.2.4Планы управления рабочими проектами
- •3.2.5Техническое задание на рабочее проектирование
- •3.2.6Системный проект
- •3.2.7Акт завершения работ и утверждения системного проекта
- •3.2.8Основные компоненты договора на детальное проектирование
- •3.3Работы и нормативные документы по системному проектированию информационной системы
- •3.4Стандарты в жизенном цикле информационных систем
- •3.4.1Нормативно-методическое обеспечение
- •3.4.2Рекомендуемые стандарты
- •4Проектирование систем как часть жизненного цикла
- •4.1Стадии и этапы жизненного цикла
- •4.1.1Исследование
- •4.1.2Проработка
- •4.1.3Создание
- •4.1.4Переходный период
- •4.2Процесс проектирования
- •4.2.1Концептуальное проектирование
- •4.2.2Логическое проектирование
- •4.2.3Физическое проектирование
2.10.1Основные сведения о диаграмме состояний
В общем случае при моделировании поведения с использованием диаграммы состояний показывают следующие элементы:
Состояние – State.
Событие, которое изменяет текущее состояние – Event.
Переход из одного состояния в другое (в результате события) – Transition.
Действие, которое происходит внутри состояния или при переходе – Actions. Существует четыре возможных действия в пределах состояния:
на входе – On Entry;
на выходе – On Exit;
внутри – Do;
на переходе – On Event.
Д иаграмма состояний определяет все возможные состояния, в которых может находиться конкретный элемент, а также процесс смены состояний этого элемента в результате влияния некоторых событий.
С остояния могут быть вложенными, то есть одно состояние (суперсостояние) может включать множество других состояний. Вместо того чтобы поддерживать одинаковые переходы (по одному на каждое состояние), их можно объединить, перенося в одно суперсостояние.
Вложенные состояния используются в случае, когда у нескольких состояний имеются идентичные переходы.
Бывают ситуации, когда необходимо помнить, в каком состоянии находился объект в прошлом. Например, при выходе из суперсостояния по нескольким переходам следует запомнить, из какой точки суперсостояния произошёл выход. Существует два способа решения этой проблемы:
Включение начального состояния в суперсостояние. Именно в данной точке будет находиться объект при входе в суперсостояние.
Использование истории состояний (State history). В этом случае объект может выйти из суперсостояния, а затем вернуться точно в то место, откуда вышел.
П ример диаграммы состояний объекта класса Курсы:
Т а же самая диаграмма с использованием суперсостояния и хронологии:
Совокупность переходов диаграммы показывает, как объект Курс может переходить из одного состояния в другое. Стрелка перехода направлена от первоначального состояния к последующему.
Переходы могут быть рефлексивными: объект переходит в то же состояние, в котором он в настоящий момент находится.
Переходы могут иметь ограждающие условия (Guard condition), которые определяют, когда переход может быть выполнен. Ограждающие условия задаются в случае, когда существует несколько переходов из одного состояния (условия обязательно должны быть взаимоисключающими).
Как состояния, так и диаграммы состояний могут быть вложены друг в друга для более детального представления отдельных элементов модели.
2.10.2События
В каждый момент времени в реальном мире происходят различные явления. Заслуживающие всеобщего внимания или значимые явления называют событиями. В терминах проектирования информационных систем говорят, что
Событие – это описание существенного факта, локализованного во времени и в пространстве. Событие трактуется как стимул, который вызывает переход моделируемого элемента из одного состояния в другое.
Все реальные системы в той или иной мере динамичны. Их динамичность обусловлена событиями, происходящими вне или внутри системы. Диаграмма состояний используется для описания реакции моделируемого элемента на подобные события.
Различают два вида событий:
Внешние (системные) события. Вызываются некоторыми внешними по отношению к системе условиями (например, пользователем или датчиком). Внешние события передаются между системой и её актёрами. Сначала их следует искать в описании потоков событий, затем в диаграммах последовательности. Для особо важных внешних событий приводятся инициируемые ими системные операции. Например, прерывание от датчика.
Внутренние события. Вызываются некоторыми внутрисистемными условиями и передаются между объектами внутри самой системы. Внутренние события возникают при выполнении операции после приёма сообщения от другого системного объекта. Например, исключение при переполнении. Внутренние события в виде сообщений отображаются на диаграммах взаимодействия. Их также можно идентифицировать, исследуя диаграммы классов:
Экземпляр класса (объект) может вести себя по-разному в зависимости от значений атрибутов. Особенно следует обращать внимание на классы, атрибутом которых является такой атрибут, как Статус. Необходимо проанализировать поведение объекта при различных значениях этого атрибута.
Поведение объекта может зависеть от его связей с другими объектами. Необходимо обратить внимание на отношения в диаграмме классов, мощность которых может принимать нулевое значение. Нули указывают на то, что данная ассоциация не является обязательной. Следует понять, ведёт ли себя объект по-разному при наличии и отсутствии связи. Если да, то он имеет несколько состояний. Например, связь между классами Сотрудники и Организации. Если между ними установлена связь (Синичкин – “Автосервис”), то это означает, что сотрудник нанят. Если нет, то он уволен или на пенсии.
Диаграммы состояний для иллюстрации внутренних событий используются для моделирования объектов со сложным поведением. В информационных системах обработки данных такие объекты встречаются крайне редко, а информационные системы управления содержат множество зависимых от состояния объектов.
Объект любого класса может послать объекту-получателю сигнал или послать событие (инициировать в нём операцию). После отправления сигнала получателю он продолжает свой поток управления, не дожидаясь ответа. После инициации операции, отправитель передаёт ему поток управления и должен дождаться ответа от получателя.
Объект любого класса может получать от объекта-отправителя сигналы или события. В случае события поток управления отправителя блокируется потоком управления получателя до тех пор, пока операция не завершится. Если не указано, что нужен ответ, событие может быть потеряно.
При помощи UML моделируют четыре типа событий: сигналы, вызовы, истечение промежутка времени, изменение состояния.