- •С.Л. Моругин Проектирование информационных систем
- •Часть 1
- •Содержание
- •1. Введение. Общая характеристика процесса проектирования ис
- •1.1. Информационные системы
- •1.2. Классификация ис
- •1.3. Проектирование ис
- •1.4. Восходящий и нисходящий подходы к проектированию ис
- •2.1.2. Каскадная (водопадная) модель
- •2.1.3. Инкрементная модель
- •2.1.4. Спиральная модель
- •2.1.5. Макетирование
- •2.1.6. Компонентно-ориентированная модель
- •2.2. Этапы жизненного цикла программного обеспечения
- •2.2.1. Этап установления требований
- •2.2.2. Этап спецификации требований
- •2.2.3. Этап проектирования архитектуры
- •2.2.4. Этап детализированного проектирования
- •2.2.5. Этап реализации
- •2.2.6. Этап интеграции
- •2.2.7. Этап сопровождения
- •2.3. Методологии проектирования ис
- •2.3.1. Общие требования к методологии и технологии проектирования
- •2.3.2. Методология структурного анализа и проектирования
- •2.3.2. Объектно-ориентированный подход
- •2.3.2.1. Объектно-ориентированные методологии
- •2.3.2.1.2. Методология omt и другие методологии
- •2.3.3. Методология rad
- •2.4. Стандарты idef
- •2.5. Инструментальные средства моделирования информационных систем
- •3. Этапы разработки ис. Техническое задание
- •3.1. Этапы разработки информационных систем
- •3.2. Проведение обследования деятельности предприятия и построение моделей
- •3.2.1. Сбор информации для исследования и формализации бизнес-процессов деятельности предприятия или организации
- •3.2.2. Обследование деятельности предприятия и сбор данных
- •3.2.3. Построение и анализ моделей деятельности предприятия
- •3.2.4. Этапы (стадии) создания ис
- •3.3. Разработка системного проекта
- •3.4. Разработка предложений по автоматизации и техническое предложение
- •3.5. Разработка технического задания
- •3.5.1. Назначение технического задания и его структура
- •3.5.2. Рекомендации по заполнению разделов технического задания
- •4. Функциональные структурные модели ис
- •4.1 Структурный подход к проектированию ис
- •4.1.1. Сущность структурного подхода
- •4.1.2 Методология функционального моделирования sadt
- •4.2. Моделирование потоков данных
- •4.2.1. Внешние сущности
- •4.2.2. Системы и подсистемы
- •4.2.3. Процессы
- •4.2.4. Накопители данных
- •4.2.5. Потоки данных
- •4.2.6. Построение иерархии диаграмм потоков данных
- •Обозначения и сокращения
- •Библиографический список
- •Проектирование информационных систем
- •607220, Г. Арзамас, Нижегородская обл., ул. К.Маркса, 36
- •607220, Г. Арзамас, Нижегородская обл., ул. К.Маркса, 36
2.2.5. Этап реализации
Реализация информационной системы включает инсталляцию приобретенного ПО и программирование ПО, разрабатываемого под заказ. Кроме того, реализация подразумевает осуществление некоторых других важных мероприятий, таких как загрузка тестовых и производственных баз данных, тестирование, обучение пользователей, вопросы, связанные с аппаратным обеспечением, и т.д.
Типичная организация бригады по реализации проекта ПО предполагает разделение программистов на две группы:
одну, ответственную за программирование клиентских приложений,
другую, которая должна отвечать за программирование сервера баз данных. Клиентские программы реализуют оконный интерфейс, логику приложений и при необходимости вызывают программы баз данных (хранимые процедуры). Ответственность за непротиворечивость баз данных и корректность транзакций лежит на серверных программах.
2.2.6. Этап интеграции
Наращиваемая разработка предполагает наращиваемую интеграцию программных модулей. Эта задача не так проста, как может показаться на первый взгляд. Для больших систем интеграция отдельных модулей может потребовать больше времени и усилий, чем любой из более ранних этапов ЖЦ, включая реализацию. Еще Аристотель заметил, что целое больше простой суммы частей.
Интеграция модулей должна быть тщательно спланирована в самом начале жизненного цикла ПО. Программные компоненты, подлежащие отдельной реализации, должны быть идентифицированы на ранних стадиях анализа системы. Порядок реализации должен позволять как можно более плавную наращиваемую интеграцию.
Основная трудность, связанная с наращиваемой интеграцией, заключается в существовании взаимных обратных зависимостей между модулями. Хороший проект системы отличается минимальной связностью (coupling) модулей.
Тем не менее, время от времени два модуля оказываются зависимы друг от друга, так что ни один из них не может функционировать изолированно.
Что делать, если необходимо поставить один из модулей еще до того, как другой готов к применению? Ответ состоит в написании специальной программы (макета, заглушки) для временного "заполнения бреши" так, чтобы все модули оказались интегрированными. Программная процедура, предназначенная для имитации работы отсутствующего модуля, называется заглушкой (stubs).
В отличие от традиционных программных систем, основанных на понятии главной программы, в современных объектно-ориентированных системах, управляемых событиями, отсутствует центральная интеллектуальная (главная) программа. Более того, в современных системах отсутствует четко определенная интеграционная структура. Традиционные стратегии интегрирования сверху-вниз или снизу-вверх не применимы к современным системам.
Объектно-ориентированные системы должны быть спроектированы под интеграцию. Каждый модуль должен быть как можно более независимым. Зависимости между модулями необходимо идентифицировать и минимизировать на этапах анализа и проектирования. В идеале, каждый модуль должен образовывать один поток обработки, который запускается в ответ на определенное требование клиента. Использования заглушек как операций замещения следует, по возможности, избегать. Если система спроектирована недостаточно качественно, этап интеграции приведет к хаосу и поставит под угрозу весь проект по разработке системы.