- •1. Основные концепции системного анализа и проектирования в ssadm
- •1.1. Цели и концепции
- •1.1.1. Пользователи.
- •1.1.2. Менеджеры.
- •1.2.4. Обозначения структурной модели
- •1.1.3. Разработчики.
- •1.2 Структурная модель ssadm, ее назначение, роль и состав.
- •1.2.1 Модули.
- •1.2.2. Входы модулей.
- •1.2.3 Выходы модулей.
- •Информационная шина.
- •Организационные действия.
- •Соглашения, принятые для облегчения понимания схем.
- •1.2.5 Описания действий.
- •1.3. Жизненный цикл разработки систем
- •1.3.1. Модуль fs - описание действия "анализ реализуемости".
- •Краткое изложение.
- •Участники.
- •Предусловия.
- •1.3.2. Модуль rа - описание действия "анализ требований".
- •Краткое изложение.
- •Участники.
- •Предусловия.
- •1.3.3. Модуль rs - описание действия "спецификация требований".
- •Участники.
- •Предусловия.
- •1.3.4 Модуль ls-определение действия "спецификация логической системы".
- •Краткое изложение.
- •Участники.
- •Предусловия.
- •Участники.
- •Предусловия.
- •1.4. Ключевые понятия и философия
- •1.4.1. Три вида модели.
- •1.4.2. Ориентация на требования.
- •1.4.3. Пользователь, функция и моделирование данных.
- •1.4.4. Варианты организационного управления.
- •1.5. Сценарий применения методов
- •1.5.1. Применение методов в жизненном цикле.
- •1.5.2. Взаимозависимости между методами.
- •1.5.2.1. Взаимодействие методов в модуле fs (Анализ реализуемости).
- •1.5.2.2. Взаимодействие методов в модуле ка (Анализ требований).
- •"Определение требований".
- •"Моделирование потоков данных".
- •1.5.2.3. Взаимодействие методов в модуле rs (Спецификация требований).
- •"Моделирование потоков данных".
- •"Логическое моделирование данных".
- •"Определение функций".
- •"Реляционный анализ данных".
- •"Объектно-событийное моделирование".
- •"Спецификация прототипирования".
- •"Проектирование диалога".
- •Организационное управление.
- •Проектирование базы данных.
- •Проектирование физических процессов.
- •Интерфейс процесс - данные.
- •1.6 Достоинства инвариантности к реализации проектов
- •1.7. Информационно-технологическая поддержка
- •2 Моделирование потоков данных
- •2.1. Назначение метода
- •2.2 Обзор
- •2.3. Место метода моделирования потоков данных в процессе проектирования
- •2.3.1 Этапы
- •2.3.2.Взаимосвязь с другими методами.
- •2.4. Входы мпд
- •2.5 Выходы мпд
- •2.6. Основные понятия и обозначения метода моделирования потоков данных.
- •2.6.1. Обозначения, применяемые при построении схем потоков данных.
- •2.6.1.1. Внешний объект
- •2.6.1.2. Процесс
- •2.6.1.3. Хранилища данных.
- •2.6.1.4. Поток данных
- •2.6.1.5. Двунаправленный поток
- •2.6.1.6. Поток данных между внешними объектами
- •2.6.1.7. Поток ресурса
- •2.6.1.8. Разрешенные спд - соединения
- •2.6.2. Спд - иерархия
- •2.6.3. Правила декомпозиции процесса.
- •2.6.5.Декомпозиция других элементов спд
- •2.7 Техника моделирования потоков данных
- •2.7.1. Модель потоков данных существующей системы (мпд сс)
- •2.7.1.1. Начало моделирования
- •2.7.1.2. Спд нижних уровней
- •2.7.1.3. Контекстные схемы, схемы документопотоков и схемы ресурсопотоков
- •2.7.1.4. Построение и использование контекстной схемы
- •2.7.1.5. Построение и использование схем документопотоков
- •2.7.1.6. Разработка схем документопотоков
- •2.7.1.7. Составление схемы ресурсопотоков
- •2.7.2. Логическая модель потоков данных (лмпд)
- •2.7.2.1. Процедуры приведения мпд сс к логической мпд
- •2.7.2.2. Рационализация хранилищ данных
- •2.7.2.3. Рационализация процессов нижнего уровня
- •2.7.2.4. Реконструирование иерархии
- •2.7.2.5. Общие функциональные признаки
- •2.7.2.6. Проверки полноты и согласованности
- •2.7.2.7. Идентификаторы процесса.
- •2.7.2.8. Избегайте интуитивного синтеза лмпд
- •2.7.4. Мпд тс
- •2.7.4.1. Мпд тс и определение функций
- •1.9. Реальные ограничения
- •2.7.2.9. Спд и варианты бизнес-системы.
- •2.7.4.2. Связь между потоками данных и событиями
- •2.7.4.3. Проверка правильности по другим продуктам технологии
- •2.8. Заключение
- •3. Логическое моделирование данных
- •3.1. Назначение
- •3.2. Обзор
- •3.3. Использование лмд в ssadm – технологии
- •3.3.1. Этапы.
- •3.3.2. Связь с другими методами.
- •3.4. Входы логического моделирования данных
- •3.5 Выходы логического моделирования данных
- •3.6. Основные понятия и обозначения метода логического моделирования данных
- •3.6.1. Объекты.
- •3.6.2. Связи
- •3.6.3. Степень связи.
- •3.6.4. Жесткость.
- •3.6.5. Идентификаторы связи.
- •3.6.6. Фраза-описатель связи.
- •3.6.7. Группы исключающих связей.
- •3.6.8. Рекурсивные связи.
- •3.6.9. Разбиения.
- •3.7. Понятия логического моделирования данных, не изображаемые на лсд
- •3.7.1 Мобильные и немобильные объекты.
- •3.7.3. Обязательные и необязательные атрибуты.
- •3.7.4. Сгруппированные домены.
- •3.7.5. Уникальные идентификаторы.
- •3.8. Вспомогательные понятия
- •3.8.1. Главные и вспомогательные объекты.
- •3.8.2. Ключи.
- •3.8.3. Ссылочные объекты.
- •3.8.4. Простые иерархические ключи.
- •3.8.5 Составные ключи.
- •3.8.6. Более сложные ключи.
- •3.9. Использование метода в процессе проектирования
- •3.9.3. Идентификация связей.
- •3.9.4. Формирование лсд.
- •3.9.5. Присвоение имен связям.
- •3.9.6. Нормализация лмд.
- •3.9.7. Проверка правильности лмд.
- •3.9.8. Удаление лишних связей из лсд.
- •3.9.9. Раскрытие связей типа m:n.
- •3.9.10. Раскрытие связей типа 1:1.
- •Связь 1:1 с одним необязательным концом.
- •Связь 1:1 с двумя необязательными концами.
- •Связь 1:1 с двумя обязательными концами.
- •3.9.11. Определение путей доступа запросов к данным.
- •Б) Уточнение триггера запроса.
- •В) Уточнение пути доступа запроса к данным.
- •3.9.12. Представление лмд пользователю.
- •3.9.13. Документирование лмд.
- •3.10. Краткое изложение процедуры
- •Приложение 1
- •2.2. Руководство по заполнению формы – «Описание объекта» – Часть 2
- •2.3. Руководство по заполнению формы – «Описание связи».
- •2.4. Руководство по заполнению формы – «Описание Атрибут/Элемент данных».
- •2.5. Руководство по заполнению формы «Описание сгруппированного домена».
Интерфейс процесс - данные.
Для максимизации устойчивости проекта к изменениям бизнес - среды или к технической оптимизации СУБД некоторые элементы конструкции процесса выборочно расширяются с целью изменения интерфейса между процессом и данными. Это помогает убедиться в том, что и для программ и для пользователей база данных может рассматриваться как реляционная, несмотря на то, что при физической реализации используются различные механизмы распределения памяти и хранения данных. При этом используются следующие подходы, которые помогают разработать интерфейс процесс - данные, включают:
• ранжирование СУБД;
• распределение данных (возможно использование однородной сети, состоящей из различных СУБД-продуктов);
• использование возможностей стандартных языков манипулирования данными (таких как SQL);
• заимствование элементов развитых иерархических СУБД.
1.6 Достоинства инвариантности к реализации проектов
Отличительной чертой подхода SSАDМ к физическому проектированию является наличие предварительно разработанной спецификации логической системы. Эта форма спецификации обеспечивает относительную независимость от конкретной реализации на объекте информатизации, что в свою очередь предоставляет следующие преимущества SSАDМ-проектам: инвариантность; гибкость; бизнес-ориентацию; прагматизм.
Инвариантность.
В случае, когда полная системная спецификация не привязана к конкретным программно-аппаратным решениям, проект пригоден для реализации до тех пор, пока он отвечает требованиям практики. Это имеет существенное значение при работе над большими и длительными проектами, обеспечивающими технологический или рыночный прорыв разработкам, которые ранее не выполнялись.
После внедрения (система может даже работать длительное время), по мере появлений более привлекательных альтернативных решений, в SSАDМ всегда есть возможность вернуться к логической спецификации, как основе для модификации системы в новой среде. При этом, если модификация не используется в качестве катализатора для перепроверки требований, составляющих основу бизнеса, и усовершенствования системы, то изменения, вносимые в логическую спецификацию, будут минимальными.
Общая инвариантность систем и их данных становится реалистичной и в данном случае уже не является недостижимой целью. Введение интерфейса процесс-данные представляет собой один из инструментов, помогающих в достижении этой цели.
Гибкость.
Логический проект оформляется без ориентации на точные фирменные технические решения, сильные и слабые стороны которых соответственно не будут упоминаться в логической спецификации. В ней будет содержаться набор обобщенных потенциальных технических решений, которые удовлетворяют логически упорядоченным требованиям.
Кроме прямых достоинств более широкого выбора, это также существенно облегчает воспроизведение систем по их архитектуре, например, воспроизведение системы в различных средах. Такой подход также обеспечивает высокую степень гибкости организационного управления реализацией проекта. Например, представляются возможности для организационного управления вариантами поэтапной разработки и заключения руководством контрактов на будущие поставки. При этом выбор руководства не должен ограничиваться наличием только одного поставщика сервисных средств.
Возможно, что ключевым достоинством, вытекающим из гибкости реализации состоит в том, что она способствует устойчивости к изменениям в бизнес-среде. Информационная система, содержащая в себе компоненты информационной технологии, дает возможность реализовать по мере развития системы новые бизнес-операции или вносить изменения в уже реализуемые.
Бизнес-ориентация.
Самым большим достоинством инвариантности к реализации является ее особое место при проектировании систем, удовлетворяющих потребности бизнеса. Естественна склонность разработчиков с самого начала проектировать средства реализации для каждой отдельной среды. Однако это может скомпрометировать методологию проектирования системы, так как некоторые необходимые элементы функционального наполнения могут быть исключены, если известно, что "продукт X" не сможет поддержать их. Это полностью противоречит концепциям SSADM, приматом которой при проектировании любых возможных систем является стремление полностью удовлетворять потребности бизнеса. Введение отвлекающих от функциональной по сути проекта характеристик, относящихся к стадии реализации проекта, на ранних стадиях проектирования может только нанести вред поиску наиболее подходящего проектного решения. На рис. 1.13 показывается тенденция наращивания степени детализации проекта системы по мере продвижения по стадиям жизненного цикла и отмечена область возможного начала реализации проекта.
Прагматизм.
Несмотря на сделанные выше замечания, существуют обстоятельства, при которых программно-аппаратная среда известна до начала физического проектирования или существуют весомые аргументы за реализацию системы в особой среде (основные примеры - совместимость и существование хорошей технической базы). Было бы неразумно пренебрегать этой ключевой информацией. Методология SSADM не препятствует этому, позволяя группе разработчиков извлечь максимум выгоды из имеющихся знаний о программно-аппаратной среде и эксплуатации возможностей этой среды при разработке логического проекта (см. рис.1.13).

Рис. 1.13. Иллюстрация независимости процесса проектирования от конкретной реализации физической системы
