Лекция 7. Основные рабочие процессы: проектирование архитектуры, детальное проектирование

Процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или ее компонентов называется проектированием.

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

Проектирование играет важную роль в процессах жизненного цикла создания программного обеспечения (Software Development Life Cycle), например, IEEE и ISO/IEC (ГОСТ Р ИСО МЭК 12207). Проектирование программных систем можно рассматривать как деятельность, результат которой состоит из двух составных частей:

Архитектурный или высокоуровневый дизайн (software architectural design, top-level design) – описание высокоуровневой структуры и организации компонентов системы;

Детализированная архитектура (software detailed design) – описывающая каждый компонент в том объеме, который необходим для конструирования.

Архитектурное проектирование – декомпозиция структуры (статической) и организации (динамической) компонент;

Детализация архитектуры – описывает специфическое поведение и характеристики отдельных компонент.

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

Техники применения (Enabling Techniques)

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

1. Абстракция (Abstraction)

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

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

2 Связанность и соединение (Coupling and Cohesion)

Связанность (Coupling) – определяет силу связи (часто, взаимного влияния) между модулями. Соединение (Cohesion) – определяет как тот или иной элемент обеспечивает связь внутри модуля, внутреннюю связь.

Значение оригинальных терминов очень близко и, в зависимости от контекста, “связанность” и “соединение” могут рассматриваться как степень самодостаточности или ее отсутствия (coupling) и функциональная зависимость (cohesion), соответственно.

3 Декомпозиция и разбиение на модули (Decomposition and Modularization)

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

4 Инкапсуляция/сокрытие информации (Encapsulation/information hiding).

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

5 Разделение интерфейса и реализации (Separation of interface and implementation)

Данная техника предполагает определение компонента через специфицирование интерфейса, известного (описанного) и доступного клиентам (или другим компонентам), от непосредственных деталей реализации.

6 Достаточность, полнота и простота (Sufficiency, completeness and primitiviness)

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

Данный принцип особенно ярко выделен и явно представлен в виде рекомендуемых практик (best practices) методологий гибкого моделирования и экстремального программирования, где “все, что надо, но ни граммом больше” лежит в основе самой концепции “прагматичного” подхода (и на стадии моделирования, и в отношении реализации в коде). В оригинале этот принцип звучит как YAGNI – “You Aren’ t Going to Need It”, то есть “не делай этого, пока не понадобится”.

Структура и архитектура программного обеспечения (Software Structure and Architecture)

В строгом значении архитектура программного обеспечения (software architecture) – описание подсистем и компонент программной системы, а также связей между ними. Архитектура пытается определить внутреннюю структуру получаемой системы, задавая способ, которым система организована или конструируется.

В середине 90-х, на волне распространения клиент-серверного подхода и начала его трансформации в “многозвенный клиент-сервер”, призванный обеспечить централизованное развертывание и управление общей (для клиентских приложений) бизнес-логикой, вопросы организации архитектуры программного обеспечения стали складываться в самостоятельную и достаточно обширную дисциплину. В результате, сформировалась точка зрения на архитектуру не только в приложении к конкретной программной системе, но и развился взгляд на архитектуру, как на приложение общих (generic) принципов организации программных компонент. В итоге, уже на сегодняшний день, на фоне такого развития понимания архитектуры, накоплен целый комплекс подходов и созданы (и продолжают создаваться и развиваться) различные архитектурные “фреймворки”, то есть систематизированные комплексы методов, практик и инструментов, призванные в той или иной степени формализовать имеющийся в индустрии опыт (как положительный – например, design patterns, так и отрицательный – например, anti-patterns).

Одним из примеров такой систематизации в форме фреймворков является модель Захмана. В ней была предложена простая, но концептуально мощная схема, показывающая различные уровни представления архитектуры ИС, различные виды ее "обеспечения", а также их основные взаимосвязи.

Шесть строк таблицы отражают шесть уровней представления системы:

· реальная бизнес-среда;

· концептуальная модель;

· логическая модель;

· технологическая (физическая) модель;

· детальная реализация (часто - поблочная и выполняемая субподрядчиком);

· представление пользователя.

