Структурные описания, статический взгляд (Structural Descriptions, static view)

Нотации проектирования (Software Design Notations)

Измерения (Measures)

Анализ качества и техники оценки (Quality Analysis and Evaluation Techniques)

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

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

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

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

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

• стандартом; например, 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): описываю структуру вызовов в программах (какой модуль вызывает, кем и как вызываем).

Дата добавления: 2014-10-22