- •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.3.2. Связь с другими методами.
Моделирование потоков данных.
Каждое хранилище данных в схеме потоков данных (СПД) ставится в соответствие объекту в ЛСД. Потоки данных, проходящие через хранилища, являются модификациями объектов ЛСД. Модель потоков данных проверяется по признакам однозначного соответствия каждого объекта ЛСД единственному хранилищу данных СПД и наличия процессов, поддерживающих каждый объект. ЛСД проверяется на наличие путей доступа к требуемым данным для каждого элементарного процесса.
Определение требований.
В "Каталог требований" заносятся записи по требованиям к новой системе, сформировавшимся в процессе разработки ЛМД на стадии 1 "Анализ требований". На стадии 3 "Логическая спецификация системы" ЛМД требуемой систем корректируется в соответствии с новыми требованиями к проектируемой системе, возникшими в процессе разработки. Например, новые требования к данным ограничения по доступу к данным и т.д.
Варианты бизнес - системы.
Схемы ЛСД используются для упрощения процесса описания множества возможных структур проектируемой бизнес - системы.
Определение функций.
Каждая функция модификации данных и обслуживания запроса требует наличия пути доступа к данным на ЛСД. Для функций обслуживания запросов пути доступа оформляются как часть документации, создаваемой при разработке ЛМД. Для функций модификации данных маршруты доступа содержатся в так называемой схеме распространения эффектов, которая является результатом объектно-событийного (динамического) моделирования проектируемой системы.
Объектно-событийное (динамическое) моделирование.
Допустимая последовательность событии, воздействующих на объект ЛСД, описывается историей жизни каждого объекта. При динамическом моделировании, путем проверки ЛМД на правильность соответствия данной модели имеющимся историям жизни объектов, обычно удается обнаружить новые объекты и связи. С учетом этого корректируют полученную к моменту применения данного метода ЛМД требуемой системы.
Реляционный анализ данных.
Реляционный анализ данных и логическое моделирование данных это взаимодополняющие методы, предназначенные для идентификации и уточнения требований к структуре данных проектируемой системы. ЛСД может быть выражена как набор нормализованных отношений и наоборот нормализованные отношения могут быть представлены в виде ЛСД. Метод логического моделирования данных полностью соответствует технологии проектирования "сверху - вниз", идентифицируя сначала основные объекты, а затем детализируя их и связи между ними. Реляционный анализ данных реализует принципы технологии "снизу - вверх", синтезируя произвольные группы данных в большие группы, которые соответствуют объектам и связям
ЛМД. Реляционный анализ обеспечивает глубокий сквозной контроль достоверность ЛМД. На этапах 140 и 320 реляционный анализ используется как неформальный метод анализа имеющейся документации. Кроме того, здесь он также может быть использован для проверки нормализованности ЛСД, а если неизвестна структура данных, то и для разработки первого варианта ЛСД. Формально этот метод используется на этапе 340 с целью анализа структур ввода - вывода и сопоставления результатов анализа с разработанной ЛМД требуемой системы [3,5,7,8].
Логическое проектирование процедур обработки данных.
Здесь пути доступа запросов вместе со структурами ввода - вывода используются для разработки моделей прохождения запросов в требуемой системе.
Физическое проектирование базы данных.
Элементам ЛМД ставится в соответствие их физическое представление (по возможности соответствие должно быть однозначным):
• логическое понятие ------- > желаемое физическое представление;
• тип объекта ----------------- > запись, таблица, файл;
• атрибут ---------------------- > физическая единица данных, колонка;
• связь -------------------------- > внешний ключ, индекс, цепочка указателей.