- •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. Руководство по заполнению формы «Описание сгруппированного домена».
2.6.1.5. Двунаправленный поток
На СПД 1-го уровня в виде потоков данных изображаются только главные входы и выходы. Дополнительные входы и выходы могут вводиться на более низких уровнях. На схемах должны присутствовать только истинные информационные потоки. На СПД верхних уровней можно использовать двухстрелочные потоки данных, для того чтобы отметить возможность появления на следующем уровне новых входных выходных потоков. Применение двунаправленных потоков должно ограничиваться уровнями СПД, лежащими выше последнего уровня. На последнем уровне все потоки должны быть однонаправленными. Чтобы гарантировать правильность схем необходимо убедиться в том, что такое преобразование сделано для каждого двухстрелочного потока данных и что оба направления новых потоков верны.
СПД всех уровней должны быть согласованы между собой. Любой поток данных нижнего уровня должен быть представлен на верхнем уровне простым одинарным потоком данных или частью двунаправленного потока.

Рис. 2.4. Изображение потоков данных
Поток данных (одинарный или двунаправленный) фактически может быть смесью отдельных потоков из СПД следующего более низкого уровня.
2.6.1.6. Поток данных между внешними объектами
Если необходимо показать информационные потоки между внешними объектами то их обозначают пунктирной линией так, как это показано на рис. 2.5.

Рис. 2.5. Информационный поток между двумя внешними объектами
2.6.1.7. Поток ресурса
Для изображения движения физических ресурсов (предметов отличных от документов) используется два структурных символа:
• широкая стрелка представляет движение физического ресурса (поток ресурса). Обычно это движение компонентов из одного места в другое, как на производственной линии;
• закрытый узкий прямоугольник представляет хранилище ресурса.
На рис. 2.6 приведен пример использования таких обозначений.

Рис. 2.6. Поток и хранилище ресурсов
2.6.1.8. Разрешенные спд - соединения
В таблице 2.1 приведены все допустимые варианты соединений элементов схем линиями потоков.
На рис.2.7 показано, как эти соединения изображаются на схемах.
2.6.2. Спд - иерархия
СПД должна быть простой и легко понимаемой. Одной СПД редко бывает достаточно для детального отображения системы, поэтому рисуется иерархический набор схем. Верхний уровень иерархии помечается как СПД 1-го уровня. Схемы 1-го уровня используются для определения масштаба системы. При этом учитываются внешние
источники и потребители данных, главные системные входы и выходы, главные функциональные признаки, а также граница между информационной системой и внешними объектами. На рис. 2.8. граница системы обозначена пунктирной линией. Системная граница устанавливается по потокам данных от внешних объектов и к ним.
Представление пользователей об основных функциональных особенностях системы отображается ячейками процессов на 1- м уровне СПД, а каждый из этих процессов может быть разбит на подпроцессы более низкого уровня, описываемые своими СПД. Каждая ячейка процесса может быть “окном” на схеме следующего уровня иерархии, который содержит более детальное описание потоков, хранилищ данных и процессов верхнего уровня.

Рис.2.7. соединения между процессами, хранилищами данных и внешними объектами
Таблица 2.1
-
Внешний объект
процесс
Хранилище данных
Хранилище ресурсов
Внешний объект
Только внешний поток данных и ресурсов
Да. Поток данных и ресурсов
нет
нет
процесс
Да. Поток данных и ресурсов
Да. Поток данных и ресурсов
Да
Только поток ресурсов
Хранилище данных
Нет
Да
Нет
Нет
Хранилище ресурсов
нет
Только поток ресурсов
нет
нет
Потоки данных никогда не объединяются один с другим и с потоками ресурсов
СПД 1-го уровня обычно содержит до 15-ти процессов. Каждый процесс 1-го уровня в свою очередь может быть разбит на 4-8 процессов 2-го уровня. Далее это будет рассмотрено на реальном примере, описывающем "Жилищную систему".

Рис. 2.8. Первый уровень СПД
Ячейка процесса 2-го уровня может быть декомпозирована далее, если это необходимо. Не рекомендуется, чтобы проектировщик разбивал процессы ниже 3-го уровня, т.к. обычно бизнес-среда может быть промоделирована на 2-м и 3-м уровнях. Процессы, которые не декомпозируются далее, определяются как процессы последнего уровня и помечаются так, как это показано на рис. 2.8. (процесс 5).
Некоторые процессы на 1-м уровне СПД могут быть простыми, а поэтому для их описания не требуются СПД более низких уровней.
