- •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. Руководство по заполнению формы «Описание сгруппированного домена».
2.7.4.2. Связь между потоками данных и событиями
В SSADM есть два способа идентификации входных данных в анализируемой системе. Во-первых, потоки данных идентифицируются и изображаются на СПД. Во-вторых, события, которые воздействуют на объекты, определяются при анализе "Истории жизни объекта" и документируются в ИЖО-схемах. Оба способа используют терминологию элементов данных. Суммарный поток данных обычно содержит в себе одно событие или пакет событий. Аналитик, разрабатывающий МПД ТС для обоснования принимаемых решений, должен быть заинтересован в выявлении связей между потоками данных и событиями. Этому обоснованию и решению задачи определения функций системы может помочь следующий перечень правил:
• один поток данных может нести пакет событий ( аналитик, чтобы обеспечить простоту СПД, обычно предпочитает рисовать один входной поток данных, вмещающий в себя пакет событий и отражающий поступающие в систему данные). Такой пакет может быть входом в режимах "он-лайн" или "оф-лайн";
• входной поток данных может изображать варианты пакетирования событий. СПД в этом случае должны представлять несколько (возможно много) допустимых вариантов. Это могут быть пакетирования, которые пользователь или аналитик интуитивно признают приемлемыми, либо пакетирования, описывающие структуру организации работ в существующей системе;
• допускаются пакеты событий внутри одного потока данных. Пакетирование обычно экономит время и работу пользователя и компьютера. Например, минимизирует время, требуемое для ввода данных и для доступа к хранимым данным. В методике определения функций перечислено несколько объективных критериев пакетирования;
• события одного типа могут переноситься несколькими потоками данных, но любое конкретное событие должно полностью включаться только в один поток данных;
• входной поток данных может представлять собой фиктивное пакетирование событий (считается разумным собрать несколько событий вместе в один поток с целью сокращения размеров СПД, несмотря на то, что события никогда не появляются одновременно на входе системы. Если это сделано, то из одного входного потока данных должно быть выделено несколько функций, вероятно по одной для каждого события);
• нежелательно вводить отдельные потоки данных и процессы для каждого отдельного события и даже для каждого пакета событий, если они поступают вход совместно. (Так пользователи обычно хотят видеть данные в таком виде, в каком они обычно вводятся, и при этом лучше показывать отличия между отдельными преобразованиями в базе данных. Тогда на СПД последнего уровня должны показываться отличия между входными потоками данных по каждому из известных событий, однако это значительно увеличивает количество схем нижнего уровня при несущественном влиянии на результат анализа системы).
2.7.4.3. Проверка правильности по другим продуктам технологии
Результаты разработки МПД ТС должны быть отражены в других продуктах SSADM-технологии:
• ЛМД ТС (разрабатываемой параллельно с МПД);
• документе «Каталог требований»;
• документе "Роди пользователя".
Проверка соответствия ЛМД ТС и МПД ТС
Аналитик должен пометить связи между главными логическими хранилищами данных МПД и объектами ЛМД. Для этого составляется документ "Таблица перекрестных ссылок Логическое хранилище данных/Объект", в, котором при разработке моделей регистрируются все изменения.
Заполнение «Каталога требований»
"Каталог требований" заполняется с соответствующими ссылками на те элементы МПД, которые обеспечивают реализацию требуемой функции системы.
Аналитик должен быть уверен в том, что требования, введенные в «Каталоге требований" выполнимы при тех входах, выходах, информационных объектах и функциональном разбиении, которые представлены на модели.
Согласование с документом «Роли пользователя»
На СПД ТС различают два типа внешних объектов:
• объекты, которые являются внешним» по отношению ко всей системе в целом;
• объекты, которые являются частью системы, но остаются внешними по отношению к ее автоматизированной части.
В процессе разработки МПД ТС аналитик должен обеспечить согласование имен внешних объектов второго типа и ролей пользователя, т.е. внести ясность в понимание роли, отведенной пользователю, изображенному на СПД в виде внешнего объекта.
Однако, если при определении роли пользователя возникают трудности, то необходимо сравнить описание внешнего объекта и связанных с ним процессов с их описаниями в документе "Роли пользователя".