Тщательное проектирование важно не только для создания мостов и аэродромов. Конечно, даже при хорошем проекте вещь может быть плохо сделана, но, если плох проект, не спасет даже высокое качество изготовления.
Методы проектирования ПО
Проектирование ПО - дело еще более трудное, нежели проектирование вообще. В первую очередь это связано со сложностью и “неосязаемостью” ПО. Как правило, сначала разрабатывается абстрактная модель решения (архитектура или логический проект), а затем модель преобразуется в детальные проектные решения, которые могут быть использованы программистом как “калька”.
Четыре точки зрения на создаваемую ИС
Именно методология проектирования должна обеспечить необходимое множество преобразований от начальной модели к детальному описанию конечного решения. В методологии проектирования ПО можно выделить два главных компонента:
- изобразительные средства (как описать идеи проекта);
- методическая часть (что сделать, чтобы получить проект с использованием выбранных выразительных средств).
Большинство современных методов проектирования ПО служит в большей степени стратегическим руководством для проектировщиков, нежели дает детальные рекомендации.
Изобразительные средства нужны для того, чтобы:
- выразить идеи проектировщика;
- объяснить идеи проектировщика другим лицам (заказчику, подчиненным, начальнику);
- помочь в оценке решения, прежде всего его корректности, непротиворечивости и полноты.
Большинство специалистов придерживаются следующей классификации изобразительных средств:
- структурные (основное внимание концентрируется на статическом аспекте системы);
- поведенческие (описание причинно-следственных связей между событиями и откликами системы);
- функциональные (описание в терминах предметной области того, что делает система);
- средства моделирования данных (описывают информационные объекты, используемые в системе, и связи между ними).
Таким образом, существуют четыре различных взгляда (проекции) на создаваемую ИС. Каждому направлению соответствуют целое семейство изобразительных средств.
Структурная проекция. Используется для моделирования статических связей между объектами, идентифицируемыми в ходе анализа. На абстрактном (архитектурном) уровне эти объекты практически соответствуют объектам предметной области, независимо от принятой стратегии проектирования. Связи, соединяющие объекты, отражают потоки данных или зависимость от данных.
На уровне детального проектирования моделируемыми объектами обычно бывают программные модули. Могут быть связи типа “вызывает” или “использует”. Наиболее распространены различные виды диаграмм иерархий и зависимостей, а на уровне детального проектирования - структурные схемы ЙоданаКонстантайна.
Поведенческая проекция. Модели этого типа выражают связи между событиями и откликами на них и базируются на понятии конечного автомата. Наиболее распространенный инструмент - диаграммы переходов состояний (или диаграммы типа “состояния-переходы”). В этих диаграммах узлы соответствуют состояниям динамической системы, а дуга - переходу между состояниями. Дуга помечается именем входного сигнала или события, вызывающего этот переход, или, что тоже возможно, выходным сигналом или действием, сопровождающим переход.
Функциональная проекция. Одной из труднейших задач является точное описание действий системы. Наиболее распространенное средство - диаграммы потоков данных. Они описывают движение данных в моделируемой предметной области. Диаграмма строится из четырех базовых элементов: процессов, терминаторов, хранилищ и потоков данных.
Терминатор служит для отображения внешних по отношению к проектируемой системе объектов, являющихся источниками или потребителями информации (например, бухгалтерия, отдел кадров, справочники).
Процесс - логический узел обработки данных, преобразующий входные потоки данных в выходные. Его название обычно включает слово, обозначающее действие.
Поток, имеющий направление, показывает движение информации внутри организации, представляя таким образом данные в движении.
Хранилище представляет собой “склад” информационных объектов. В компьютерной системе обычно это база, или файл данных, или (при описании реального процесса) просто папка. Такие хранилища служат для корректного представления на диаграмме каких-либо асинхронных событий, предоставляя попавшим в нее данным как бы отсрочку, необходимую, например, для упорядочивания элементов. На диаграмме изображаются в виде прямоугольника с открытой стороной (или отрезков параллельных прямых).
Каждый поток данных и хранилище имеют некоторое содержимое, т. е. могут состоять из совокупности элементов и структур данных.
Для увеличения “прозрачности” диаграммы потоков данных строят многоуровневую структуру, верхний уровень которой является так называемой контекстной диаграммой. На ней ИС в целом представлена единым процессом, а также показано взаимодействие с внешними объектами.
Диаграммы следующего (нулевого) уровня представляют основные процессы и соответствующие потоки данных ИС. Все последующие уровни являют собой результаты декомпозиции процессов более высокого уровня, раскрывающие подробно структурное содержание того или иного процесса.
На уровне детального проекта диаграммы потоков данных необходимы для описания поведения программы во время ее выполнения.
Моделирование данных. Практически каждая информационная система манипулирует разнообразными, часто очень сложными, данными, работа с которыми невозможна без моделирования. Некоторые методологии основываются на модели данных типа “ядра” и сопутствующих технологий. Такой подход приемлем, если для предметной области характерны несложные процедуры обработки данных. Если функциональные требования сложны, методология основывается на двух базовых технологиях: моделировании процессов и моделировании данных.
Различают три главных типа моделей данных:
- концептуальная модель - идентифицирует сущности и их взаимосвязи, объединяя требования индивидуальных пользователей в общую модель организации;
- логическая модель - представляет собой концептуальную модель, трансформированную в структуру выбранной СУБД (иерархическую, сетевую, инвертированные списки, реляционную и т. д.);
- физическая модель - это логическая модель, отображенная на уровень физической реализации БД. На этом уровне объектами являются типы размещения данных, образцы трафика, требования индексирования, ограничения по безопасности и целостности.
Помимо них достаточно популярен ERподход (Entity-relationship - “сущность-связь”) - пожалуй, наиболее известная аналитическая техника моделирования данных. ER определяет два типа абстракций: сущности и связи. Начало этому направлению положила статья П. Чена, опубликованная в 1976 г. С тех пор ER-подход трансформировался в “графический язык” для описания требований пользователей посредством диаграмм (с различными вариантами - “школами” нотаций). Многие компании используют концептуальные модели данных в форме ER-диаграмм не только как средство проектирования систем, но и как базу для тренировки персонала и руководство для перестройки бизнес-процессов.
Структурная проекция для моделирования статических связей между объектами
Из многих методологий проектирования ПО можно выделить три основных класса.
Первый (самый обширный) - “структурный анализ” (SA - Structured Analysis). В его основе лежит простая идея использования наглядных графических средств в качестве основного средства спецификации ПО. Основные и самые распространенные из них - диаграммы потоков данных, модели “сущностьсвязь” и структурные схемы.
Второй класс - “информационная инженерия” (IE - Information Engineering). Этот термин не так давно ввел Дж. Мартин. При использовании IE следует помнить, что при создании информационных систем основное внимание надо уделять данным: их сбору и организации.
Мартин предложил целый ряд дополнительных по сравнению с SA методов и графических средств, весьма полезных при разработке ИС.
Поведенческая проекция отражает связи между событиями и откликами на них
Третий класс составляют методологии, основанные на концепции “объекта”.
Существует много нотаций графических средств. Например, диаграммы потоков данных наиболее часто применяются в нотации Gane/Sarson или Yourdon/DeMarco. ER-модели чаще всего реализуются в нотации Бахмана, Чена или стандарте IDEF1X. Структурные схемы - в нотации Yourdon/Constantine.
Что дает применение CASE-средств?
Обычно конкретное CASE-средство предполагает использование некоторой методологии. Например, IEF строго следует методологии Information Engineering. Однако чаще всего разработчики CASE-средств предлагают пользователям не одну, а целое семейство методологий (или гибридную методологию).
В некоторой степени это следствие нежелания фирм-изготовителей навязывать свой вкус пользователям, а также того, что в отдельных странах есть официально рекомендуемые правительством методологии, которых следует придерживаться при разработке ПО по заказу государственных организаций. Во Франции такой методологией является Merise, в Великобритании - SSADM (Structured System Analysis and Design Methods), в США - стандарт 2167А Министерства обороны.
CASE-средства используют заказчик и разработчик ИС. Каждому из них эти средства предоставляют новые и очень важные для него возможности и преимущества.
Основное назначение CASE - помочь разработчику в применении описанных в первой части выразительных средств при проектировании программных ИС. Это прежде всего средство проектирования и документирования проекта. Как правило, любое CASE-средство содержит несколько графических редакторов, каждый из которых обеспечивает возможность создания диаграмм одного вида, и общее хранилище-репозиторий. Репозиторий наряду с графическими объектами должен хранить и текстовую описательную информацию.
Применение CASE-технологии при создании ИС позволит не приступать к программированию без проекта, т. е. сделает процесс разработки более управляемым и “осязаемым”. Результаты труда отдельных проектировщиков не покинут фирму вместе с уволившимся сотрудником, они останутся доступными для общего пользования.
CASE-технология даст возможность еще на ранней стадии разработки убедиться в правильности избранного разработчиком пути и, более того, позволит участвовать в формировании этого пути, сделает разработку управляемым процессом.
Проектные материалы, подготовленные с помощью CASE, будут строгим и четким заданием программистам, они же окажутся бесценными материалами на этапе сопровождения.
К сожалению, нередко приходится сталкиваться с тем, что от CASE-средств ждут невозможного: нажать на кнопку и - получить готовую прикладную программу. Пока этого сделать нельзя, хотя и очень хотелось бы.
Итак, серьезные разработчики и серьезные заказчики должны использовать CASE-средства. Но какие? Об этом речь пойдет в следующей статье.
Олег Чикало
