- •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.9.3. Идентификация связей.
Эта задача в основном решается на этапах 110, 140 и 320. Идентификация связей является наиболее трудной задачей логического моделирования данных, так как для каждой пары объектов (или рекурсии объекта) необходимо проверить, нет ли возможности описать ее как один объект в терминах некоторого другого объекта, т.е. осуществить проверку на избыточность связи. Здесь также рассматриваются степень, жесткость, множественность, фразы-описатели связей и принадлежность связи к исключающей группе. Должна быть выполнена проверка и других ограничении, накладываемых на отдельные связи, таких как мобильность и полнота связей между имеющимися объектами.
3.9.4. Формирование лсд.
Разработка ЛСД является итеративным процессом, так как ЛСД подвергается преобразованиям на протяжении выполнения проектных процедур стадий 1 и 3 SSADM - технологии. Кроме того она может быть трансформирована и на стадии 2.
Процесс формирования ЛСД начинается с того, что рисуется несколько так называемых "грубых" моделей специально для инициирования дискуссии с пользователями, а затем идет итеративный процесс уточнения ЛСД. Это обусловлено тем, что на ранних стадиях анализа аналитик не имеет достаточного количества информации для построения "совершенной" ЛСД. Поэтому аналитик должен быть готов к тому, что ему надо будет перерисовывать ЛСД до тех пор, пока не будет получено решение, удовлетворяющее всем известным ему требованиям.
Уровень детализации ЛСД должен полностью соответствовать уровню детализации модели потоков данных и нарастать в направлении от обобщенной ЛСД к ЛСД требуемой системы.
Размеры ячеек на схемах можно варьировать, если в них необходимо разместить длинные имена объектов или добавить новые связи, но при этом надо помнить, что пользователи склонны связывать размеры ячеек с их значимостью.
Главные объекты должны располагаться на схеме выше вспомогательных, таким образом, ссылочные объекты окажутся расположенными вдоль верхней кромки рисунка. Если количество главных объектов невелико, то они могут быть изображены в центре листа, и наоборот, объекты, участвующие в большом количестве связей в качестве вспомогательных, рисуются в нижнем левом или нижнем правом углу листа.
При формировании ЛСД аналитик дополнительно мысленно должен учитывать следующие факторы:
• цель разработки для обеспечения ясности, простоты и содержательности;
• минимизацию пересечения линий связи;
• важность точности и размещения элементов схемы;
• запрет на использование аббревиатур;
• полноту именованности концов связей.
3.9.5. Присвоение имен связям.
Имена должны присваиваться связям в момент появления их на схеме. Именование связей с обоих концов линий позволяет сразу же определить и удалить ненужные связи, обнаружить слабое понимание сути некоторых связей и в то же время убедиться в необходимости остальных. Из этого следует важность четкости составления фраз-описателей линий связей. Эта задача не является тривиальной, поэтому ее решение ну. можно доверять только опытным .высококвалифицированным аналитикам. Предполагается, что утверждения должны быть точно сформулированы, исходя из информационных требований, которые пользователь может понять и оценить. Легкость прочтения связей позволяет аналитику на ранних стадиях выявить особые ситуации и требования, зависимость от времени, и другие специальные случаи. При таком подходе модель обеспечивает выбор оптимального механизма обработки информации и соответствующей ему конструкции системы. Это позволяет избежать необходимости решения многих проблем, возникающих обычно на стадии внедрения сложных информационно - управляющих систем из-за того, что разработчики просто не знают об этих особых ситуациях. Это незнание, в конечном счете, приводит к существенным потерям из-за очень высокой стоимости исправления ошибок проектирования на завершающих стадиях создания таких систем.