
- •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.9.12. Представление лмд пользователю.
Очень важно, чтобы пользователь проверил точность каждой разработанной ЛМД. Поэтому необходимо на регулярной и неформальной основе обсудить с пользователем и остальными членами проектной группы эти модели и факторы, обеспечивающие их точность. Официально ЛМД представляется на рассмотрение по окончании этапов 110, 140, 320, 340, и 360.
Существенным фактором здесь является постоянная интерактивная обратная связь с пользователем. Однако это труднодостижимо, так как требует соответствующей подготовки пользователя и организационного управления процессом для обеспечения сквозного контроля качества модели.
Основное требование к процессу общения с пользователем состоит в том, чтобы диалог разработчика модели и пользователя происходил на терминологическом уровне, соответствующем уровню понятий пользователя о происходящих в системе процессах, но, тем не менее, была точным. Ни в коем случае нельзя опускаться до уровня жаргона.
В процессе представления модели не рекомендуется сразу показывать полную схему. Сначала даются понятия и определения по каждому обозначению так, как будто это делается впервые. Модель выстраивается для пользователя постепенно по частям (на одну часть не более пяти новых объектов), что позволяет показать ему различные аспекты информационных требований, сохраняя при этом структуру модели достаточно стабильной.
3.9.13. Документирование лмд.
Составление документации на ЛМД - процесс, протекающий на всем протяжении этапов 140, 320, 340, и 360. Документация обеспечивает поддержку достоверности ЛМД.
По окончании стадии 3 ЛМД требуемой системы будет состоять из окончательной ЛСД и заполненных описаний объектов, атрибутов и сгруппированных доменов (за исключением индикаторов состояния, которые добавляются в "Описание объект» на этапе 520). Руководство по заполнению форм описаний приведено в приложении 2.
Обобщенная ЛСД не обеспечивается поддерживающей документацией.
При разработке ЛМД существующего системного окружения важно, чтобы дополнение ЛСД "Описаниями объектов", содержащими основные характеристики каждого объекта, а также связи и главные атрибуты к ним, производилось по мере обнаружения этой информации. Любая другая нужная информация, если она относится к требуемой системе аналогичным образом должна вноситься в эту документацию или регистрироваться в "Каталоге требований".
Для каждого объекта первыми идентифицируются те атрибуты, которые формирует части уникальных идентификаторов или ключей. После этого по мере появления вводятся формальные обозначения для других важных атрибутов. Там, где для нескольких элементов данных используются одинаковые проверки правильности и форматы, характеристики регистрируются в "Описаниях сгруппированных доменов”
ЛМД требуемой системы получается на этапе 320 путем модификации и расширения соответствующей ЛМД существующего системного окружения, исходя из информации о требованиях к новой системе, определяемых выбранной структуре проектируемой системы и содержащихся в "Каталоге требовании". На этом этапе должны быть заполнены формы с детальным описанием всех объектов, связей, атрибутов и сгруппированных доменов. Требования к новым данным должны быть обработаны так, чтобы можно было показать, где и как эти данные отражены на ЛМД.
Нефункциональные требования к ЛМД, содержащиеся в "Каталоге требовании", используются для внесения поправок в нее на этапе 320. Эти требования обычно
характеризуют уровень обслуживания, ограничения по доступу к данным, защиту данных, внешний надзор и управление, а также другие ограничения. Нефункциональные требования тоже должны быть обработаны так, чтобы можно было показать, где и как они отражены на ЛМД. Некоторые нефункциональные требования высокого уровня не могут быть полностью отражены на ЛМД, однако это должно упоминаться в "Каталоге требований". ЛМД, полученная как результат работ, выполненных на этапе 320, может потребовать дополнительных исследовании для дальнейшего уточнения модели.
Уже на стадии 1 удобно начинать документирование объемов объектов и связей. Это может помочь при выборе организационной структуры системы, а также потребуется при оценке пропускной способности и выборе структуры технических средств системы. После того как на этапе 360 получена ЛМД требуемой системы, на копии ЛДС можно отметить объемы объектов и связей (см. рис. 3.21). Значение объема объекта берется из поля "Среднее количество экземпляров" формы "Описание объекта", а объем связи подсчитывается, исходя из отношения объемов двух объектов, участвующих в связи.
Рис. 3.21. Пример ЛСД с отмеченными объемами
Логический размер каждого объекта подсчитывается путем суммирования логических размеров всех его атрибутов. Он должен содержать в себе размеры индикаторов состояния. Отметим, что может потребоваться более одного размера, если объект имеет параллельные жизни.