Файл: "Анализ и оценка средств реализации структурных методов анализа и проектирования информационной системы".pdf

Примерно в 1990 появляется термин «инженерия разработки ПО» (Information Engineering, IE, James Martin), являющаяся логическим расширением структурных методов, появившихся в течение 1970х.

3 Метод структурного анализа и проектирования SADT

SADT (Structured Analysis and Design Technique) – это методология инженерии разработки ПО (software engineering) для описания систем в виде иерархии функций (функциональной структуры).

Структурный анализ возник в конце 60-х годов в ходе революции, вызванной структурным программированием. Метод SADT был предложен Дугласом Т. Россом как способ уменьшить количество дорогостоящих ошибок за счет структуризации на ранних этапах создания системы, улучшения контактов между пользователями и разработчиками и сглаживания перехода от анализа к проектированию. Дуглас Т. Росс часть своих PLEX-теорий относящихся к методологии и языку описания систем, назвал «Методология структурного анализа и проектирования» (SADT). Исходная работа над SADT началась в 1969 г.

Первое ее крупное приложение было реализовано в 1973 г. при разработке большого аэрокосмического проекта, когда она была несколько пересмотрена сотрудниками SofTech, Inc. В 1974 г. SADT была еще улучшена и передана одной из крупнейших европейских телефонных компаний.

Таким образом, к началу 70-х SADT представляет собой четкую формальную процедуру.

Появление SADT на рынке произошло в 1975 г. после годичного оформления в виде продукта.

К 1981 г. SADT уже использовали более чем в 50 компаниях при работе более чем над 200 проектами, включавшими более 2000 людей и охватывавшими дюжину проблемных областей, в том числе телефонные сети, аэрокосмическое производство, управление и контроль, учет материально-технических ресурсов и обработку данных.

Ее широкое распространение в настоящее время в европейской, дальневосточной и американской аэрокосмической промышленности (под названием IDEF0) позволяет эти цифры существенно увеличить. Таким образом, SADT выделяется среди современных методологий описания систем благодаря своему широкому применению. Почему SADT имеет такое широкое применение?

Во-первых, SADT является единственной методологией, легко отражающей такие системные характеристики, как управление, обратная связь и исполнители. Это объясняется тем, что SADT изначально возникла на базе проектирования систем более общего вида в отличие от других структурных методов, «выросших» из проектирования программного обеспечения.

Во-вторых, SADT в дополнение к существовавшим в то время концепциям и стандартам для создания систем имела развитые процедуры поддержки коллективной работы и обладала преимуществом, связанным с ее применением на ранних стадиях создания системы.

Кроме того, широкое использование SADT показало, что ее можно сочетать с другими структурными методами. Это достигается использованием графических SADT-описаний в качестве схем, связывающих воедино различные методы, примененные для описания определенных частей системы с различным уровнем детализации.

Таким образом, неадекватные спецификации систем того времени вызвали создание графического языка SADT, а его усиленное использование преобразовало SADT в законченную методологию, способную повысить качество продуктов, создаваемых на ранних стадиях развития проекта.

Итак, SADT началась как язык описания функционирования систем общего вида, а по мере применения ее процедуры описания систем были улучшены и дополнены.

SADT использует два типа диаграмм: 1) модели деятельности (activity models); 2) модели данных (data models).

SADT использует стрелки для построения этих диаграмм и имеет следующее графическое представление:

• главный блок (box), где определено названии ее процесса или действия;

• с левой стороны блока – входящие стрелки: входы действия;

• сверху – входящие стрелки: данные, необходимые для действия;

• внизу – входящие стрелки: средства, используемые для действия;

• справа – исходящие стрелки: выход действия.

SADT использует декомпозицию на основе подхода «сверху вниз». Каждый уровень декомпозиции содержит до 6 блоков.

SADT начинается с уровня (level) 0^[1], затем может быть детализирован на более низкие уровни (1, 2, 3, ...). Например, на уровне 1, блок уровня 0 будет детализирован на несколько элементарных блоков и так далее.

На уровне 1 действие «Manufacture computers», может быть разбито (declined), например на 4 блока:

1) получить электронные компоненты («receive electronic components»);

2) сохранить электронные компоненты («store electronic components»);

3) доставить электронные компоненты на сборочную линию («bring electronic components to the assembly line»);

4) собрать компьютеры («Assemble computers»).

Семантика стрелок для действий (activities):

• входы (Inputs) входят слева и представляют данные или предметы потребления (consumables), нужные действию (that are needed by the activity);

• выходы (Outputs) выходят справа и представляют данные или продукты, производимые действием (activity);

• управления (Controls) входят сверху и представляют команды, которые влияют на исполнение действия, но не потребляются. В последней редакции IDEF0 – условия, требуемые для получения корректного выхода. Данные или объекты, моделируемые как управления, могут быть трансформированы функцией, создающей выход;

• механизмы означают средства, компоненты или инструменты, используемые для выполнения действия; представляют размещение (allocation) действий.

Семантика стрелок для данных (data):

• входы (Inputs) – это действия, которые генерируют эти данные (are activities that produce the data);

• выходы (Outputs) потребляют эти данные (consume the data);

• управления (Controls) влияют на внутреннее состояние этих данных (influence the internal state of the data).

Роли SADT-процесса:

• авторы (Authors) – разработчики SADT модели;

• комментаторы (Commenters) – рецензируют (review) работу авторов;

• читатели (Readers) – возможные (the eventual) пользователи SADT диаграмм;

• эксперты (Experts) – те, от кого авторы получают специальную информацию о требованиях и ограничениях;

• технический комитет (Technical committee) – технический персонал, ответственный за рецензирование (reviewing) SADT модели на каждом уровне;

