- •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.7. Информационно-технологическая поддержка
Использование информационной технологии для поддержки SSADM-проектов уже обсуждалось ранее, однако масштабы использования средств такой поддержкой заставляют еще раз выделить этот аспект.
С практической точки зрения достоинства информационной технологии заключаются в:
• общности знаний о правилах методологии;
• распространении человеческих возможностей на полноту и согласованность проверок правильности результатов проектирования;
• минимизации исходных данных;
• обеспечении возможности многократного использования определений дани) функций и т.п.;
• упрощении интеграции с существующей документацией по системной поддержке, использующей общий инструментарий проектирования.
Большинство работ, выполняемых в рамках SSADM-проекта, представляют собой сбор, обработку, переопределение и опросы по наиболее важным наборам данных. Наличие какой-нибудь формы компьютерной поддержки при этом необязательно, но очень желательно. Даже обычная словесная формулировка может сильно повлиять на качество документации и впоследствии отразиться на стоимости всей разработки в периоды, когда появляется необходимость использования этого материала. Поэтому важно обеспечить простой и удобный доступ разработчиков к этим материалам и их общение между собой в процессе проектирования. Здесь желательно применение электронной почты, сводных электронных таблиц и компьютерных средств их обработки.
Эффект от информационной технологии будет значительно большим, если она будет поддерживать решение задач анализа и проектные работы, а еще лучше, если она будет разработана специально для поддержки методологии SSADM. Независимо от того, как ее будут называть Workbench, САSЕ, IСАSЕ, IРSЕ, 4GL, или обозначат какой-то другой аббревиатурой, такой инструментарий и инструментальная среда могут принести определенные выгоды как в смысле количества и качества работ выполняемых группой разработчиков, так и в смысле управляемости проекта. Их использование также будет способствовать значительному развитию информационной инфраструктуры проектной организации. Это создаст предпосылки как для возникновения инструментария по организации и контролю информации, которая определяет точность информационной системы организации и ее мета-данные, так и для улучшения данных, обрабатываемых самой системой. Со временем такое организационное управление станет более удобным, т.к. такие стандарты, как IRSD (Словарь информационных ресурсов систем –Information Resource Dictionary Systems) и РСТЕ (Общие универсальные инструментальные оболочки – Portable Common Tool Environments) очистятся, утвердятся и получат поддержку разработчиков инструментальных средств.
Ясность взаимосвязи методов и продуктов в SSADM обеспечивает прекрасную возможность для разработки инструментария, который поможет реализовать потенциальные возможности данной методологии, и одновременно снизить нагрузка на группы анализа при документировании и проверке достоверности информации. Это высвободит квалифицированные кадры для менее рутинных действий, таких как опрос, обсуждение, оценивание и анализ.
В рамках SSADM для любого проекта желательно обеспечить следующие виды поддержки (хотя детальные требования к такому инструментарию могут быть определены только в свете конкретных потребностей проекта/организации):
• набор/редактирование текстов;
• рисование графиков;
• получение качественных твердых копий вышеуказанных материалов (в идеальном случае - интерфейс с возможностями DTP Desk Top Publishing);
• централизованный каталог и библиотека материалов проектирования;
• стандартизованная структура вышеуказанного (идеально с заранее определенными возможностями для поддержки каждого из основных методов отдельно, так и их комплексного применения);
• стандартизованная форма запросов/ответов;
• защищенный доступ к данным;
• архивирование/восстановление данных;
• управление конфигурацией (по меньшей мере, с возможностью организации управления версиями документации и процессами разработки системы (этот тип обслуживания подчеркивается "информационной шиной");
• поддержка многопользовательского и многопроектного режима работы для больших групп разработчиков;
• интерфейсы с другими элементами инфраструктуры информационной технологии.
