- •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. Руководство по заполнению формы «Описание сгруппированного домена».
1.5.2.2. Взаимодействие методов в модуле ка (Анализ требований).
В этом модуле исследуется существующая система (стадия 1) и обеспечивается организационное управление выбором варианта бизнес - системы. Используемые здесь методы заключаются в конструировании моделей бизнес - операций (схем потоков данных) и информации, используемой в бизнесе (логическая модель данных). Эти модели перекрестно ссылаются одна на другую через "Каталог требований" и "Каталог пользователей". Ниже кратко описаны задачи, которые решаются в этом модуле различными методами.
"Определение требований".
Пересматриваются системные цели и бизнес - цели и идентифицируются основные пользователи, на основании чего составляется "Каталог пользователей". Затем посредством опроса и других методов уточняются требования. Цель здесь состоит в определении возможности представления каждого требования в количественном виде. На рис. 1.9 для модели потоков данных это выражается связями 1 и 2, а дня описания объектов на логической модели данных - связью 6.

Рис.1.9 Связи между методами при реализации модуля «Анализ требований»
"Моделирование потоков данных".
Для каждой процедуры существующей системы аналитик определяет внешние объекты (пользователей и/или другие системы), информационные потоки, как пересекающие границу системы, так и текущие внутри нее, процессы, активизируемые при поступлении сообщений, и память, отведенную для хранения информации. Результаты этого анализа помещаются в "Каталог требований" (связи 1 и 2). Важной для логической модели данных является связь 3, так как хранилища данных должны содержать в себе информацию только о реальных объектах.
"Логическое моделирование данных".
Хранящаяся и используемая для поддержки бизнес-функций информация моделируется с использованием методов формализации объектов, отношений и атрибутов. Нефункциональные требования (например, уровни обслуживания) регистрируются в "Каталоге требований". В качестве вспомогательного может использоваться метод реляционного анализа данных. Неформальное применение реляционного анализа данных может способствовать получению высококачественных моделей бизнес - данных.
1.5.2.3. Взаимодействие методов в модуле rs (Спецификация требований).
Разработка "Спецификации требований" состоит в повышении уровня детализации описания и точности представления требований. Эта информация необходима и особенно важна для:
• определения корректности спецификации функционального наполнения и описания данных;
• уточнения критериев, по которым пользователь может проверить достижимость системных целей.
"Определение требований".
Производится уточнение "Каталога требований" представляющее собой дополнение его новыми требованиями. После достижения соглашения о масштабе проекта, наибольшие усилия прилагаются к определению требований, с целью представления их в наиболее точном виде. В "Каталог требований" заносятся только те требования, которые в дальнейшем не могут быть лучше детализированы в виде функций, объектов и событий (на рис. 1.10 это изображено связями 10 и 11). "Каталог требований" обеспечивает перекрестные ссылки для средств представления и проверки требований пользователя.
"Моделирование потоков данных".
Параллельно с совершенствованием "Каталога требований" и логических схем потоков данных пересматривается и выбранный вариант бизнес - системы. Этот процесс также предполагает дополнительную детализацию по входам и выходам системы. Модель интерактивно обогащается при сверке с логической моделью данных (связь 3), но ее обогащение здесь не является основной целью. Цель этого процесса - получить данные, необходимые для применения метода "Определение функций". При этом каждый поток, текущий между внешним объектом и элементарным процессом, для определения функции оснащается признаком запуска (связи 1 и 2).

Рис. 1.10. Взаимосвязи между методами в модуле 'Спецификация требований'
