- •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.6.7. Группы исключающих связей.
Если участие экземпляра объекта в одной связи запрещает его участие в более других связях, то это означает наличие в схеме группы исключающих связи. Все связи, входящие в такую группу, должны иметь общий предметный объект и одинаковую характеристику мощности. На момент рассмотрения для любого экземпляра общего объекта может существовать только одна связь из группы ЛСД, группа исключающих связей изображается в виде исключающей дуги. Исключающие дуги рисуются возле соответствующего объекта и относятся к тем связям, линии которых пересечены этими дугами. Если необходимо, то связи можно переупорядочивать для того, чтобы вынести не участвующие и связи за ее пределы и таким образом избежать разрывов дуг и путаницы в схеме. Объект может участвовать в нескольких различных исключающих группах. В связи с этим на ЛСД различные исключающие дуги могут быть произвольным образом помечены. Однако, концы линий связи не должны участвовать более чем в одной исключающей группе, что гарантирует ясность и упорядоченность ЛСД. Полное документирование связей, входящих в исключающие группы, осуществляется при заполнении форм «Описание объекта».
На рис.3.5 изображен несколько видоизмененный фрагмент ЛСД, приведенной на рис. 3.1. Связи для этого фрагмента читаются следующим образом:

Рис.3.5. Пример необязательной группы исключающих связей
«Каждый район может быть или известен для включения в него одного или более населенных пунктов, или предложен для размещения в нем одной или более свободных площадок» (дуга пересекает пунктирную линию).
Исключающая группа, изображенная на рис. 3.6, является примером обязательной группы (дуга пересекает сплошную линию) и может быть прочитана следующим образом:
«Каждое предпочтение нанимателя жилья должно быть определено, как один и только один район или определено как один или только один населенный пункт».
«Каждое предпочтение нанимателя жилья должно быть выражено в одном и только одном заявлении».

Рис.3.6. Пример обязательной группы исключающих связей
Субтипы объектов.
Связи типа 1:1 могут использоваться в исключающих группах для того, чтобы дать базовое представление субтипов объектов. Например, для рис. 3.7, если читать от объекта «ЗАЯВЛЕНИЕ», получим утверждение:
«Каждое заявление должно быть или супертипом нового заявления или супертипом заявления на передачу, где «НОВОЕ ЗАЯВЛЕНИЕ» и «ЗАЯВЛЕНИЕ НА ПЕРЕДАЧУ» будут субтипами супертипа «ЗАЯВЛЕНИЕ»».
Супертип объекта имеет связи и атрибуты, которые являются общими для его субтипов, и в то же время, каждый субтип может иметь собственные связи и атрибуты. Обобщенное определение супертипов и субтипов лежит за пределами излагаемого в данной книге материала.

Рис. 3.7 Базовое представление супер- и субтипов
3.6.8. Рекурсивные связи.
Существует две основных ситуации, в которых удобно изображать объект связанным с самим собой, т.е. с рекурсивной связью.
Иерархия.
Первая ситуация представляет иерархические структуры, присущие организационному управлению на предприятиях. Такая структура изображена на рис. 3.8 и описывается следующими утверждениями:
"Каждый менеджер может быть ответственным за одного или более менеджеров";
"Каждый менеджер может быть ответственным перед одним и только одним
менеджером".
Заметим, что в этом упрощенном представлении оба конца линии связи должны быть необязательными. Это позволяет самому главному менеджеру не отчитываться перед другими менеджерами, а более младшим - быть подчиненными только одному менеджеру (см. рис.3.8а). Эта же структура может быть изображена в виде, показанном на рис. 3.86, где рекурсия представляет собой петлю, представляющую связь типа 1:m.
На рис. 3.9. показано уточненное представление иерархии, допускающее обязательный конец линии связи и описываемое с этого конца утверждением:
"Каждый менеджер должен быть или ответственным перед одним и только одним директором или ответственным перед одним и только одним менеджером".
Сеть.
Вторая ситуация характеризуется наличием связей типа m:n и наиболее часто возникает при описании технологии производственных процессов обработки материалов и сборки изделий. Здесь под действием некоторых процессов производятся сборочные единицы, из которых затем собираются другие более крупные сборочные единицы до тех пор, пока не будет получен окончательный продукт. Любое подмножество сборочных единиц здесь может входить в состав других подмножеств как их часть и может само состоять из других подмножеств.

Рис. 3.8 Представление иерархии организационного управления рекурсивной связью

Рис.3.9 Уточнение представления иерархии организационного управления
Рекурсивная связь, показанная на рис. З.10а, может быть прочитана следующим образом:
"Каждое подмножество может быть использовано в одном или более подмножеств";

Рис. 3.10. Раскрытие рекурсивной связи для технологии обработки материалов и сборки изделий
«Каждое подмножество может быть собрано из одного или более подмножеств».
Заметим, что в данном случае оба конца линии связи должны быть необязательными, так как имеются окончательные продукты, которые не являются сборочными единицами, и есть элементарные подмножества, не имеющие в своем составе сборочных единиц. Здесь базовое обозначение для рекурсии - петля, характеризуемая степенью связи m:n. Связи такого вида необходимо раскрывать путем замены ее на две связи типа 1:m, как это показано на рис. 3.106. Новые связи читаются следующим образом:
"Каждое подмножество может быть использовано как одна или более стандартных компонент";
"Каждое стандартная компонента должна быть использована в одном и только в одном подмножестве";
"Каждое подмножество может быть собрано из одной или более стандартных компонент";
"Каждая стандартная компонента должна быть в списке элементов одного и только одного подмножества".
Наименее общим, а потому редко встречающимся видом связи, является связь со степенью 1:1. Обычно этот вид связи используется для отображения возможности замены экземпляра объекта (например, один стандартный элемент может быть заменен другим, если первого нет на складе). В этом случае, если один из концов связи не входит в исключающую группу, оба конца связи должны быть необязательными.
