- •Проектирование информационных систем
- •Для студентов пятого курса специальности 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.5.1Моделирование организационной структуры
Данный тип моделирования основан на структурной методологии. Сущность структурного подхода к описанию предметной области заключается в декомпозиции автоматизируемой организации на подразделения, в которых определяются участники производственного процесса (действующие лица) и документы, с которыми они работают.
Rose с самого начала проектирования поддерживает архитектуру системы на высоком уровне абстракции, благодаря наличию пакета (Package).
Модель организационной структуры определяется как иерархия Use case-диаграмм.
Первый уровень иерархии должен включать одну или несколько организационных единиц (organization unit). Например, подлежащее автоматизации предприятие.
Последующие уровни иерархии могут включать так же одну или несколько организационных единиц (organization unit). Например, это могут быть подразделения автоматизируемого предприятия.
Нижний уровень иерархии включает действующих лиц производственного процесса: субъектов (business worker) и объектов (business actor). Субъект (business worker) представляет собой человека, который действует в рамках системы. Объект (business actor) воплощает автоматизируемую деятельность субъектов и по сути является абстрактным описанием субъекта.
М одели документов (бизнес-сущностей) строятся с использованием классов (business entity) на Use case-диаграммах.
2.5.2Моделирование бизнес-процессов
Моделирование бизнес-процессов (или по-другому производственных процессов) для описания автоматизируемой предметной области производится с использованием диаграмм деятельности (Activity diagram).
Диаграммы деятельности представляют собой схемы потоков управления в системе от действия к действию, а также параллельные действия и альтернативные потоки.
Диаграммы деятельности применяются для моделирования поведения системы. Они очень удобны для выделения бизнес-функций системы. Внимание фокусируется на деятельности с точки зрения участников автоматизируемого производственного процесса, которые будут сотрудничать с системой.
К основным элементам данной диаграммы относятся следующие:
начальное состояние (start state);
конечное состояние (end state);
деятельность (activity);
состояние (state);
переход (state transition);
решение (decision);
горизонтальные синхронизаторы (horizontal synchronization);
разделительные линии (swimlane).
Д иаграмма деятельности может иметь только одно начальное состояние, а конечных состояний – множество. Новые начальные состояния могут быть только на диаграммах, декомпозирующих отдельные виды деятельности.
Э лемент activity (деятельность) используется для описания определённой деятельности субъекта. Этот элемент должен иметь наименование, которое отражает цель деятельности. Деятельность именуется глаголом в настоящем времени. С элементом деятельности могут быть связаны конкретные действия (Action), которые происходят на входе элемента, на выходе, внутри него или при наступлении определённого события. Действие описывается в спецификации в форме свободного текста.
Э лемент state (состояние) используется для описания определённых состояний какого-либо субъекта или объекта. С этим элементом должно быть связано имя. Именуется состояние так же, как и деятельность, глаголом в настоящем времени.
П ереход используется для описания связи между элементами диаграммы activity (деятельность) и state (состояние). Переход обозначается сплошной линией со стрелкой, указывающей на следующее действие или состояние.
Переход может происходить по условию. Для этого используется элемент decision (решение). При использовании этого элемента рекомендуется указывать для перехода ограждающие условия.
П ри моделировании бизнес-процессов часто встречаются параллельные потоки. Для отражения выполнения параллельной деятельности используется элемент horizontal synchronization (синхронизатор).
Э лемент swimlane (разделительная линия, дорожка, секция) используется для разделения диаграммы на участки. Это нужно для того, чтобы показать, кто из участников отвечает за выполнение действий на каждом участке. Название разделительной линии, как правило, соответствует имени субъекта (business worker) или объекта (business actor).
Рекомендации по моделированию с использованием диаграммы деятельности
Для того, чтобы построить модель процесса необходимо следующее:
Выделить какой-либо участок производственного процесса.
Создать для каждого действующего лица этого участка отдельную дорожку.
Определить предусловия для начального состояния рабочего процесса и постусловия. Это необходимо для того, чтобы чётко определить границы производственного процесса.
Отразить на диаграмме (во времени) деятельности и действия, а также контролируемые состояния для участников, начиная с исходного состояния.
Множество деятельностей, которые тесно связаны друг с другом и не могут быть прерваны, поместить в одну декомпозируемую деятельность и представить виде отдельной суб-диаграммы.
Соединить состояния и деятельности сначала для последовательных потоков, затем перейти к ветвлениям и только после этого рассмотреть разделения и слияния.
Если необходимо, то поместить на диаграмму важные объекты, которые участвуют в производственном процессе.