Проектирование программного продукта

После определения всех требований, составления и утверждения техниче­ского задания можно переходить к следующему этапу — проектированию разработки программного продукта. На этом этапе набирается команда раз­работчиков и назначается менеджер проекта (project manager). Разработчики под руководством менеджера проекта, прежде всего, анализируют техниче­ское задание и формулируют записанные в нем требования к продукту на своем языке. Это может быть более детальное описание в терминах про­граммирования, запись на псевдокоде или на специальном языке описания интерфейсов. Затем они выбирают удобную для себя среду разработки, язык программирования, подыскивают или конструируют алгоритм решения за­дачи, подбирают структуры данных, способы хранения и представления данных. В результате возникает проект создания программного продукта, в котором отражается план необходимых для этого работ.

Редко удается сразу разработать полный и всеобъемлющий проект. Обычно разработка проходит несколько этапов, на которых проект уточняется и де­тализируется. Многие стандарты разработки различают эскизный проект, технический проект и рабочий проект. Но работа по созданию проекта на­чинается с анализа поставленной задачи.

Анализ

Классический метод анализа рассматривает создаваемый продукт как ин­формационную систему или систему управления. Слово "система" очень общее, ему трудно дать точное определение. Для анализа системы важно, что она состоит из нескольких относительно независимых подсистем. На­пример, информационная система факультета может состоять из подсисте­мы, обеспечивающей учебный процесс во главе с деканатом, подсистемы, обеспечивающей научную деятельность факультета во главе с ученым сове­том, подсистемы, обеспечивающей социальные нужды студентов и сотруд­ников.

Подсистема состоит из одного или нескольких модулей. Каждый модуль обеспечивает решение одной или нескольких задач, взаимодействуя при этом с другими модулями подсистемы. Например, подсистема учебного процесса факультета может состоять из модулей "деканат", "кафедра", "биб­лиотека", "компьютерный класс", "методическая комиссия".

В результате такого анализа выявляется структура системы, поэтому он но­сит название структурного анализа (structured analysis). Есть несколько де­сятков различных методик структурного анализа, приспособленных к ана­лизу систем разного типа. Наиболее широкое распространение получила методика SADT (Structured Analysis and Design Technique), разработанная в конце шестидесятых годов Дугласом Россом в Массачусетском технологиче­ском институте. В начале семидесятых годов она была с успехом применена в крупном аэрокосмическом проекте. Затем методика SADT использовалась в проектировании телефонных сетей, в системах автоматизированного про­ектирования (САПР), в разработке автоматизированных систем управления различными производственными процессами. Она до сих пор применяется для анализа самого широкого круга задач и реализации многих проектов.

Методика SADT была применена ВВС США для реализации программы компьютеризации промышленности, названной ICAM (Integrated Computer Aided Manufacturing). В ходе выполнения этой программы потребовалось разработать стандарт взаимодействия промышленных систем. Этот стандарт получил название IDEF (ICAM DEFinition). Оказалось, что он хорошо под­ходит для анализа и проектирования самых разных деловых и производст­венных процессов. Стандарт IDEF быстро развивался. На его основе появи­лись разновидности IDEFO, IDEF1, IDEF1X, IDEF3, IDEF4, IDEF5, ABC, приспособленные для решения специфических задач. Каждая разновид­ность стандарта IDEF уже выпушена в нескольких версиях

Результаты структурного анализа оформляются графически в виде несколь­ких диаграмм. Каждая методика предлагает свой набор диаграмм и свои правила их оформления, но почти во всех методиках есть диаграммы пото­ков данных DFD (Data Flow Diagrams), диаграммы переходов состояний STD (State Transition Diagrams), диаграммы сотрудничества ERD (Entity- Relationship Diagrams). Фирмы, вырабатывающие методики, предлагают и свои графические инструменты для их вычерчивания. Большое распростра­нение получили программные продукты ERWin, BPWin фирмы Com­puter Associates, Rational Rose фирмы Rational Software Corporation, серия программных продуктов SILVERRUN одноименной фирмы.

В последнее время все большее распространение получает объектно- ориентированный анализ (ООА, Object-Oriented Analysis), активно развивае­мый фирмой Rational Software Corporation. Этот метод анализа опирается на RUP (Rational Unified Process). Он начинает с составления всех возможных прецедентов (use cases) работы будущего программного продукта и создает аналитическую модель. Аналитическая модель, как следует из названия ме­тодики, определяет объекты, с которыми будут работать сценарии, входя­щие во все прецеденты. В число этих объектов, прежде всего, попадают сущности, которыми оперирует программа. Примерами сущностей могут служить списки сотрудников учреждения, его штатное расписание, банков­ские счета, каталог библиотеки и т. д. Действующие лица (actors) сценариев тоже становятся объектами. Кроме них, выделяются объекты, реализующие действия (actions), выполняемые действующими лицами, и объекты, связы­вающие действующие лица между собой.

Далее, объекты описываются классами. Выделяются классы сущностей, гра­ничные классы, описывающие взаимодействия различных объектов, управ­ляющие классы, описывающие объекты управления другими объектами. При этом сразу рисуются диаграммы классов, а также диаграммы взаимо­действий объектов. В объектно-ориентированном анализе выработано много разновидностей диаграмм, но наиболее часто создаются диаграммы коопе­рации объектов и диаграммы последовательностей.

Для облегчения и автоматизации анализа разработаны различные про­граммные продукты. Например, фирма Rational Software Corporation предла­гает средство анализа и проектирования Rational Rose. С его помощью можно быстро нарисовать нужные диаграммы и даже создать исходный текст программы на одном из наиболее распространенных языков програм­мирования.