Методы объектного анализа и построения моделей предметных областей

4.2. Методы проектирования архитектуры ПО

Проектирование ПО - это процесс разработки, следующий за этапом анализа и формирования требований. Задача проектирования - это преобразование требований к системе в требования к ПО и построение архитектуры системы [4.16].

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

Основное условие построения архитектуры системы - это декомпозиция системы на компоненты или модули, а также

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

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

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

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

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

К методам проектирования относятся стандартный подход к проектированию, основанный на сформировавшейся общесистемной технологии традиционного проектирования программных систем.

4.2.1. Стандартный подход к проектированию

Разработка автоматизированных систем (АС) выполнялась на основе стандарта ГОСТ 34.601-90, регламентирующего стадии и этапы процесса разработки АС с учетом особенностей АС и средств объединения подсистем. Основание для разработки АС - это договор между разработчиком системы и заказчиком.

Этапами данного стандарта являются: формирование требований, разработка концепции системы, проектирование эскизного, технического и рабочего проекта. В эскизном и техническом проекте на основе сформулированных требований и концепций определяются конкретные задачи системы, строится структура системы, а также определяются пути и алгоритмы реализации подсистем. Эти этапы заканчивается созданием и утверждением отчета о научно-исследовательской работе, в котором дается оценка необходимых для реализации АС ресурсов, вариантов и порядка проведения оценки качества системы.

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

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

Проектные решения определяют организационную структуру, функции персонала АС, набор необходимых технических средств, языка и системы программирования, типы СУБД, систему классификации и кодирования, справочники, а также варианты ведения информационной базы системы.

Данный стандарт обеспечивает:

• концептуальное проектирование,которое состоит в построении концептуальной модели, уточнении и согласовании требований;
• архитектурное проектирование,которое состоит в определении главных структурных особенностей создаваемой системы;
• техническое проектирование - это отображение требований определение задач и принципов их реализации в среде функционирования системы;
• детальное рабочее проектирование,которое состоит в спецификации алгоритмов задач, построении БД и программного обеспечения системы.

Рассмотрим каждый вид проектирования более подробно.

При концептуальном проектировании определяются:

• источники поступления данных от заказчика, который несет ответственность за их достоверность;
• объекты системы и их атрибуты;
• способы материализации связей между объектами и виды организации данных.
• интерфейсы с потенциальными пользователями системы для оказания им помощи при формулировке целей и функций системы;
• методы взаимодействия пользователей с системой для обеспечения скорости реакции системы.

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

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

При архитектурном проектировании системы может применяться язык UML, который позволяет учитывать аспекты, свойственные действующим лицам, а также устанавливать форматы в меню и иконах интерфейсов [4.17].

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

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

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

Для уточнения поведения объектов используются диаграммы UML, отображающие различные аспекты взаимодействия объектов. Эти уточнения касаются интерфейсов и поведения объектов в сценариях, а также пересмотра моделей требований и состава объектов системы. Изменения начинаются с требований и поиска мест локации для внесения необходимых изменений в модель требований и их трассирование. Наряду с изменением требований к функциям системы могут изменяться нефункциональные требования, касающиеся ограничений на структуру системы и условий среды функционирования системы (отказоустойчивость и др.).

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