Будем называть проекцией отображение взгляда на систему с некоторой точки зрения, а полной проекцией — исчерпывающее описание определенного взгляда на систему. Описание архитектуры является совокупностью отдельных проекций, которая образует архитектурную модель, с той или иной степенью полноты описывающую систему. Любую систему можно полностью описать с помощью некоего конечного числа полных проекций. Совокупность проекций, полностью и исчерпывающе описывающих систему, назовем полной архитектурной моделью («полностью» в данном случае означает, что любую другую проекцию удастся построить на основе данной архитектурной модели). Архитектурная (в широком смысле слова) наука предлагает нам полную модель Захмана (Известные архитектурные модели (строго говоря, нотации описания архитектурных моделей) легко укладываются в эту модель. В свете введенных нами определений строки и столбцы модели Захмана являются проекциями: строки — с точки зрения групп заинтересованных лиц, столбцы — с точки зрения областей рассмотрения (что, кто, как, когда, где и зачем).

Архитектурные структуры и точки зрения (Architectural Structures and Viewpoints)

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

В настоящее время не существует явного определения, что такое “архитектурная структура”. В то же время это понятие достаточно важно. Можно предложить его толкование как применение архитектурной точки зрения и представления к конкретной системе и описания тех деталей, которые необходимы для реализации системы, но отсутствуют (в силу достаточно общего взгляда) в используемом представлении. Таким образом, представление (view), концентрируясь на заданном подмножестве свойств является составной частью и/или результатом точки зрения, а архитектурная структура – дальнейшей детализацией в отношении проектируемой системы.

Модель Захмана [Zachman] является великолепным и классическим источником комплекса архитектурных точек зрения и представлений, построенных в системе координат “вопрос-уровень детализации”. Каждое архитектурное представление является результатом ответа на вопрос (Как? Что? Где? и т.п.) в контексте необходимого уровня абстракции (содержание, то есть концепция: бизнес-модель, то есть функциональность и т.д.). Например, физическая модель данных (Physical Data Model) является ответом на вопрос “что?” в контексте технологической модели, а логическая модель данных, отвечая на тот же вопрос, находится на один уровень абстракции выше – в контексте системной или логической модели.

Архитектурные стили (Architectural Styles). Архитектурный стиль, по своей сути, мета-модель или шаблон проектирования макро-архитектуры - на уровне модулей, "крупноблочного" взгляда. Например, архитектура распределенной сервисно-ориентированной системы может строиться в стиле обмена сообщениями через соответствующие очереди сообщений, может проектироваться на основе идеи взаимодействия между компонентами и приложениями через общую объектную шину, а может использовать концепцию брокера как единого узла пересылки запросов. В то же время, на более концептуальном уровне, мы можем говорить о выборе клиент-серверного стиля или распределенного стиля архитектуры системы. Таким образом, архитектурный стиль – набор ограничений, определяющих семейство архитектур, которые удовлетворяют этим ограничениям.

Шаблоны проектирования (Design Patterns). Наиболее краткая формулировка того, что такое шаблон проектирования, может звучать так – “общее решение общей проблемы в заданном контексте”. Что это значит в реальной жизни? Если мы хотим организовать системы таким образом, чтобы существовал один и только один экземпляр заданного ее компонента в процессе работы с данной системой – мы можем использовать шаблон проектирования “Singleton”, описывающий такое общее поведение.

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

Чаще всего говорят о следующих группах шаблонов проектирования:

Шаблоны создания (Creational patterns) - builder, factory, prototype, singleton

Структурные шаблоны (Structural patterns) - adapter, bridge, composite, decorator, facade, flyweight, proxy

Шаблоны поведения (Behavioral patterns) - command, interpreter, iterator, mediator, memento, observer, state, strategy, template, visitor

Семейства программ и фреймворков (Families of Programs and Frameworks). Один из возможных подходов к повторному использованию архитектурных решений и компонент заключается в формировании линий продуктов (product lines) на основе общего дизайна. В объектно-ориентированном программировании аналогичную смысловую нагрузку несут “фреймворки”, обеспечивающие решение одних и тех же задач – например, внутренней организации компонентов пользовательского интерфейса или общей логики работы распределенных систем.

Нотации проектирования

Нотация есть соглашение о представлении. Часто под нотацией подразумевают визуальное (графическое) представление. Нотация может задаваться:

стандартом; например, OMG UML – Unified Modeling Language, развиваемый консорциумом OMG (Object Management Group, http://www.omg.org);

общепринятой практикой; например, в eXtreme Programming часто используются карточки функциональной ответственности и связей класса - Class Responsibility Collaborator или CRC Card (CRC по свое природе является текстовой, то есть невизуальной нотацией);

внутренним методом проектной команды (“будем рисовать и обозначать так...”).

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

Общие стратегии

Это обычно часто упоминаемые и общепринятые стратегии:

- “разделяй-и-властвуй” и пошаговое уточнение

- проектирование “сверху-вниз” и “снизу-вверх”

- абстракция данных и сокрытие информации

- итеративный и инкрементальный подход

- и другие...