- •Проектирование информационных систем
- •Для студентов пятого курса специальности 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.11.5Правила построения диаграммы компонентов
Создание диаграммы компонентов возможно только после разработки логического представления системы и до создания диаграммы размещения.
До начала разработки диаграммы компонентов необходимо принять решение о выборе:
операционных систем, на которых предполагается реализовывать систему;
конкретных баз данных;
языков программирования.
Решить, из каких частей (файлов) будет состоять физическая реализация системы. При выборе необходимо учитывать два основных фактора:
повторное использование;
управление конфигурацией.
Выделить исполняемые программы и библиотеки как компоненты. В исполняемых библиотеках должны размещаться самые необходимые для инициализации программы части исходного кода. Как правило, в библиотеки помещают бОльшую часть описаний классов, их операций и методов.
Дополнить модель интерфейсами. Если в системе существуют пары компонентов, в которых один компонент – реализует услугу, а другой – использует эту услугу, а для системы важно управление стыковочными узлами системы, то моделирование интерфейсов между компонентами обязательно.
Добавить в диаграмму зависимости между отдельными компонентами системы.
Включить в модель схему базы данных. Этот шаг предполагает спецификацию отдельных таблиц и установление информационных связей между таблицами.
Добавить детализирующие диаграммы для отдельных компонентов, чтобы отобразить особенности компиляции исходных текстов программ и исполнения.
По возможности пользоваться стандартными стереотипами компонентов UML.
Создание диаграммы компонентов тесно связано с ещё одной диаграммой реализации – диаграммой размещения (или развёртывания), о которой в следующей главе.
2.12Диаграмма развёртывания – deployment diagram
Любая информационная система включает программное и аппаратное обеспечение. Компоненты, которые разрабатываются для информационной системы (или повторно используются в ней), должны быть размещены на какой-либо аппаратуре. При проектировании архитектуры системы она рассматривается как с логической, так и физической точки зрения.
К логическим элементам относятся:
классы;
интерфейсы;
взаимодействия;
кооперации;
конечные автоматы.
К физическим элементам относятся:
компоненты, которые представляют физическую реализацию логических сущностей;
узлы, представляющие аппаратуру, на которой размещаются и исполняются компоненты.
Далее рассматриваются отдельные элементы, из которых состоит диаграмма развёртывания.
2.12.1Узлы - Nodes
Узел3 – физически существующий элемент системы, который представляет собой процессор или устройство.
В настоящее время понятие узла включает в себя не только вычислительный ресурс (процессор, некоторый объём памяти), но и другие механические или электронные устройства:
датчики;
принтеры;
модемы;
цифровые камеры;
сканеры;
манипуляторы.
Узлы, как и компоненты, представляют физический аспект системы. Между ними существует соответствие:
Узлы исполняют компоненты. Компоненты исполняются на узлах.
Узлы – это средства физического развёртывания компонентов. Компоненты включают в спецификацию узла как процесс. Один компонент может быть развёрнут на одном или нескольких узлах системы.
Множество компонентов, приписанных на узел как группа, называется элементом распределения – Distribution Unit.
Узлы можно группировать в пакеты точно так же, как классы или компоненты.
Каждый узел должен иметь уникальное имя, которое может быть произвольной последовательностью символов (за исключением двоеточия, оно отделяет имя узла от имени объемлющего пакета). Например, Сервер, Продажи, :Принтер HP DeskJet 400.
Дополнительно к имени узла можно использовать различные стереотипы. В UML не существует стандартных стереотипов, разработчики при необходимости могут создать их самостоятельно. Несмотря на то, что стандартных стереотипов не существует, они приписываются узлам. В практике встречаются следующие стереотипы для узлов:
|
|
|
|
|
|
|
|
Чаще всего используются стереотипы: процессор и устройство.
Процессор (Processor) – узел, способный обрабатывать данные, то есть исполнять компонент.
Устройство (Device) – узел, не способный обрабатывать данные. В общем случае такой узел используется для представления чего-либо, что связано с реальным миром.
Моделирование процессоров и устройств осуществляется следующим образом:
Определить все аппаратные, механические и другие типы устройств, которые необходимы для выполнения системой своих функций (с точки зрения их размещения) и выделить каждый из них как узел.
Если элементы являются процессорами и устройствами общего вида, то приписать им стереотипы <<процессор>> и <<устройство>>, иначе – либо задать подходящий стереотип, либо соответствующую пиктограмму.
Указать характеристики узла. Это аналогично атрибутам класса.
Указать процессы, применимые к узлу. Это аналогично операциям класса, с одной стороны. С другой стороны – это не что иное, как исполняемые на узле компоненты. При развёртывании компонент следует помнить, что на одном узле может размещаться несколько разных компонентов, а одна и та же компонента может быть развёрнута на нескольких узлах.
Если окажется, что отдельные компоненты не развёрнуты ни на одном узле, то добавить дополнительные узлы, содержащие процессор.
Г рафически узел изображается в виде куба, но можно создавать свои собственные пиктограммы для обозначения различных узлов (например, персонального компьютера, принтера, человека).
Узлы используются для определения топологии создаваемой системы с точки зрения состава и свойств конкретных физических компонентов системы, которые должны быть выполнены для успешной работы системы.
Узлы системы могут определяться и в самом начале проектирования, после исследования требований к аппаратной платформе. Тогда дальнейшее проектирование системы может быть обусловлено выбранными аппаратными средствами. Однако при проектировании информационных систем следует стремиться к максимальной независимости функционирования системы от аппаратуры.