Проектирование программного обеспечения

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

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

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

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

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

Семейства программ и фреймворков

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

1.4 Анализ качества и оценка программного дизайна

Атрибуты качества

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

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

• применимые к run-time, то есть ко времени выполнения системы; например, среднее время отклика системы позволяющий оценить качество дизайна с точки зрения производительности;

• ориентированные на design-time, то есть позволяющие оценивать качество получаемого дизайна еще на этапе проектирования или, в общем случае, вплоть до тестирования, включительно; например, средняя нагруженность классов бизнес-методами (предположим бизнес-методов в каждом классе в среднем 30 – интересно, насколько легко можно поддерживать, модифицировать и развивать систему с такой внутренней структурой....);

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

 

Анализ качества и техники оценки

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

• обзор дизайна (software design review); например, неформальный обзор архитектуры членами проектной команды;

• статический анализ (static analysis); например, трассировка с требованиями;

• симуляция и прототипирование (simulation and prototyping) – динамические техники проверки дизайна в целом или отдельных его атрибутов качества; например, для оценки производительности используемых архитектурных решений при симуляции нагрузки, близкой к прогнозируемым пиковым;

 

Измерения

Также известные как метрики. Могут быть использованы для количественной оценки ожиданий в отношении различных аспектов конкретного дизайна, например, размера <проекта>, структуры (ее сложности) или качества (например, в контексте требований, предъявляемых к производительности).

Чаще всего, все метрики разделяют по двум категориям:

• функционально-ориентированные

• объектно-ориентированные

 

 

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

 Нотация есть соглашение о представлении. Часто под нотацией подразумевают визуальное

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

• стандартом; например, OMG UML – Unified Modeling Language, развиваемый консорциумом

