- •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.8.2. Ключи.
Рассматриваемые ниже понятия различных ключей, строго говоря, являются понятиями метода реляционного анализа данных, входящего в состав SSADM -технологии. Таким образом, нормализованные связи как результат такого анализа и модели, рассматриваемые в данной главе, по своей сути являются различными нотациями, используемыми для представления одной и той же информации. Объект эквивалентен отношению, а связь - соответствующему ключу.
Хотя это и не требуется непосредственно для построения ЛМД, но для достижения конечных целей проектирования рекомендуется записать:
• первичный ключ для каждого объекта, используя один из его уникальных идентификаторов;
• один или более внешних ключевых атрибутов, либо являющихся частью первичного ключа, либо нет (для того, чтобы представить каждую связь, идущую от вспомогательного объекта к главному). Это делается путем копирования первичного ключа главного объекта во вспомогательный.
Указанные действия должны выполняться в процессе построения ЛМД до окончания этапа 360, после выполнения которого большинство ключей должно быть внесено в документацию. Ключи вносятся в документацию в момент их обнаружения. Заметим, что если внешний ключ является частью первичного ключа вспомогательного объекта, то соответствующий главный объект не может быть мобильным, так как изменение ключа главного объекта влечет за собой изменение ключа вспомогательного объекта.
3.8.3. Ссылочные объекты.
Объекты, не являющиеся вспомогательными по отношению ни к какому другому объекту, называются ссылочными объектами. Они идентифицируются одним или несколькими атрибутами. Например, приведенный на рис. 3.1 объект "НАНИМАТЕЛЬ ЖИЛЬЯ" может в иметь качестве первичного ключа либо этот идентификатор, либо комбинацию своих атрибутов "Имя нанимателя жилья" и "Дата рождения". Однако, следует отметить, что это не лучший вариант первичного ключа, так как он уникален, что нежелательно при большом населении в данной местности.
3.8.4. Простые иерархические ключи.
Одной связи к главному объекту может быть недостаточно для идентификации вспомогательного объекта. Однако, его идентификатор в комбинации с атрибутами вспомогательного объекта может дать уникальный идентификатор, а следовательно и иерархический (композитный) ключ.
Изображенные на рис. 3.13, ключи "Код - района" и "Код - округа" использованы для того, чтобы идентифицировать объект "ОКРУГ". "Код - округа" сам по себе не является уникальным, но служит для того, чтобы различать округи внутри одного района. Связь, соединяющая объекты "ОКРУГ" и "РАЙОН", со стороны объекта "ОКРУГ" является обязательной и немобильной. "Код - района" используется для того, чтобы представить указанную выше связь объектов в полученном ключе, и включается в "Описание объекта" для объекта "ОКРУГ" как часть первичного ключа. Он также помечается как внешний ключ, чтобы указать на его принадлежность объекту "РАЙОН".

Рис. 3.13. Пример иерархического ключа "Район/Округ'
3.8.5 Составные ключи.
Объект "ПРЕДЛОЖЕНИЕ", изображенный на рис.3.14, является примером компоновки или пересечения объектов. Этот объект существует исключительно по причине существования объектов "ЗАЯВЛЕНИЕ" и "СОБСТВЕННОСТЬ". Для идентификации объекта "ПРЕДЛОЖЕНИЕ" используется комбинация связей с главными объектами. Первичный ключ здесь является комбинацией ключей "Номер заявления" и "Индекс собственности". Связи, идущие от объекта "ПРЕДЛОЖЕНИЕ" - обязательные и немобильные. Это один из возможных примеров составного ключа. Все его составляющие суть первичные ключи других объектов.
