- •1. Основные концепции системного анализа и проектирования в ssadm
- •1.1. Цели и концепции
- •1.1.1. Пользователи.
- •1.1.2. Менеджеры.
- •1.1.3. Разработчики.
- •1.2 Структурная модель ssadm, ее назначение, роль и состав.
- •1.2.1 Модули.
- •1.2.2. Входы модулей.
- •1.2.3 Выходы модулей.
- •1.2.4. Обозначения структурной модели
- •Информационная шина.
- •Организационные действия.
- •Соглашения, принятые для облегчения понимания схем.
- •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. Избегайте интуитивного синтеза лмпд
- •1.9. Реальные ограничения
- •2.7.2.9. Спд и варианты бизнес-системы.
- •2.7.4. Мпд тс
- •2.7.4.1. Мпд тс и определение функций
- •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. Руководство по заполнению формы «Описание сгруппированного домена».
3.7.4. Сгруппированные домены.
Понятие сгруппированного домена при логическом моделировании данных используется для проверки правильности представления допустимых классов и диапазонов значений атрибутов, а также формирования правил выделения таких классов. Например, сгруппированный домен "ДАТА" для ЛСД "Жилищной системы" является классом созданным из атрибутов, описывающих подобные характеристики различных объектов ("Дата вселения", "Дата выезда", "Дата начала рентной платы" и др.).
Форма документа "Описание сгруппированного домена" предназначена для записи общих свойств атрибутов и может использоваться для сокращения трудоемкости поиска информации и анализа.
3.7.5. Уникальные идентификаторы.
Экземпляр объекта всегда должен быть уникальным, т.е. уникален не только объект существенно отличающийся своей натуральной формой от других объектов, но и экземпляр этого объекта, который должен отличаться хотя бы одним из своих свойств. Следовательно, должен существовать по крайней мере один уникальный идентификатор для каждого объекта. Уникальным идентификатором может быть:
• один или более обязательных атрибутов, относящихся к данному объекту (смотреть ссылочные объекты в 3.8.2);
• комбинация одного или более атрибутов объекта, участвующего в одной или более обязательных, немобильных связях (см. простые иерархические ключи в 3.8.1);
• комбинация одного или более атрибутов объектов, участвующих в двух и более обязательных, немобильных связях (см. составные ключи в 3.8.2).
Если один конец связи в обязательной исключающей группе является частью уникального идентификатора, то другой конец (концы) должен быть частью альтернативного уникального идентификатора. Связь между уникальными идентификаторами и ключами поясняется в 3.8.2.
3.8. Вспомогательные понятия
Здесь вводятся фундаментальные понятия, связывающие логическое моделирование данных с другими методами, используемыми в SSADM - технологии.
3.8.1. Главные и вспомогательные объекты.
Большинство связей, получаемых в процессе построения ЛСД, в зависимости от того, с какого конца линии связи они читаются, имеют степень1:m или m:1. После этапа 340 все присутствующие на ЛСД связи должны быть представлены в таком виде. Это обеспечивает ясность и иерархичность структуры, а также все необходимые предпосылки для применения метода объектно-событийного моделирования, логического проектирования процедур обработки в базе данных и физического проектирования базы данных.
Все связи в ЛСД могут быть представлены в виде связей, имеющих степень 1:m:
• m:n - связь может быть раскрыта, как две 1:m - связи с соответствующими линиями между двумя объектами;
• 1:1 - связь может рассматриваться как специальный случай связи 1:m, или оба объекта могут быть объединены.
Преобразование связей типа m:n и 1:1 объясняется в п.п. 3.9.9. и 3.9.10.
В связях типа 1:m главным называется объект, примыкающий к концу линии со степенью "один", а объект, примыкающий к концу линии связи со степенью "много", называется вспомогательным. Термины "главный" и "вспомогательный" указывают на роль объекта в данной связи точнее, чем любая из его характеристик. Объект может быть главным в одной связи и вспомогательным в другой. Каждый главный объект может иметь в подчинении несколько вспомогательных, а каждый вспомогательный объект может быть главным для некоторого множества вспомогательных объектов более низкого уровня. Простейшей формой представления сказанного выше является, изображенная на рис. 3.12, простая иерархия объектов. Описанные выше понятия также могут применяться и в более сложных структурах.
Например, два главных объекта могут иметь в подчинении один общий для них вспомогательный или один главный объект может иметь в подчинении два множества вспомогательных объектов.
Иерархическая структура, приведенная на рис.3.12. полностью соответствует следующим допущениям:
• для любого главного объекта все связанные с ним вспомогательные объекты достижимы;
• для любого вспомогательного объекта достижим главный.
Рис. 3.12. Связь типа 1:m