- •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.9.8. Удаление лишних связей из лсд.
Связи, которые являются потенциально лишними, выявляются в течение всего процесса логического моделирования данных, но особое внимание уделяется этой задаче на этапе 320. По мере разработки ЛМД может выясниться, что не все из множества идентифицированных связей необходимы для описания процесса функционирования системы. Некоторые связи могут действительно оказаться лишними. Лишней называется связь, которая дает доступ к той же информации что две или более других, т.е. в любых обстоятельствах выводимая из других связей.
Лишние связи могут иметь место в замкнутых циклах. Простейшая форма такого цикла показана на рис. 3.15а. Здесь одна из связей может быть удалена, если она действительно является лишней. Для того, чтобы определить это, необходимо рассмотреть семантику связей. Простой просмотр ЛСД без понимания реального смысла связей не дает возможности идентифицировать среди них лишние.
Структура, приведенная на рис 3.15а, не будет логически корректна, если объект С не относится через различные связи к двум различным экземплярам объекта А. В этом случае возможен доступ к С через В и наоборот. Тогда исходная структура после удаления лишней связи изображается так, как это показано на рис. 3.156. Связь, идущая от А к С, или удаляется или может быть оставлена на схеме как теоретическая линия, но тогда необходимо ее выделить для углубленного анализа на стадии физического проектирования базы данных. Еще один часто встречающийся вариант замкнутого цикла с идентификацией и удалением лишних связей показан на рис. 3.16. Данный пример является хорошей иллюстрацией того как решение задачи идентификации и удаления лишних связей приводит к рационализации ЛМД.
Рис.3.16 Пример дублирующей связи объектов
Однако здесь существует опасность незаметного удаления сложных элементов структуры, удовлетворяющих некоторым особым требованиям. Поэтому в процессе решения данной задачи необходимо тщательно проверять правильность принятых решений, чтобы еще раз удостовериться в том, что она удовлетворяет всем известным функциональным требованиям.
На этапе 360 должны быть окончательно проверены все пути доступа запросов к данным и "Схема распространения эффектов". В "Каталоге требований" должны быть задокументированы все удаленные лишние связи.
3.9.9. Раскрытие связей типа m:n.
На ранних стадиях разработки ЛМД может содержать в себе очень много связей типа n:m, которые обычно отражают правила деловой жизни данной организации.
К тому же связи данного типа часто оказываются полезными при обсуждении модели с пользователями.
Все связи типа n:m должны быть раскрыты к концу этапа 340, так как они скрывают понятия главный/вспомогательный объект и делают невозможным четкое определение путей доступа к данным. Раскрытие связи данного типа обычно осуществляется введением в схему связанного объекта, который разбивает эту связь на две связи типа 1:m. Несмотря на внешнюю простоту используемого приема преобразований структуры, его применение не механический процесс, а мощный способ структурного анализа. При этом из исходного объекта, содержащего не ключевые атрибуты, выделяется связанный объект, который более точно описывает главные объекты и природу связи между ними.
Например, можно допустить, что есть необходимость в связи типа n:m между объектами "ЗАЯВЛЕНИЕ" и "СОБСТВЕННОСТЬ", описываемой следующим утверждениями:
• "Каждым заявлением может быть предложен один или более экземпляр собственности";
• "Каждый экземпляр собственности может быть предложен по одному или более заявлениям".
Но тогда мы наблюдаем, что упущены характеристики, на основе которых "СОБСТВЕННОСТЬ" распределяется по "ЗАЯВЛЕНИЯМ", т.е. объект "ПРЕДЛОЖЕНИЕ", включающий в свой состав такие атрибуты как "Дата предложения" (см. рис. 3.14).
На ранних стадиях проектирования, когда используются связи типа m:n, желательно, чтобы хотя бы один из концов каждой из этих связен был необязательным.