- •Проектирование информационных систем
- •Для студентов пятого курса специальности 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Физическое проектирование
1.4Архитектура системы
1.4.1Общее понятие системной архитектуры
Заказчик обычно воспринимает систему как единую сущность. Поэтому архитектура может быть представлена общей моделью2, которую заказчик в состоянии понять. В процессе проектирования строится множество моделей системы с разных точек зрения. Каждая модель детализирует и специфицирует общую модель. Это необходимо для лучшего понимания проекта. Все модели вместе взятые, описывают системную архитектуру.
Архитектура включает в себя данные:
об организации программной системы, её подсистемах и базы данных;
о структурных элементах, входящих в систему, и их интерфейсах;
о поведении, которое определяется кооперациями, в которых участвуют структурные элементы;
о составе структурных элементов и элементов поведения наиболее крупных подсистем;
о стиле архитектуры.
Хорошо спроектированная архитектура имеет следующие качества:
многоуровневая структура подсистем (модулей);
слабое связывание модулей между собой;
простота понимания организации системы;
надёжность и масштабируемость;
хорошая возможность повторного использования компонентов;
учёт наиболее важных и критичных функций системы;
хорошо продуманный интерфейс с системой и хорошо продуманные интерфейсы с её подсистемами.
Следовательно, для создания качественной архитектуры новой информационной системы необходимо:
представить организационную структуру (автоматизируемого предприятия и приложения);
определить функциональные требования и специфицировать классы, которые реализуют отдельные функции системы;
организовать классы в подсистемы (модули);
сгруппировать модули в архитектурные слои.
Фактически основная цель этапа проектирования состоит в создании надёжной архитектуры в виде исполняемой базовой архитектуры, которая поддаётся модификации.
1.4.2Архитектурные уровни
Наиболее распространённый в настоящее время стиль архитектуры программных систем – это трёхуровневая (или трёхзвенная) архитектура (three–tiered architecture), которая включает следующие уровни:
Уровень представления – User Service.
Уровень логики приложения (бизнес-правила) – Business Service.
Уровень управления данными – Data Service.
С точки зрения информационных систем эти уровни можно интерпретировать следующим образом:
User Service – включает графический интерфейс пользователя (диалоговые окна, отчёты).
Business Service – удовлетворяет требования к системе. Включает программные классы предметной области, а также классы управления и служебные классы. Классы управления и служебные классы не являются классами предметной области. Первые несут ответственность за координацию взаимодействия классов предметной области в соответствии с требованиями, вторые – выполняют вспомогательные функции. Например, управляют передачей сообщений в системе, обеспечивают обмен информацией с базой данных, поддерживают генерацию всевозможных отчётов, обеспечивают безопасность системы, включая защиту информации.
D ata Service – поддерживает хранение и манипулирование данными. Как правило, это реляционная или объектная база данных под управлением соответствующей системы управления базами данных (СУБД).
Системы с трёхуровневой архитектурой могут разворачиваться в различных конфигурациях, в том числе и в следующих (наиболее распространённых):
“Толстый клиент”. Клиент – уровень представления, уровень логики приложения. Сервер – база данных.
“Тонкий клиент”. Клиент – уровень представления. Сервер приложения – уровень логики приложения, база данных.
Для объектно-ориентированных информационных систем, как правило, используется многоуровневая архитектура (multi-tiered architecture). Проводится декомпозиция существующих уровней, которая подразумевает распределение обязанностей, выполняемых классической трёхуровневой архитектурой. Например, сервис генерации отчётов можно разделить на два уровня: высокий и низкий. Первый обеспечивает генерацию шаблона определённого отчёта, второй – генерацию самого отчёта и файловый ввод-вывод. После выполнения декомпозиции трёхуровневая архитектура превращается в многоуровневую без явно выраженных границ.
Использование многоуровневой архитектуры обусловлено следующими причинами:
Повторное использование. Если логика приложения представлена в виде изолированных модулей, то эти модули можно использовать в других системах (приложениях).
Распределённость систем. С развитием языков и средств программирования, которые поддерживают распределённые вычисления, созданные с их помощью приложения становятся всё более распределёнными. Различные уровни приложения можно распределить по разным процессорам и/или нескольким процессам, что повышает производительность системы и улучшает совместное использование информации в системах типа клиент/сервер.
Коллективная разработка приложений. Разработку отдельных уровней системы (пользовательский интерфейс, логика приложения, база данных) можно поручить разным участникам проектной группы, а значит, составить реальный график работы над проектом. Наличие многих уровней даёт возможность поддерживать высокое качество благодаря специализации профессионалов, а также параллельность разработки всех уровней приложения.