• библиотекарь проекта (Project librarian) – ответственный за все документы проекта;

• менеджер проекта (Project manager) – имеет полную техническую ответственность за системный анализ и проектирование (has overall technical responsibility the system analysis and design);

• аналитик (Monitor) (Chief analyst) – эксперт в области SADT, помогающий и консультирующий персонал проекта по использованию SADT;

• инструктор (Instructor) – обучает авторов и комментаторов SADT.

Этапы моделирования. Одним из важных моментов при проектировании ИС с помощью методологии IDEF0 является точная согласованность типов внутренних связей по их характеру^[2].

В Таблице 2^[3] представлены все типы связей, рассмотренные выше. Важно отметить, что уровни 4 – 6 устанавливают типы связностей, которые разработчики считают важнейшими для получения диаграмм хорошего качества.

Разработка SADT модели представляет собой итеративный процесс и состоит из нижеследующих условных этапов.

1. Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. На этом этапе авторы опрашивают компетентных лиц, получая ответы на следующие вопросы:

• что поступает в предметную область на «входе»;

• какие функции и в какой последовательности выполняются в рамках предметной области;

• кто является ответственным за выполнение каждой из функций;

• чем руководствуется исполнитель при выполнении каждой из функций;

• что является результатом работы объекта (на выходе)?

На основе полученных результатов опросов создается черновик модели (Model Draft).

2. Распространение черновика для рассмотрения, получения комментариев и согласования модели с читателями. При этом каждая из диаграмм черновика письменно критикуется и комментируется, а затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает ее с изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению.

3. Официальное утверждение модели. Утверждение согласованной модели происходит руководителем рабочей группы в том случае, если у авторов модели и читателей отсутствуют разногласия по поводу ее адекватности. Окончательная модель представляет собой согласованное представление о системе с заданной точки зрения и для заданной цели.

Метод SADT получил дальнейшее развитие. На его основе в 1981 году разработана известная методология функционального моделирования IDEF0.

4 Метод структурного анализа и проектирования SSADM

SSADM (Structured Systems Analysis and Design Method) – системный подход к анализу и проектированию ИС.

SSADM как комплект стандартов для системного анализа и разработки приложений был разработан в начале 1980-х для Центрального агентства по компьютерам и телекоммуникациям (Central Computer and Telecommunications Agency, сейчас это Office of Government Commerce) – государственного учреждения UK, заинтересованного в использовании технологии в управлении.

Позже SSADM широко использовался для государственных ИТ-проектов в UK, затем нашел широкое применение во всем мире для проектирования ИС.

SSADM использует комбинацию текста и диаграмм для проектирования системы на всем ее жизненном цикле, от идеи до реального физического проекта приложения

SSADM использует комбинацию из трех методологий моделирования.

1. Логическое моделирование данных (Logical Data Modeling, LDM) – процесс идентификации, моделирования и документирования требований к разрабатываемой системе. Элементы логической модели данных:

• сущности (entities) – то, о чем фирме нужно записать информацию;

• связи (relationships) – ассоциации между сущностями.

2. Моделирование потоков данных (Data Flow Modeling) – процесс идентификации, моделирования и документирования движения данных в ИС. Моделирование потоков данных исследует:

• процессы (processes) – деятельность по преобразованию данных из одной формы в другую;

• накопители данных (data stores) – области (промежуточного) хранения данных (the holding areas for data);

• внешние сущности (external entities) – сущности, которые посылают данные в систему или получают данные из системы;

• потоки данных – маршруты, по которым данные могут двигаться.

3. Моделирование поведения сущностей (Entity Behavior Modeling) – процесс идентификации, моделирования и документирования событий, которые влияют на каждую сущность и последовательности, в которой эти события происходят.

Каждая их этих трех моделей системы обеспечивает различные точки зрения на одну и ту же систему, и каждая из точек зрения необходима для формирования полной модели проектируемой системы.

Все три методологии во взаимосвязи друг с другом (are cross-referenced against each other) дают гарантию полноты и точности всего приложения.

Проект разработки SSADM приложения делится на пять модулей, которые в дальнейшем разбиваются на иерархию из стадий, этапов и задач. Модули проекта приведены ниже.

1. Анализ осуществимости проектного решения (Feasibility Study) – анализ предметной области для определения сможет ли проектируемая система удовлетворить бизнес-требованиям.

2. Анализ требований (Requirements Analysis). На этом этапе определяются подлежащие разработке системные требования и моделируется текущая среда предприятия в терминах процессов с включением структур данных.

3. Спецификация требований (Requirements Specification). На этом этапе определяются детальные функциональные и нефункциональные требования и вводятся новые методики для определения необходимых процессов и структур данных.

4. Логическая системная спецификация (Logical System Specification). На этом этапе вырабатываются опции технической системы, логический проект обновлений, обработка запросов и системные диалоги.

5. Физический проект (Physical Design). На этапе физического проектирования создается физический проект базы данных и комплект программных спецификаций с использованием логической и технической системных спецификаций.

В отличие от RAD, который подразумевает параллельное выполнение этапов, SSADM строит каждый этап на основе работы, которая была предписана на предыдущем этапе без отклонений от модели.

Согласно стандарту при разработке автоматизированной системы выделяются следующие этапы:

Стадия 0. Оценивание реализуемости (необязательно).

- Определить рамки и составить план разработки.

- Определить первоначальный вариант требований.

- Выбрать вариант оценивания реализуемости.

- Оформить отчёт о возможности создания.

Стадия 1. Предпроектное исследование.

- Определить рамки предпроектного исследования.

- Определить основные требования.

- Изучить процессы обработки информации в существующей системе.

- Изучить данные, обрабатываемые в существующей системе.

- Разработать логическое описание существующей системы.