2-software_engineering_design (Основы программной инженерии (по SWEBOOK)), страница 3

В результате, сформировалась точка зрения на архитектуру нетолько в приложении к конкретной программной системе, но и развился взгляд на архитектуру, как наприложение общих (generic) принципов организации программных компонент. В итоге, уже насегодняшний день, на фоне такого развития понимания архитектуры, накоплен целый комплексподходов и созданы (и продолжают создаваться и развиваться !) различные архитектурные“фреймворки”, то есть систематизированные комплексы методов, практик и инструментов,призванные в той или иной степени формализовать имеющийся в индустрии опыт (какположительный – например, design patterns, так и отрицательный – например, anti-patterns).Примеры такой систематизации в форме фреймворков: TOGAF [TOGAF81, 2003] – The Open Group Architecture Framework (на момент написанияданной главы доступен в версии 8.1, впервые опубликованной в декабре 2003 года) Модель Захмана – Zachman Framework [Zachman] Руководство по архитектуре электронного правительства E-Gov Enterprise ArchitectureGuidance [E-Gov, 2002]3.1 Архитектурные структуры и точки зрения (Architectural Structures and Viewpoints)Любая система может рассматриваться с разных точек зрения – например, поведенческой(динамической), структурной (статической), логической (удовлетворение функциональнымтребованиям), физической (распределенность), реализации (как детали архитектурыпредставляются в коде) и т.п.

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

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

Каждое архитектурное представление является результатом ответа на вопрос (Как?Что? Где? и т.п.) в контексте необходимого уровня абстракции (содержание, то есть концепция:бизнес-модель, то есть функциональность и т.д.). Например, физическая модель данных (PhysicalData Model) является ответом на вопрос “что?” в контексте технологической модели, а логическаяCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru7Основы программной инженерии (по SWEBOK)Программная инженерия. Проектирование программного обеспечения.модель данных, отвечая на тот же вопрос, находится на один уровень абстракции выше – вконтексте системной или логической модели.3.2 Архитектурные стили (Architectural Styles)В рассматриваемой редакции SWEBOK допущено несоответствие между структурой декомпозицииданной области знаний и описанием охватываемых ею тем.

Если архитектурные стили присутствуютв декомпозиции, в самом описании области знаний темы 3.1 и 3.2 смешаны (по форматированию иструктуре) в рамках темы “3.1”, (о чем автор сообщил ассоциированному редактору данной частиSWEBOK).Архитектурный стиль, по своей сути, шаблон проектирования макро-архитектуры - на уровнемодулей, "крупноблочного" взгляда. Например, архитектура распределенной сервисноориентированной системы может строится в стиле обмена сообщениями через соответствующиеочереди сообщений, может проектироваться на основе идеи взаимодействия между компонентами иприложениями через общую объектную шину, а может использовать концепцию брокера как единогоузла пересылки запросов.

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

Что это значит в реальной жизни? Если мыхотим организовать системы таким образом, чтобы существовал один и только один экземплярзаданного ее компонента в процессе работы с данной системой – мы можем использовать шаблонпроектирования “Singleton”, описывающий такое общее поведение.В то время, как архитектурный стиль определяет макро-архитектуру системы, шаблоныпроектирования задают микро-архитектуру, то есть определяют частные аспекты деталейархитектуры.Чаще всего говорят о следующих группах шаблонов проектирования: Шаблоны создания (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В SWEBOK данная тема, в силу упомянутого выше несоответствия между структурнойдекомпозицией и описанием области знаний “проектирование”, имеет номер 3.2 (следующая тема, всвою очередь, представлена в SWEBOK как 3.3).3.4 Семейства программ и фреймворков (Families of Programs and Frameworks)Один из возможных подходов к повторному использованию архитектурных решений и компонентзаключается в формировании линий продуктов (product lines) на основе общего дизайна.

В объектноориентированном программировании аналогичную смысловую нагрузку несут “фреймворки”,обеспечивающие решение одних и тех же задач – например, внутренней организации компонентовпользовательского интерфейса или общей логики работы распределенных систем.4. Анализ качества и оценка программного дизайна (Software Design Quality Analysis andEvaluation)4.1 Атрибуты качества (Quality Attributes)Существует целый спектр различных атрибутов, помогающих оценить и добиться качественногодизайна. Эти атрибуты могут описывать многие характеристики системы и элементов дизайна какCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru8Основы программной инженерии (по SWEBOK)Программная инженерия.

Проектирование программного обеспечения.такового – “тестируемость”, “переносимость”, “модифицируемость”, “производительность”,“безопасность” и т.п. Важно понимать, что обсуждаемые атрибуты касаются только дизайна (какрезультата), но не проектирования (как процесса). В принципе, все эти атрибуты можно разбить нанесколько групп: применимые к run-time, то есть ко времени выполнения системы; например, среднее времяотклика системы позволяющий оценить качество дизайна с точки зренияпроизводительности; ориентированные на design-time, то есть позволяющие оценивать качество получаемогодизайна еще на этапе проектирования или, в общем случае, вплоть до тестирования,включительно; например, средняя нагруженность классов бизнес-методами (предположимбизнес-методов в каждом классе в среднем 30 – интересно, насколько легко можноподдерживать, модифицировать и развивать систему с такой внутренней структурой....); атрибуты качества архитектурного дизайна как такового, например, концептуальнаяцелостность дизайна, непротиворечивость, полнота, завершенность; например, любойопределенный бизнес-метод является вызываемым, то есть создан не просто потому чтоможет понадобиться в будущем, а определен в соответствии с требованиями или необходимдля реализации дизайна в выбранном архитектурном стиле.Необходимо понимать, что существуют атрибуты, которые сложно измерить.

Например,портируемость или безопасность. Не стоит путать атрибуты качества дизайна с атрибутамикачества, фигурируемыми в ряду требований, предъявляемых к системе. Часть из них можетотображаться друг на друга и нести эквивалентную смысловую нагрузку, некоторые могут бытьсвязаны, большая часть атрибутов является специфичной именно для дизайна и не связана стребованиями. Например, если мы используем платформу J2EE (Java 2 Enterprise Edition) иориентируемся на использование компонентой модели EJB (Enterprise JavaBeans), существуютпризнаки хорошего дизайна, специфичные для данной платформы и компонентной модели, ноабсолютно никак не связанные с какими-либо требованиями к создаваемой на этой платформепрограммной системе.

Если вернуться к измеряемым атрибутам качества, они описываютсяопределенными метриками. Приведенный выше пример с количеством бизнес-методов на классявляется метрикой, относящейся к теме 4.3 “Измерения”. Эта же метрика позволяет оценитьатрибуты качества “модифицируемость” и “сложность” системы.4.2 Анализ качества и техники оценки (Quality Analysis and Evaluation Techniques)В индустрии распространены многие инструменты, техники и практики, помогающие добитьсякачественного дизайна: обзор дизайна (software design review); например, неформальный обзор архитектурычленами проектной команды; статический анализ (static analysis); например, трассировка с требованиями; симуляция и прототипирование (simulation and prototyping) – динамические техники проверкидизайна в целом или отдельных его атрибутов качества; например, для оценкипроизводительности используемых архитектурных решений при симуляции нагрузки,близкой к прогнозируемым пиковым;4.3 Измерения (Measures)Также известные как метрики.