- •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. Руководство по заполнению формы «Описание сгруппированного домена».
1.4.2. Ориентация на требования.
Для выявления критических требований в SSADM используется метод, получивший название "Определение требований". Этот метод характеризуется тем, что фокусирует внимание группы анализа на требованиях к будущей системе. Его цель состоит в том, чтобы обеспечить гарантии объективности собранной информации в самом начале анализа даже для тех требований, которые выражены в наиболее общем виде, чтобы определить способы детального исследования по всем трем видам моделей.
Метод "Определение требований" определяет приоритеты аналитика, работающего в SSADM. Центральным документом здесь является "Каталог требований", который постоянно используется в организационном управлении проектом, а также участниками процесса проектирования системы (см. рис. 1.4).
Отсутствие или наличие существующей системы меняет тактику, но не стратегию применения метода "Определение требований". Этот метод начинают применять на начальных этапах первого модуля, что фокусирует внимание группы проектировщиков на выделении бизнес - пользователей и бизнес-функций. Метод используется также и для формализации содержимого кратких отчетов предыдущих стадий стратегических исследований и анализа реализуемости.
Оформление и разработка "Каталога требований" является основной и постоянной целью стадии "Анализ требований". Особое значение придается выявлению как функциональных, так и нефункциональных требований и определению их в понятиях, которые явно и объективно измеримы. В этом случае "Определение требований" способствует разработке тестовых критериев, которые должны формироваться и параллельно применяться группами разработчиков функциональной модели и модели данных существующей системы.

Рис. 1.4. Требования, функции, диалоги
Следовательно, действия по определению требований всегда направлены на будущую систему. На стадии 1 исследуется существующая среда. Это означает, что, если имеются существующие компьютерные системы, то они могут быть промоделированы вместе с ручными процедурами, с помощью методов "Моделирование потоков данных" и "Логическое моделирование данных", которые подробно будут рассмотрены в следующих главах. В противном случае, процесс определения требований поддерживается моделями будущей организации бизнеса, предлагаемыми организацией-пользователем. Это может означать, что модели, поддерживаемые "Каталогом требований", могут регламентировать информацию и процедуры, с помощью которых планируется реализовать информационную технологию.
Ведущая роль метода "Определение требований" подчеркивает и другие фундаментальные характеристики SSADM. Параллельное формирование различных взглядов на систему посредством модели потоков данных и логической модели данных выполняется одновременно одной и той же группой разработчиков. Эти модели отображают два взаимодополняющих вида восприятия требований аналитиками. Ценность этого заключается в том, что в "Каталоге требований" выразительность требований, сформулированных на естественном языке, наращивается за счет большей точности языка схематического. Схемы сами по себе существенно облегчают пользователям проверку правильности требований при обсуждении их на обзорных сессиях.
"Каталог требований" итеративно уточняется на всем протяжении стадии 3 с целью получения "Спецификации требований", поэтому большинство входов здесь расширяется, декомпозируется и преобразуется в детальную спецификацию функций, данных и событий.
"Спецификация требований" представляет собой пакет нескольких спецификационных продуктов, совместно обеспечивающих полное описание требований к будущей системе.
Результатом анализа является спецификация, поэтому детальная форма представления информации имеет три вида:
• материалы по взаимодействию пользователя с системой, собираемые в процессе проектирования диалога;
• материалы по функционированию системы, собираемые в процессе определения функций;
• информационные требования, собираемые в процессе логического моделирования данных.
