
- •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.6.9. Разбиения.
При больших размерах ЛСД возникает необходимость выделения подсхем, разбиения исходной ЛСД на части. Один из способов получения таких частей использует следующие понятия:
• неполный объект, т.е. объект, имеющий связи и соединения с объектами, оказанными на подсхеме;
• неполная группа исключающих связей, означающая, что в группе имеются и другие связи, не показанные на подсхеме. Неполные объекты изображаются пунктирными ячейками и рисуются только те линии связи, для которых на схеме есть оба участвующих в связи объекта. Неполные группы исключающих связей изображаются в виде исключающих дуг с пунктирными краями, как это показано на рис. 3.11.
Рис. 3.11 Обозначение неполной группы исключающих связей
3.7. Понятия логического моделирования данных, не изображаемые на лсд
Здесь описываются понятия, которые используются при оформлении документации на ЛМД, но не изображаются при построении ЛСД. Они не так важны и фундаментальны, как понятия введенные в 3.5, но без знания этих понятий невозможно качественно заполнить формы документации, которые приведены в приложении 2.
3.7.1 Мобильные и немобильные объекты.
В некоторых случаях экземпляр предметного объекта может быть соотнесен экземпляру целевого объекта, а впоследствии они могут быть разнесены и первый экземпляр соотносится другому экземпляру целевого объекта. Такой целевой объект будет называться мобильным. Если это не разрешается по каким-либо причинам, то целевой объект будет называться немобильным. Например, собственность всегда будет находиться на какой-нибудь улице. С другой стороны, хотя собственность должна находиться в одной и только одной единице административного деления, местность может быть реорганизована, а в этом случае собственность перемещается из старого элемента административного деления местности в новый.
В строго обязательных связях целевые объекты всегда должны быть немобильными. В каждой необязательной связи целевой объект потенциально мобилен. Ниже в 3.7.5 и 3.8.2 разъясняется важность понятия немобильной связи при определении уникальных идентификаторов и ключей.
З.7.2. Атрибуты.
Атрибут – характеристика объекта, помогающая описать, классифицировать, идентифицировать, квалифицировать, тенить качество или выразить его состояние. Каждый атрибут является характеристикой одного и только одного объекта. Значение атрибута приписывается определенному экземпляру объекта, который в настоящий момент времени может иметь только такое значение. Примерами атрибутов объекта "ЗАЯВИТЕЛЬ" являются: "Имя", "Дата рождения", "Годовой доход". Примерами значений атрибута являются: "Джо Смит", "28 ноября 1952".
Атрибуты требуют тщательного определения. Они могут иметь весьма важное значение при отборе некоторых объектов или групп объектов (например таких, как все "ОПОЗДАВШИЕ ЗАКАЗЫ").
3.7.3. Обязательные и необязательные атрибуты.
Некоторые атрибуты прилагаются не ко всем экземплярам, соответствующих им объектов. Например, атрибут "Дата вербовки" применим только к заявителям, которые являются служащими. Атрибуты такого рода считаются необязательными и им может присваиваться нулевое значение, интерпретируемое как "не применяемый атрибут". Существует также другое использование нулевого значения, интерпретируемое как "обязательный, но отсутствующий в настоящее время".
Если значения атрибута должны быть указаны для каждого экземпляра объекта, например, в виде части идентификатора объекта, то атрибут считается обязательным. Однако и у обязательных атрибутов значения могут отсутствовать.