Нотации проектирования. Структурные описания, статический взгляд. Поведенческие описания, динамический взгляд.
Нотация есть соглашение о представлении. Часто под нотацией подразумевают визуальное (графическое) представление. Нотация может задаваться:
- стандартом; например, 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” данной области знаний). Ниже мы будем рассматривать нотации, исходя из описания структурного (статического) или поведенческого (динамического) представления.
Структурные описания, статический взгляд (Structural Descriptions, static view)
Следующие нотации, в основном (но, не всегда), являются графическими, описывая и представляя структурные аспекты программного дизайна. Чаще всего они касаются основных компонент и связей между ними (статических связей, например, таких как отношения “один-ко-многим”).
- Языки описания архитектуры (Architecturedescriptionlanguage,ADL): текстовые языки, часто – формальные, используемые для описания программной архитектуры в терминах компонентов и коннекторов (специализированных компонентов, реализующих не функциональность, но обеспечивающих взаимосвязь функциональных компонентов между собой и с “внешним миром”);
- Диаграммы классов и объектов (Classandobjectdiagrams): используются для представления набора классов и <статических> связей между ними (например, наследования);
- Диаграммы компонентов или компонентные диаграммы (Componentdiagrams): в определенной степени аналогичны диаграммам классов, однако, в силу специфики концепции или понятия компонента*, обычно, представляются в другой визуальной форме; * здесь необходимо отметить различие в понятиях класса (или объекта) и компонента: компонент рассматривается как физически реализуемый элемент программного обеспечения, несущий <в определенной степени> самодостаточную логику и реализуемый как конгломерат интерфейса и его реализации (часто, в виде комплекса классов);
- Карточки <функциональной> ответственности и связей класса (Classresponsibilitycollaboratorcard,CRC): используются для обозначения имени класса, его ответственности (то есть, что он должен делать) и других сущностей (классов, компонентов, актёров/ролей и т.п.), с которыми он связан; часто их называют карточками “класс-обязанность-кооперация”;
- Диаграммы развёртывания (Deploymentdiagrams): используется для представления (физических) узлов, связей между ними и моделирования других физических аспектов системы;
- Диаграммы сущность-связь (Entity-relationshipdiagram,ERD илиER): используется для представления концептуальной модели данных, сохраняемых в процессе работы информационной системы;
- Языки описания/определения интерфейса (InterfaceDescriptionLanguages,IDL): языки, подобные языкам программирования, не включающие возможностей описания логики системы и предназначенные для определения интерфейсов программных компонентов (имён и типов экспортируемых или публикуемых операций);
- Структурные диаграммы Джексона (Jacksonstructurediagrams): используются для описания структур данных в терминах последовательности, выбора и итераций (повторений);
- Структурные схемы (Structurecharts): описываю структуру вызовов в программах (какой модуль вызывает, кем и как вызываем).
Дата добавления: 2018-05-12; просмотров: 384; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!