- •Проектирование информационных систем
- •Для студентов пятого курса специальности 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.7.7.4Альтернативные потоки событий
Отражают отклонения от основного потока событий и потоки ошибок.
Например, возможны альтернативы (А) для потока Покупка товара:
А 1. (Строка 1). Введён неверный идентификатор товара. Выдать сообщение об ошибке.
А 2. (Строка 5.1). Покупатель не может оплатить покупку. Можно отменить покупку или инициировать другой вид платежа.
А 3. (Строка 5.2). От системы авторизации кредитов пришёл отказ. Предложить покупателю другой способ оплаты.
2.7.7.5Постусловия варианта использования
Постусловия – это такие условия, которые должны быть выполнены после завершения варианта использования.
Если, например, после данного варианта использования должен выполняться какой-то другой, то это может быть указано как постусловие.
Постусловия имеются не у каждого варианта использования.
2.8Диаграммы взаимодействия – interaction diagrams
Создание диаграмм взаимодействий является одним из наиболее важных шагов при объектно-ориентированном анализе и проектировании. Для создания диаграмм взаимодействий требуются значительные творческие усилия. Затраченные время и усилия занимают бОльшую часть времени, требующегося для реализации всего проекта.
Значение диаграмм взаимодействия в том, что при построении этих диаграмм происходит распределение обязанностей.
На одной диаграмме взаимодействия отражают один процесс обработки информации из варианта использования.
Если вариант использования имеет альтернативные потоки событий, то для этого варианта использования необходимо создать несколько диаграмм взаимодействия:
на одной диаграмме будет показан основной поток событий, – то, что происходит в системе, когда всё в порядке;
на других будут отображены альтернативные потоки, – то, что произойдёт, если будут отклонения от нормального потока событий.
С уществует два типа диаграмм взаимодействия: последовательности и кооперации. На диаграммах обоих типов представлена одна и та же информация, однако, между ними существуют различия. Последовательности заостряют внимание на управлении, кооперации отображают потоки данных.
2.8.1Идентификация объектов
Главное в диаграммах взаимодействия – объекты, которые должны быть здесь созданы для реализации функциональных возможностей, заложенных в вариантах использования.
Объект описывает реальные, конкретные предметы и заключает в себе некоторые данные и поведение.
Данные объекта называются атрибутами. Их значения время от времени меняются, но сами они неизменны.
Поведение объекта представляется его операциями.
Класс является по существу шаблоном для объектов.
Например, класс – дом, объекты – 25 построенных домов.
На этапе логического проектирования создаются классы спецификации программных сущностей – описание набора объектов со сходными атрибутами и операциями. Класс, реализованный в программном обеспечении, называется классом реализации.
Для выбора кандидатов в объекты можно воспользоваться списком категорий понятий:
Категория понятий |
Пример |
Категория понятий |
Пример |
Физические или материальные объекты |
Самолёт |
Абстрактные понятия |
Боязнь высоты |
Спецификации, элементы дизайна или описания |
Описание полёта |
Организации |
Авиалиния |
Места |
Аэропорт |
События |
Полёт, Крушение |
Транзакции |
Резервирование, Продажа |
Процессы (в основном, не представляются в виде понятий) |
Продажа, Бронирование места |
Элементы транзакций |
Элемент продажи |
Правила и политика |
Политика аннулирования заказа |
Роли людей |
Пилот |
Каталоги |
Каталог частей |
Контейнеры для других объектов |
Самолёт |
Записи финансовой, трудовой, юридической и другой деятельности |
Чек, Трудовой контракт, Журнал обслуживания |
Содержимое контейнеров |
Пассажир |
Финансовые инструменты и службы |
Кредитная линия, Акция |
Другие компьютерные или электро-механические системы, внешние по отношению к данной системе |
Система управления полётами |
Руководства, книги |
Должностные инструкции, Руководства по восстановлению |
Существует очень простой способ идентификации объектов. Он состоит в выделении существительных из текстовых описаний предметной области и выборе их в качестве кандидатов в объекты. Этот способ следует применять осторожно. Недостаток в выразительности естественного языка. Для описания одного и того же понятия могут использоваться различные существительные, и в то же время некоторые существительные могут иметь несколько значений. Типичной ошибкой является отнесение некоторого объекта к атрибутам, в то время как он должен относиться к объектам.
Не все объекты появляются в описании потока событий:
там может не быть экранных форм для заполнения, но их необходимо показывать на диаграммах взаимодействия, чтобы позволить актёру вводить новые данные в систему или просматривать их;
там не будет управляющих объектов, которые координируют последовательность потока событий в варианте использования.