- •Проектирование информационных систем
- •Для студентов пятого курса специальности 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.12.4.3Распределённые системы
Распределённая система – это система из нескольких взаимосвязанных узлов, способная решать единую прикладную задачу. Узлы, как правило, не бывают статическими.
Распределённые системы бывают разные:
состоять из двух взаимосвязанных процессоров;
быть разветвлёнными и размещаться на многих географически удалённых узлах.
Как отмечалось, узлы в таких системах могут появляться и исчезать в зависимости от сетевого трафика и выхода процессоров из строя. Соединения могут работать параллельно: новые более быстрые каналы и медленные устаревающие. Размещение программных компонентов мигрирует по узлам: репликация (повторение) баз данных между серверами с целью приблизить их к потребителю по мере изменения трафика.
Для распределённых систем диаграммы развёртывания неоценимы для учёта вычислительных ресурсов системы, детализации сетевых устройств.
На диаграмме развёртывания распределённой системы сеть (локальная – Local Area Network, глобальная – Wide Area Network) показывают как отдельный узел. Сеть Internet принято изображать в виде облачка. Для детального описания свойств сети можно воспользоваться атрибутами и операциями узла.
Внимание уделяется:
идентификации узлов, как для системы клиент-сервер;
идентификации (при необходимости) коммуникационных устройств с достаточной степенью детализации;
проектированию диаграммы развёртывания пакетов узлов, чтобы показать логику группирования узлов и размещённых на них компонентов;
созданию диаграмм вариантов использования и взаимодействия для развёртывания, если важна динамика системы.
3Системное проектирование сложных систем
Создание информационной системы (ИС) предполагает создание сложного комплекса программ. Начинается системное проектирование с формулирования первичного замысла на создание новой ИС. Основным содержанием системного проектирования является детальное проектирование программных средств (ПС) и базы данных (БД).
Системное проектирование сложных комплексов программ (т.е. информационных систем) является фундаментом для обеспечения функциональной адекватности и качества всего жизненного цикла программных средств и базы данных.
От полноты и тщательности системного проектирования зависит эффективность реализации функций информационной системы и степень удовлетворения ожиданий и требований заказчика и пользователей. Непредусмотренные при системном проектировании ситуации являются потенциальными источниками отказов и аварий при применении ИС.
3.1Цель и задачи системного проектирования
3.1.1Цель системного проектирования
Основная цель системного проектирования заключается в том, чтобы подготовить и обосновать замыслы и принятые решения о необходимости, направлениях и концепции создания (или модернизации существующих) программных средств и базы данных.
Результатом этих работ являются:
Системный проект.
Техническое задание.
Контракт на продолжение проектирования или решение о нецелесообразности проектирования.
3.1.2Задачи системного проектирования
Системный проект отражает следующие основные результаты выполненных исследований и разработок:
Обследование объекта автоматизации. Системное проектирование начинается с исследования существующей информационной системы, её основных программных компонент и базы данных. Анализируется предметная область, для чего проводится бизнес-анализ (изучение технологических процессов, подлежащих автоматизации). Цель обследования заключается в том, чтобы выявить потребность в создании новой ИС (или модернизации существующей) с определёнными функциями.
Оценка доступных ресурсов для жизненного цикла ПС и БД. Задачи данного вида деятельности состоят в анализе имеющихся и потенциально доступных финансовых, вычислительных средств, специалистов для обеспечения жизненного цикла проекта.
Исходные требования к функциям и характеристикам качества ПС и БД. Основная цель деятельности состоит в подготовке исходных данных и документов, в которых содержатся предварительные требования и пожелания к функциональным характеристикам и показателям качества программного комплекса (функциональная пригодность, надёжность – устойчивость к ошибкам, эффективность – ресурсная и временнАя экономичность, сопровождаемость – удобство анализа и модификации, переносимость – структурированность и замещаемость).
Технико-экономическое обоснование жизненного цикла ПС и БД. Существует два предельных альтернативных варианта технико-экономического обоснования:
разработка полностью нового проекта, для которого отсутствуют подходящие компоненты;
разработка проекта на базе набора готовых программных компонент и информации баз данных, которая не требует создания новых компонент.
На практике для создания сложных ИС почти всегда требуется создавать некоторую часть компонентов заново. Следует помнить, что создание ИС должно быть ориентировано на последующее повторное использование и перенос на другую аппаратную и операционную платформы готовых компонентов.
Анализ инструментальной среды проекта ПС и БД. Данный вид деятельности направлен на анализ имеющейся инструментальной среды и перспектив её развития. Для сложных проектов целесообразно использовать специальный инструментарий и хранилище в процессе создания системы для согласования разработки и управления разработкой.
Создание концепции ПС и БД. Концепция создаётся либо на естественном языке, либо с использованием какого-либо языка моделирования (например, UML). Концепция определяет назначение информационной системы, формализованные функции и задачи. Концепция включает понятия и термины предметной области. На основе описания формируется предварительное техническое задание на систему и её основные модули. Формализация носит итеративный характер. Главная причина – сложность ИС. Начало описания сложных систем – это описание основной части предметной области. При последующих итерациях предметная область постепенно расширяется и детализируется. Важными являются два основных момента:
каждый шаг описания должен документироваться;
заказчики и пользователи ИС должны активно участвовать в процессе анализа и реализации описания.
Моделирование архитектуры ПС и БД. Задача этого вида деятельности – создать предварительный проект архитектуры проекта (возможно на основе моделей и прототипов аналогичных систем). Модели и прототипы различных модулей и функций ИС обеспечивают возможность применить готовые решения, а также исследовать новые методы для реализации их в ПС и БД. Важную роль здесь играет прототипирование. Оно позволяет наглядно продемонстрировать заказчику функции ИС, виды и динамику применения меню, диалоговых экранов, отчётов. Моделирование процессов и обработки данных преследует две основные цели:
моделирование бизнес-процессов для последующего их повторного использования в различных проектах;
моделирование архитектуры объектов, процессов, их взаимодействия, то есть архитектуры всей системы.
Проект архитектуры позволяет наметить план разработки всего жизненного цикла.
Планирование обеспечения жизненного цикла ПС и БД. В процессе системного проектирования последовательно уточняются характеристики объекта автоматизации и среды разработки. В результате появляется возможность спланировать и обосновать весь (последующий) жизненный цикл. На основе такого плана разрабатывается предварительный график работ, и выделяются ресурсы для реализации каждого этапа. Этот график уточняется и корректируется в течение жизненного цикла ИС. Использование CASE-средств в этом виде деятельности состоит в обеспечении удобства работы с такими графиками, их изменения, выявления критических этапов работ и ответственных за их выполнение сотрудников.
Планирование обеспечения качества ПС и БД. Такой план целесообразно создавать для сложных проектов на этапах анализа, разработки требований и проектирования. План устанавливает методы, которые нужно использовать, чтобы достигнуть заданных целей процесса обеспечения качества. В плане должны быть отражены:
показатели качества и условия их применения;
процедуры, которые должны выполняться на различных этапах жизненного цикла для обеспечения качества (методы, отчётность);
организация проектной группы и технология создания ИС (ответственности и полномочия участников, подходы, модели и средства проектирования ИС);
ресурсы, используемые для обеспечения качества;
структура и содержание документов, удостоверяющих определённое качество компонентов.
Планирование обеспечения защиты и безопасности ПС и БД. Планирование заключается в определении взаимосвязанных мер для обеспечения защиты и безопасности информации. Комплекс программ считается защищённым, если все операции выполняются по строго определённым правилам, которые обеспечивают непосредственную защиту объектов, ресурсов и технологических операций. Целесообразно разделять ресурсы, необходимые для непосредственного решения основных функциональных задач ИС, и ресурсы, которые требуются для защиты функционирования ПС и БД. Системное проектирование должно учитывать основные цели обеспечения безопасности, к которым относятся:
сохранение целостности, полноты и достоверности информации баз данных и программ обработки при любых видах угроз;
сохранение конфиденциальности информации в соответствии с действующим законодательством;
предотвращение утраты, хищения, несанкционированного уничтожения, искажения, модификации (подделки), копирования и блокирования информации;
соблюдение авторских прав программной и информационной продукции.
Формирование проектной группы для обеспечения жизненного цикла ПС и БД. Создание ИС во многом зависит от согласованной работы коллектива разработчиков. Возможны две схемы организации проектной группы:
для проекта формируется жёсткая организационная структура с полным составом необходимых специалистов и централизованным руководством;
выделение руководителя проекта и небольшие группы специалистов, которые выполняют определённые работы, причём они могут участвовать сразу в нескольких проектах.
При системном проектировании необходима оценка требований к технологической квалификации возможного коллектива специалистов, его способности создать и реализовать системный проект. Особенно важна не индивидуальная характеристика каждого члена группа, а интегральный показатель коллектива. Тематическая квалификация определяется средней длительностью работы в данной проблемной области основной части коллектива. Технологическая квалификация коллектива характеризируется опытом и длительностью работы с регламентированными технологиями, инструментальными комплексами автоматизации разработки и языками проектирования ПС и БД.
Создание технического задания на весь жизненный цикл ПС и БД.
Предложение контракта на дальнейшее проектирование ПС и БД.
Решение этих задач может осуществляться специалистами:
заказчика,
потенциального разработчика,
специализированной консалтинговой фирмы.