- •Проектирование информационных систем
- •Для студентов пятого курса специальности 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Проектирование информационных систем на основе объектно-ориентированного подхода
Для разработки качественного программного продукта в срок и с установленным бюджетом следует придерживаться унифицированного процесса RUP (Rational Unified Process). Унифицированный процесс является архитектурно-ориентированным, итеративным и инкрементным. Обычно всю работу по созданию системы делят на мини-проекты (небольшие куски). Каждый мини-проект является итерацией, результатом которой будет приращение. Итерации – это шаги, а приращение – выполнение проекта. На ранних фазах проекта приращение не обязательно бывает аддитивным, так как приходится заменять дизайн, но на более поздних – оно аддитивно. Если итерация достигла своей цели, процесс разработки переходит на следующую итерацию. Если итерация не выполнила свои задачи, то проектная группа должна пересмотреть свои решения и попробовать другой подход.
Управляется RUP вариантами использования (функциями системы). Вариант использования (use case) – это часть функциональности системы, необходимая для получения каждым пользователем значимого для него, ощутимого и измеримого результата. Как правило, сначала реализуются наиболее важные варианты использования, которые повышают применимость продукта. Для выбранных вариантов использования проводятся последовательно: анализ, проектирование и реализация с обязательным тестированием каждого этапа.
Варианты использования разрабатываются в паре с архитектурой системы и вместе с ней развиваются по мере хода жизненного цикла. Понятие архитектуры программы включают в себя наиболее важные статические и динамические аспекты системы. Архитектура информационной системы тесно связана с организационной структурой предприятия (или даже целой отрасли народного хозяйства), для которого она создаётся.
RUP использует унифицированный язык моделирования UML (Unified Modeling Language), представляющий собой систему обозначений, которая базируется на диаграммах и предназначается для проектирования систем на основе объектно-ориентированного подхода.
Создание информационной системы при использовании RUP предполагает построение множества моделей, которые тесно связаны друг с другом. Модели создаются архитекторами и проектировщиками. Все эти модели связаны. Вместе они полностью описывают систему.
К аждая модель конкретизирует различные представления о системе: концептуальное (Что?), логическое (Как?), физическое (Где?).
Процесс построения моделей с использованием объектно-ориентированного подхода решает следующие основные вопросы:
Какие классы необходимы. Этот вопрос решается при анализе требований и предметной области, а также при разработке логики программы.
Как распределяются обязанности между классами. Для решения вопроса необходимо определить набор услуг, обеспечиваемых некоторым классом. Обязанность (услуга, операция) может охватывать одну или несколько задач класса.
Как взаимодействуют объекты. Для ответа на этот вопрос следует определить наборы однородных связей между объектами системы.
Какие функции выполняют конкретные классы. Результат решения данного вопроса – определение конкретной реализации выполнения операций с точки зрения архитектуры системы: пользовательский интерфейс, управление, бизнес-логика, посредничество с СУБД, безопасность.
Следует заметить, что распределение обязанностей – самая сложная и важная задача при объектно-ориентированном анализе и проектировании. Для рационального распределения обязанностей важно правильно выбрать уровень абстракции и выделить объекты на выбранном уровне абстракции. Квалифицированное распределение обязанностей между компонентами информационной системы оказывает определяющее влияние на:
работоспособность системы,
масштабируемость (топология: тип, количество, конфигурация серверов),
расширяемость (функциональность, объекты),
возможность повторного использования элементов системы.
П оследовательность рабочих процессов, которые относятся к проектированию, можно показать следующим образом:
Следует заметить, что процесс проектирования системы может осуществляться как снизу вверх: от выбора элементов проектирования до отдельных подсистем (модулей), так и сверху вниз: от определения подсистем до выбора структурных элементов. Последний подход является более предпочтительным.