OMG (Object Management Group, http://www.omg.org);

• общепринятой практикой; например, в eXtreme Programming часто используются карточки

функциональной ответственности и связей класса - Class Responsibility Collaborator или CRC

Card (CRC по свое природе является текстовой, то есть невизуальной нотацией);

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

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

Кроме того, нотации чаще всего используют в контексте (выбор нотации может быть обусловлен таким контекстом) применяемой методологии или подхода (см. 6 “Software Design Strategies and Methods” данной области знаний). Ниже мы будем рассматривать нотации, исходя из описания структурного (статического) или поведенческого (динамического) представления.

 

Структурные описания, статический взгляд

Следующие нотации, в основном (но, не всегда), являются графическими, описывая и представляя структурные аспекты программного дизайна. Чаще всего они касаются основных компонент и связей между ними (статических связей, например, таких как отношения “один-ко-многим”).

• Языки описания архитектуры (Architecture description language, ADL): текстовые языки, часто – формальные, используемые для описания программной архитектуры в терминах компонентов и коннекторов (специализированных компонентов, реализующих не функциональность, но обеспечивающих взаимосвязь функциональных компонентов между собой и с “внешним миром”);

• Диаграммы классов и объектов (Class and object diagrams): используются для представления набора классов и <статических> связей между ними (например, наследования);

• Диаграммы компонентов или компонентные диаграммы (Component diagrams): в определенной степени аналогичны диаграммам классов, однако, в силу специфики концепции или понятия компонента*, обычно, представляются в другой визуальной форме; здесь необходимо отметить различие в понятиях класса (или объекта) и компонента: компонент рассматривается как физически реализуемый элемент программного обеспечения, несущий <в определенной степени> самодостаточную логику и реализуемый как конгломерат интерфейса и его реализации (часто, в виде комплекса классов);

• Карточки <функциональной> ответственности и связей класса (Class responsibility collaborator card, CRC): используются для обозначения имени класса, его ответственности (то есть, что он должен делать) и других сущностей (классов, компонентов, актёров/ролей и т.п.), с которыми он связан; часто их называют карточками “класс-обязанность-кооперация”;

• Диаграммы развёртывания (Deployment diagrams): используется для представления (физических) узлов, связей между ними и моделирования других физических аспектов системы;

• Диаграммы сущность-связь (Entity-relationship diagram, ERD или ER): используется для представления концептуальной модели данных, сохраняемых в процессе работы информационной системы;

• Языки описания/определения интерфейса (Interface Description Languages, IDL): языки, подобные языкам программирования, не включающие возможностей описания логики системы и предназначенные для определения интерфейсов программных компонентов (имён и типов экспортируемых или публикуемых операций);

• Структурные диаграммы Джексона (Jackson structure diagrams): используются для описания структур данных в терминах последовательности, выбора и итераций (повторений);

• Структурные схемы (Structure charts): описываю структуру вызовов в программах (какой модуль вызывает, кем и как вызываем).

 

Поведенческие описания, динамический взгляд

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

 

 

 

• Диаграммы деятельности или операций (Activity diagrams): используются для описания потоков работ и управления;

• Диаграммы сотрудничества (Collaboration diagrams): показывают динамическое взаимодействие, происходящее в группе объектов и уделяют особое внимание объектам, связям между ними и сообщениям, которыми обмениваются объекты посредством этих связей;

• Диаграммы потоков данных (Data flow diagrams, DFD): описывают потоки данных внутри набора процессов (не в терминах процессов операционной среды, но в понимании обмена информацией в бизнес-контексте);

• Таблицы и диаграммы <принятия> решений (Decision tables and diagrams): используются для представления сложных комбинаций условий и действий (операций);

• Блок-схемы и структурированные блок-схемы (Flowcharts and structured flowcharts): применяются для представления потоков управления (контроля) и связанных операций;

• Диаграммы последовательности (Sequence diagrams): используются для показа взаимодействий внутри группы объектов с акцентом на временной последовательности сообщений/вызовов;

• Диаграммы перехода и карты состояний(State transition and statechart diagrams): применяются для описания потоков управления переходами между состояниями;

• Формальные языки спецификации (Formal specification languages): текстовые языки, использующие основные понятия из математики (например, множества) для строгого и абстрактного определения интерфейсов и поведения программных компонентов, часто в терминах пред- и пост-условий;

• Псевдокод и программные языки проектирования (Pseudocode and program design anguages, PDL): языки, используемые для описания поведения процедур и методов, в основном на стадии детального проектирования; подобны структурным языкам программирования.

 

 

1.6 Стратегии и методы проектирования программного обеспечения

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

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

 

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

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

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

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

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

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

• и другие...

 Функционально-ориентированное или структурное проектирование

Это один из классических методов проектирования, в котором декомпозиция сфокусирована на идентификации основных программных функций и, затем, детальной разработке и уточнении этих функций “сверху-вниз”. Структурное проектирование, обычно, используется после проведения структурного анализа с применением диаграмм потоков данных и связанным описанием процессов. Исследователи предлагают различные стратегии и метафоры или подходы для трансформации DFD в программную архитектуру, представляемую в форме структурных схем. Например, сравнивая управление и поведение с получаемым эффектом.

 

Объектно-ориентированное проектирование

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

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

Хотя корни объектно-ориентированного проектирования лежат в абстракции данных (к которым добавлены поведенческие характеристики), так называемый responsibility-driven design или проектирование на основе <функциональной> ответственности по SWEBOK может рассматриваться как альтернатива объектно-ориентированному проектированию.

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

Проектирование на основе структур данных

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

Компонентное проектирование

Программные компоненты являются независимыми единицами, которые обладают однозначно-определенными (well-defined) интерфейсами и зависимостями (связями) и могут собираться и развертываться независимо друг от друга. Данный подход призван решить задачи использования, разработки и интеграции таких компонент с целью повышения повторного использования активов (как архитектурных, так и в форме кода). Компонентно-ориентированное проектирование является одной из наиболее динамично развивающихся концепций проектирования и может рассматриваться как предвестник и основа сервисно-ориентированного подхода (Service-Oriented Architecture, SOA) в проектировании, не рассматриваемого, к сожалению, в SWEBOK, но все более активно использующегося в индустрии и смещающего акценты с аспектов организации связи интерфейс-реализация к обмену информацией на уровне интерфейс-интерфейс (то есть – межкомпонентному взаимодействию). По мнению автора книги, уже наступил тот момент, когда необходимо вводить отдельную тему, посвященную сервисно-ориентированному подходу в проектировании и сервисно-ориентированным архитектурам, как моделям. В частности, нотация UML 2.0 уже позволяет решать ряд вопросов, связанных с визуальным представлением соответствующих архитектурных решений, где сервисы (службы) могут рассматриваться как публикуемая функциональность одиночных компонентов и групп компонентов,объединенных в более “крупные” блоки, обеспечивающие предоставление соответствующей сервисной функциональности.