- •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. Руководство по заполнению формы «Описание сгруппированного домена».
Содержание
Введение
1. Основные концепции системного анализа и проектирования в SSADM
1.1. Цели и концепции
1.2. Структурная модель SSADM, ее назначение, роль и состав
1.3. Жизненный цикл разработки систем
1.4. Ключевые понятия и философия
1.5. Сценарий применения методов
1.6. Достоинства инвариантности к реализации проектов
1.7. Информационно-технологическая поддержка
2. Моделирование потоков данных
2.1. Назначение метода
2.2. Обзор
2.3. Место метода моделирования потоков данных в SSADM технологии
2.4. Входы МПД
2.5. Выходы МПД
2.6. Основные понятия и обозначения метода моделирования потоков данных
2.7. Техника моделирования потоков данных
2.8. Заключение
3. Логическое моделирование данных
3.1. Назначение
3.2. Обзор
3.3 Использование ЛМД в SSADM - технологии
3.4 Входы логического моделирования данных
3.5 Выходы логического моделирования данных
3.6 Основные понятия и обозначения метода логического моделирования данных
3.7. Понятия логического моделирования данных, не изображаемые на ЛСД
3.8 Вспомогательные понятия из SSADM - технологии
3.9 Использование метода в процессе проектирования
3.10. Краткое изложение процедуры
Заключение
Литература
Питеру Спрингу, человеку, открывшему
для нас мир SSADM, посвящается
Введение
Темпы развития современного общества во всех его проявлениях во многом определяются достигнутым уровнем информатизации. Одним из основных факторов, оказывающих влияние на процесс информатизации, является наличие современной технологии и инструментальных средств проектирования сложных информационно- управляющих систем (ИУС), под которыми понимаются системы сбора, хранения, обработки информации независимо от функционального назначения. Хорошо отлаженная технология является той основой, на базе которой разрозненные инструментальные технологические средства могут быть объединены и представлены в виде систем автоматизированного проектирования.
Проектирование сложных ИУС, независимо от сферы их применения, является процессом, требующим больших затрат ресурсов и времени, а также привлечения большого количества высококвалифицированных специалистов. Однако при отсутствии стандартизованной индустриальной технологии проектирования нет никаких гарантий создания эффективной или даже просто работоспособной ИУС. Это объясняется тем, что в данной ситуации качество результатов проектирования в основном определяется личным опытом, знаниями, эвристическими соображениями и предпочтениями разработчиков. В конечном счете, наблюдается невоспроизводимость результатов, отсутствие преемственности при смене специалистов, трудности восприятия и понимания концепций разработки из-за уникальности ИУС, разработанных различными коллективами даже для однотипных объектов информатизации.
Возможным путем преодоления указанных недостатков в середине 60-х годов считалась идея типового проектирования. Предполагалось, что коллективы высококвалифицированных разработчиков смогут создать для типовых объектов эффективные ИУС, которые впоследствии будут тиражироваться с малыми затратами труда и ресурсов. Однако сейчас уже можно однозначно утверждать, что типовое проектирование не оправдало возлагаемых на него надежд. Это связано с уникальностью даже однотипных объектов по структуре, технологии обработки информации, предпочтениям руководителей и т.д. В этих условиях объект необходимо уложить в прокрустово ложе типового проекта информатизации, что противоречит здравому смыслу и нереализуемо, и что подтвердилось на практике. Осознание этого потребовало интенсивных усилий по поиску альтернативных путей совершенствования методов и средств проектирования ИУС. Таким альтернативным путем является создание высокоэффективных систем автоматизированного проектирования (САПР), позволяющих в кратчайшие сроки проектировать ИУС для любого объекта с учетом его конкретных особенностей и требований пользователей. Автоматизированные системы проектирования и инструментальные средства создавались крупными фирмами-разработчиками ИУС для собственных нужд и поэтому стали тщательно охраняемой интеллектуальной собственностью, которая недоступна широкому кругу специалистов.
Вместе с тем масштабы работ по информатизации современного общества требуют стандартизации и унификации технологий проектирования ИУС как на национальном, так и межгосударственном уровнях. Анализ процессов информатизации в развитых странах показал, что негативные тенденции здесь могут быть преодолены только путем вмешательства на государственном уровне. Еще в 70-х годах в Великобритании, США, Франции, Италии и других странах были разработаны и приняты на правительственном уровне государственные программы создания и развития индустриальных технологий проектирования ИУС. В 1989 году на Мадридской конференции представителей правительств стран - членов ЕС обсуждалась инициатива гармонизации методов разработки ИУС. Было достигнуто соглашение о создании "Еврометода", базирующегося на существующих и апробированных на практике методологиях проектирования: SSADM(Structured System Analysis and Design) (Великобритания), Merise (Франция), IDEF (США), NIAM (Италия), МАМ (Нидерланды).
Среди перечисленных выше методологий одной из наиболее развитых является SSADM (Методология структурного анализа и проектирования систем), работы по созданию которой были начаты еще в середине 70-х годов. Координация и финансирование этих работ осуществлялось британским государственным Агентством по Информатике и Вычислительной Технике - ССТА (Communication and Computer Agency). В 80-х годах SSADM была значительно усовершенствована и доведена до уровня индустриальной технологии, а в 1990 году была официально принята ее 4-я версия, ставшая в 1993 году общенациональным стандартом Великобритании.
SSADM является ярким примером реального воплощения принципа проектирования "сверху вниз" в технологии создания сложных ИУС. Он сочетает в себе простоту применения системными аналитиками средней квалификации, точность определения результатов проектирования, согласованность с современными стандартами и методологией управления проектными работами (PRINCE), гибкость в применении к проектированию широкого класса систем для различных типов объектов, гарантии качества результатов проектирования и преемственность различных версий проектов. Каркас SSADM описывается структурной моделью, основными элементами которой, в зависимости от уровня иерархии, являются модуль, стадия, этап или задача. Это делает технологию проектирования четкой и ясной, легко автоматизируемой, а также создает предпосылки для привязки методов проектирования к конкретным элементам структуры через так называемые "описания действий". Методическое обеспечение 4-й версии SSADM состоит из 13-ти методов структурного системного анализа и проектирования, объединяемых в одно целое вышеупомянутой структурной моделью.
Создатели технологии SSADM руководствовались следующими принципами, удовлетворяющими требованиям современной информационной инженерии:
• постоянное вовлечение представителей будущих пользователей в процесс выработки решений на протяжении всего проектирования ИУС;
• четкая структуризация технологического процесса, взаимная увязка всех стадий, этапов, и проектных процедур, явная регламентация ролей всех участников разработки;
• эффективный контроль хода разработки со стороны руководителей проекта, встроенный контроль качества проектирования по формализованным критериям;
• возможность применения существующих технологий автоматизированного управления разработкой;
• стыковка с технологиями, реализованными в существующих системах программирования и управления базами данных;
• формализация процесса разработки, обеспечивающая широкое применение средств автоматизации проектирования. С целью облегчения автоматизации проектирования авторы технологи SSADM достаточно четко разграничили неформализуемые и сравнительно легко формализуемые виды деятельности в процессе создания ИУС.
Основным продуктом, создаваемым по технологии SSADM, является комплект документов, на основе которых может быть реализована разрабатываемая ИУС. Последовательность выполнения технологических стадий и этапов, состав разрабатываемых на них проектных документов и применяемые методики проектирования тщательно продуманы и четко регламентированы. Это значительно упрощает управление проектом и способствует обеспечению требуемого качества выполняемых работ.
Первое знакомство с перечнем проектной документации, разрабатываемой в соответствии с технологией SSADM (свыше 50 форм документов), может повергнуть в уныние своей громоздкостью даже искушенного специалиста. Однако попытки отказаться практически от любого документа с целью экономии времени и трудозатрат приводит впоследствии к нарушению технологического процесса и не позволяет достичь такого высокого качества проектирования, которое может обеспечить данная технология при ее строгом соблюдении. Как признают авторы четвертой версии SSADM, без применения средств автоматизации проектирования ее можно реализовать при разработке лишь небольших учебных проектов. Поэтому наличие хотя бы простейших средств в распоряжении пользователей этой технологии является необходимым условием. Однако разработка таких средств является самостоятельной задачей и не входит в технологию SSADM.
Таким образом, основная цель стандартизации и разработки информационной технологии проектирования сложных ИУС состоит в создании методологии и инструментария, позволяющих повысить эффективность процессов проектирования, формализации и унификации, как проектных процедур, так и используемого при этом инструментария, жесткой регламентации последовательности этапов и их документирования, встроенной системы контроля качества и управления разработкой.
Соблюдение этих условий обеспечивает:
• воспроизводимость результатов (возможность повторной реализации проекта другими коллективами разработчиков);
• повышение качества, сокращение сроков и затрат на проектирование;
• возможность контроля и управления;
• снижение требований к уровню квалификации разработчиков;
• возможности автоматизации процесса проектирования (использование CASE - технологии);
При этом индустриальная технология должна быть:
• самопроверяемой;
• основанной на апробированных методах;
• удобной и понятной проектировщику и заказчику;
• легко изучаемой и не требующей от пользователя уникальной квалификации.
К сожалению, Украина не имеет в настоящее время стандартизированной индустриальной технологии проектирования ИУС. Существующие стандарты группы 34 "Информационная технология" определяют этапы проектирования, но не технологию их выполнения. Работы по созданию национальной индустриальной технологии проектирования ИУС только стоят на повестке дня.
Исходя из вышесказанного, SSADM была выбрана в качестве базовой технологии при подготовке курсов лекций по предметам "Системный анализ, и проектирования ИУС" и "Системный анализ и технология проектирования компьютерных систем", читаемых студентам 3-го и 5-го курсов, обучающихся по специальности 7.080402 "Компьютерные системы проектирования".
Учитывая, что детальное, близкое к оригиналу изложение материалов по данной методологии на русском языки публикуется впервые, а также судя по отзывам специалистов, с которым авторам пришлось общаться в процессе подготовки рукописи книги, весьма вероятно, что она будет полезна для студентов и аспирантов смежных специальностей, а также широкого круга специалистов, занятых вопросами разработки и внедрения ИУС.
Монография написана на основе материалов, содержащихся в "Справочном руководстве по SSADM 4-й версии" /I/.
Эта часть монографии содержит основные концепции методологии SSADM, описание структурной модели технологии проектирования в среде SSADM и взаимосвязи между методами, составляющими основу методологии, а также подробное изложение двух методов, играющих ведущую роль на начальных стадиях проектирования ИУС: метода моделирования потоков данных и метода логического моделирования данных. Таким образом, основное внимание уделяется наиболее сложным и слабо формализованным этапам проектирования и концептуальным аспектам построения современной технологии проектирования сложных ИУС.
Авторы с удовольствием выражают свою благодарность студентам кафедры системотехники факультета компьютерных наук института компьютерных информационных технологий Харьковского государственного технического университета радиоэлектроники Гнездилову А.В. и Мартыненко С.Г. за большую работу по оформлению и изготовлению оригинал-макета книги.
Авторы надеются, что им удастся опубликовать дальнейшие выпуски с изложением методов SSADM технологии. Во многом это будет зависеть от того, какой будет реакция на настоящий выпуск. Поэтому просим все критические замечания и пожелания направлять по адресу: 310726, г. Харьков, пр. Ленина, 14, Харьковский государственный технический университет радиоэлектроники, кафедра системотехники, тел. (0572) 40-93-06.
По этому же адресу можно заказать настоящее издание.
1. Основные концепции системного анализа и проектирования в ssadm
В этой главе с позиций, интересующих разработчиков информационных систем, будут детально описаны идеи и концепции, положенные в основу SSADM с точки зрения:
• целей;
• участников процесса проектирования и их взглядов на этот процесс;
• ключевых понятий;
• методов;
• инвариантности к особенностям объектов информатизации;
• информационно-технологической поддержки процесса проектирования.
1.1. Цели и концепции
Цель SSADM состоит в том, чтобы помочь проектной группе адекватно проанализировать требования к ИУС, выбрать стратегию ее разработки, спроектировать и специфицировать такую информационную систему, которая наилучшим образом удовлетворяет этим требованиям.
Работа начинается только при наличии документа (технического задания), в котором для проектной группы кратко определены:
• назначение и бизнес - требования, которые необходимо удовлетворить;
• четко сформулированные и достижимые цели.
В выполнении проекта участвуют три группы специалистов:
• пользователи (участие);
• менеджеры (управление);
• разработчики (проектирование).
Организация взаимодействия этих групп специалистов является одним из основных приоритетов рассматриваемой методологии проектирования. Поэтому важно четко определить ролевые функции этих групп.
1.1.1. Пользователи.
Потребностям пользователя в SSADM присваивается наивысший приоритет, а привлечение пользователя к выполнению проекта четко определяется. Привлекаются они в основном при формулировании потребностей их бизнеса, при определении процессов принятия решений на всех уровнях и делается это при выполнении всех фаз проектирования. Поэтому терминология, форма представления результатов, в том числе графические обозначения должны быть легко воспринимаемым пользователем и способствовать высокоэффективной связи между ними в группе анализа. Такая двусторонняя связь вводится для того, чтобы обеспечить более ясное понимание действительных требований пользователя. В целом это значительно повышает вероятность успешной реализации окончательного варианта системы.
1.1.2. Менеджеры.
Структурный продуктно - ориентированный подход, используемый в SSADM, обеспечивает менеджерам проектов, выполняемых с помощью данной технологии всевозможную поддержку. Это графически иллюстрируется структурной моделью, которая проясняет иерархическую структуру модулей, стадий, этапов и задач.
В ней также явно показана "информационная шина", обеспечивающая среду для связей, объединяющих практические действия в технологии с ее продуктами и организационным управлением всего проекта.
Структурная модель помогает в любое время видеть:
• какая работа выполняется;
• какие цели должны быть достигнуты;
• какие продукты уже разработаны, и какие должны быть разработаны;
• какие методы и средства используются при выполнении этих разработок.
Кроме того, для каждого метода определены этапы, на которых он применяется. Следовательно, для проекта может быть составлен график изменения потребности в специалистах, что поможет в планировании удовлетворения потребностей конкретного проекта. Знание этого позволяет также заранее спланировать потребности в найме на работу и обучении.
Таким образом, создаются условия, позволяющие менеджерам, работающим по данной методике организационного управления проектом самостоятельно планировать, наблюдать и управлять своими проектами. Методика также позволяет решать такие взаимосвязанные технические и организационные задачи как управление качеством, оценка риска, организационное управление конфигурацией и ресурсами.