- •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. Руководство по заполнению формы «Описание сгруппированного домена».
3.9.10. Раскрытие связей типа 1:1.
Связи этого типа также часто встречаются в ЛСД на ранних стадиях разработки. Причины этого явления те же, что и в предыдущем случае.
В окончательном варианте ЛСД все связи должны иметь главные и вспомогательные объекты, а также конец, примыкающий к вспомогательному объекту, - в виде "вороньей лапки". Как следствие к окончанию этапа 340, каждая связь этого типа либо должна исчезнуть из-за слияния двух объектов, либо - быть представленной как связь типа 1:m. Также как и в предыдущем случае, раскрытие связей типа 1:1 - мощный способ структурного анализа, который способствует определению новых объектов и связей. Он также полезен тем, что обеспечивает хорошую возможность перепроверки необходимости существования объектов, участвующих в таких связях.
Это объясняется тем, что за связями данного типа скрываются объекты - аналоги, появляющиеся за счет выбора различных первичных ключей для одного и того же объекта. После объединения таких объектов первичный ключ нового объекта должен быть одним из первичных ключей исходных объектов. Новый первичный ключ может быть создан только в том случае, если ни один из имеющихся ключей не подошел. Если два участвующих в связи объекта не представляют собой единый объект, то связь 1:1 необходимо представить на ЛСД в виде связи типа 1:m с отметкой вспомогательного объекта "вороньей лапкой".
Связь 1:1 с одним необязательным концом.
Два объекта объединяются в один с необязательными атрибутами, либо объект, примыкающий к необязательному концу связи, превращается в главный (это делается потому что обычно этот объект создается первым). Если неясно, какой из объектов создается первым, то решение о том, какой из объектов сделать главным, принимается после рассмотрения "Историй жизни объектов".
Связь 1:1 с двумя необязательными концами.
В этом случае необходимо проверить правильность данной связи, так как наиболее вероятно, что здесь пропущен, по крайней мере, один объект, через который объекты, изображенные на схеме, связаны между собой. После внесения в схему соответствующих исправлений на ней должны остаться связи 1:1 только с одним необязательным концом, которые были рассмотрены выше.
Связь 1:1 с двумя обязательными концами.
Наличие в схеме связи такого типа говорит о том, что оба участвующих в ней объекта создаются одновременно. Использование таких связей допустимо только в исключающих группах для того, чтобы представить на схеме супер- и субтипы объектов. При этом супертипы объектов рассматриваются как главные. В других случаях использования таких связей, если дальнейший анализ не обнаруживает, что один из этих концов необязательный, объекты могут быть объединены в один.
3.9.11. Определение путей доступа запросов к данным.
Пути доступа запросов к данным представляются в виде схем Джексона [4]. Путь строится для каждого запроса, а именно, для функций запросов и запросных компонент функций обработки данных, которые определены заранее. В конце концов, каждый запрос должен быть представлен в виде процесса доступа к данным. Полностью процедура получения таких процессов завершается на стадии логическою проектирования базы данных, поэтому здесь описываются только первые три действия этой процедуры (ниже а, б, в). Они реализуют важный метод оценки правильности ЛМД и выполняются на этапе 360. Остальная часть процедуры выполняется на этапе 530.
Для обеспечения уверенности в том, что соблюдаются все логические требования к функционированию и ЛМД корректна, в процессе определения и оценки правильности путей доступа в нее могут вводиться новые объекты и связи. В качестве альтернативы такому решению для гарантии правильности может использоваться пронесено - ориентированное решение (например, сортировка). Выбор между информационно- и процессно-ориентированым решением по сути является произвольным и при физическом проектировании базы данных может быть изменен. Отметим, что редактирование ЛМД предпочтительнее, если введение новых объектов и/или связей полностью соответствует терминологии предметной области системы и/или поддерживает основные требования к ней.
а) Уточнение имени запроса.
Запрос должен быть идентифицируемым по уникальному имени, которое использовалось при определении соответствующей функции и в спецификации физического процесса. Как только для запроса найден путь доступа, имя запроса может использоваться в качестве имени этого пути.