- •Проектирование информационных систем
- •Для студентов пятого курса специальности 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.2.1Сигнал
Именованный объект, который асинхронно возбуждается одним объектом и перехватывается другим.
Н аиболее типичный пример внутренних сигналов – это различного рода исключения. Создание и уничтожение объектов – это тоже сигналы. Как и классы, сигналы могут иметь атрибуты и операции.
Сигнал может вызвать переход состояния. Как правило, сигнал обрабатывается на уровне автомата.
Для специфицирования именованных сигналов внутри класса можно использовать стереотип <<сигнал>>, чтобы отличить сигнал среди остальных операций класса.
2.10.2.2С обытие вызова
Объект-отправитель инициирует операцию объекта-получателя (у которого есть автомат).
У правление передаётся от отправителя к получателю. Срабатывает соответствующий переход. Операция завершается. Получатель переходит в новое состояние и возвращает управление отправителю. В отличие от сигнала событие вызова является синхронным. Обрабатывается вызов операцией, которая объявлена в классе объекта-получателя.
2.10.2.3События времени и изменения
Событие времени представляет собой истечение промежутка времени.
М оделируется с помощью ключевого слова AFTER (после), за которым следует выражение, вычисляющее некоторый промежуток времени.
Событие изменения описывает изменение состояния или проверку некоторого условия.
Например, “высота полёта < 1000”. Моделируется с помощью ключевого слова WHEN (когда).
2.10.3Правила построения диаграммы состояний
При создании диаграммы состояния необходимо учитывать следующие обязательные условия:
Отсутствие конфликтующих переходов. Элемент не может одновременно переходить в два и более последующих состояний. Для разрешения конфликта следует пользоваться ограждающими условиями.
Отсутствие изолированных состояний и переходов. Каждый переход должен соединять два состояния (исключением являются начальное и конечное). Разрешаются рефлексивные переходы.
Конечное количество состояний. По определению диаграмма состояний представляет конечный автомат. Каждое состояние на диаграмме должно быть специфицировано явным образом (исключением являются начальное и конечное состояния).
Индивидуальность состояния. В каждом состоянии объект должен вести себя по-разному.
Определённость состояния. В каждый момент времени элемент может находиться только в единственном состоянии. Если это не так, то это или ошибка, или признак наличия параллельности поведения.
Необходимость построения нескольких диаграмм для параллельных процессов поведения. Данное условие следует учитывать особенно при создании диаграмм состояний, которые моделируют поведение системы в целом. Последовательный процесс предполагает, что элемент в течение своего жизненного цикла последовательно проходит через все свои состояния. Для параллельных процессов создаётся множество диаграмм состояния для каждого отдельного процесса поведения.
Кроме перечисленных условий следует помнить о двух аспектах:
Если для системы важно, в каком состоянии находился моделируемый объект в момент выхода из состояния, то следует использовать историю событий. Это существенно при обработке исключительных ситуаций (прерываний без потери данных или выполненной работы). У каждого объекта может быть только одно историческое состояние (последнее).
Если для системы важно, какое время элемент должен или может находиться в данном состоянии, то на диаграмме можно указать это время в явном виде. Каждое состояние должно характеризоваться определённой устойчивостью во времени. Если время ничтожно, то это ошибка выделения состояния.