Основы Программной Инженерии (по swebok) Введение Программная инженерия как дисциплина swebok руководство
 Скачать 3.21 Mb.
|
|
Достаточность, полнота и простота (Sufficiency, completeness and primitiviness) Этот подход подразумевает, что создаваемые программные компоненты обладают всеми необходимыми характеристиками, определенными абстракцией (моделью), но не более того. То есть не включают функциональность, отсутствующую в модели. Данный принцип особенно ярко выделен и явно представлен в виде рекомендуемых практик (best practices) методологий гибкого моделирования и экстремального программирования, где “все, что надо, но ни граммом больше” лежит в основе самой концепции “прагматичного” подхода (и на стадии моделирования, и в отношении реализации в коде). В оригинале этот принцип звучит как YAGNI – “You Aren’ t Going to Need It”, то есть “не делай этого, пока не понадобится”. Ключевые вопросы проектирования (Key Issues in Software Design) В какой-то мере, данную секцию стоило перевести как ключевые проблемы. Как проводить декомпозицию? Как организовать и объединить компоненты в единую систему? Как обеспечить необходимую производительность? Наконец, как обеспечить приемлемое качество системы? Все это – фундаментальные вопросы и проблемы проектирования, вне зависимости от используемых при проектировании подходов. Параллелизм (Concurrency) Эта тема охватывает вопросы, подходы и методы организации процессов, задач и потоков для обеспечения эффективности, атомарности, синхронизации и распределения (по времени) обработки информации. Контроль и обработка событий (Control and Handling of Events) В самом названии данной темы заложен комплекс обсуждаемых вопросов. В частности, данная тема касается и неявных методов обработки событий, часто реализуемых в виде функции обратного вызова (call- back), как одной из фундаментальных концепций обработки событий. Распределение компонентов (Distribution of Components) Распределение (и выполнение) по различным узлам обработки в терминах аппаратного обеспечения, сетевой инфраструктуры и т.п. Один из важнейших вопросов данной темы – использование связующего программного обеспечения (middleware 1 ) 1 часто middleware переводят как “промежуточное программное обеспечение”. Такой вариант перевода, к сожалению, рассматривает связующее ПО во второстепенной – “промежуточной” роли. Читатель, безусловно, может не согласиться с такой трактовкой, однако, многолетняя практика автора в обсуждении архитектурных вопросов с различными специалистами демонстрирует именно такой взгляд пользователей, не знакомых или не имеющих успешного опыта разработки и эксплуатации распределённых систем. Обработка ошибок и исключительных ситуаций и обеспечение отказоустойчивости (Errors and Exception Handling and Fault Tolerance) Вопрос темы, как ни странно, формулируется достаточно просто – как предотвратить сбои или, если сбой все же произошел, обеспечить дальнейшее функционирование системы. Взаимодействие и представление (Interaction and Presentation) Тема касается вопросов представления информации пользователям и взаимодействия пользователей с системой, с точки зрения реакции системы на действия пользователей. Речь в этой теме идет о реакции системы в ответ на действия пользователей и организации ее отклика с точки зрения внутренней организации взаимодействия, например, в рамках популярной концепции Model-View-Controller. Ни в коем случае не надо путать данную тему с вопросами организации пользовательского интерфейса, являющимеся частью “Эргономики программного обеспечения” – Software Ergonomics (см. “Связанные дисциплины”). Сохраняемость данных (Data Persistence) Именно сохраняемость, а не сохранность, так как тема касается не доступа к базам данных, как такового, а также не гарантий сохранности информации. Суть вопроса – как должны обрабатываться “долгоживущие” данные. Структура и архитектура программного обеспечения (Software Structure and Architecture) В строгом значении архитектура программного обеспечения (software architecture) – описание подсистем и компонент программной системы, а также связей между ними. Архитектура пытается определить внутреннюю структуру получаемой системы, задавая способ, которым система организована или конструируется. В середине 90-х, на волне распространения клиент- серверного подхода и начала его трансформации в “многозвенный клиент-сервер”, призванный обеспечить централизованное развертывание и управление общей (для клиентских приложений) бизнес-логикой, вопросы организации архитектуры программного обеспечения стали складываться в самостоятельную и достаточно обширную дисциплину. В результате, сформировалась точка зрения на архитектуру не только в приложении к конкретной программной системе, но и развился взгляд на архитектуру, как на приложение общих (generic) принципов организации программных компонент. В итоге, уже на сегодняшний день, на фоне такого развития понимания архитектуры, накоплен целый комплекс подходов и созданы (и продолжают создаваться и развиваться !) различные архитектурные “фреймворки”, то есть систематизированные комплексы методов, практик и инструментов, призванные в той или иной степени формализовать имеющийся в индустрии опыт (как положительный – например, design patterns, так и отрицательный – например, anti-patterns). Примеры такой систематизации в форме фреймворков: TOGAF [TOGAF81, 2003] – The Open Group Architecture Framework (на момент первичного написания данной главы доступен в версии 8.1, впервые опубликованной в декабре 2003 года; в 2009 году вышла версия TOGAF 9) Модель Захмана – Zachman Framework [Zachman] Руководство по архитектуре электронного правительства E-Gov Enterprise Architecture Guidance [E-Gov, 2002] Архитектурные структуры и точки зрения (Architectural Structures and Viewpoints) Любая система может рассматриваться с разных точек зрения – например, поведенческой (динамической), структурной (статической), логической (удовлетворение функциональным требованиям), физической (распределенность), реализации (как детали архитектуры представляются в коде) и т.п. В результате, мы получаем различные архитектурные представления (view). Архитектурное представление может быть определено, как частные аспекты программной архитектуры, рассматривающие специфические свойства программной системы. В свою очередь, дизайн системы – комплекс архитектурных представлений, достаточный для реализации системы и удовлетворения требований, предъявляемых к системе. SWEBOK не дает явного определения, что такое “архитектурная структура”. В то же время это понятие достаточно важно. Я хотел бы предложить его толкование как применение архитектурной точки зрения и представления к конкретной системе и описания тех деталей, которые необходимы для реализации системы, но отсутствуют (в силу достаточно общего взгляда) в используемом представлении. Таким образом, представление (view), концентрируясь на заданном подмножестве свойств является составной частью и/или результатом точки зрения, а архитектурная структура – дальнейшей детализацией в отношении проектируемой системы. Модель Захмана [Zachman] является великолепным и, кстати, классическим источником комплекса архитектурных точек зрения и представлений, построенных в системе координат “вопрос-уровень детализации”. Каждое архитектурное представление является результатом ответа на вопрос (Как? Что? Где? и т.п.) в контексте необходимого уровня абстракции (содержание, то есть концепция: бизнес-модель, то есть функциональность и т.д.). Например, физическая модель данных (Physical Data Model) является ответом на вопрос “что?” в контексте технологической модели, а логическая модель данных, отвечая на тот же вопрос, находится на один уровень абстракции выше – в контексте системной или логической модели. Архитектурные стили (Architectural Styles) В рассматриваемой редакции SWEBOK допущено несоответствие между структурой декомпозиции данной области знаний и описанием охватываемых ею тем. Если архитектурные стили присутствуют в декомпозиции, в самом описании области знаний темы 3.1 и 3.2 смешаны (по форматированию и структуре) в рамках темы “3.1”, (о чем сообщено ассоциированному редактору данной части SWEBOK). Архитектурный стиль, по своей сути, мета-модель или шаблон проектирования макро-архитектуры - на уровне модулей, “крупноблочного” взгляда. Например, архитектура распределенной сервисно-ориентированной системы может строится в стиле обмена сообщениями через соответствующие очереди сообщений, может проектироваться на основе идеи взаимодействия между компонентами и приложениями через общую объектную шину, а может использовать концепцию брокера как единого узла пересылки запросов. В то же время, на более концептуальном уровне, мы можем говорить о выборе клиент-серверного стиля или распределенного стиля архитектуры системы. Таким образом, архитектурный стиль – набор ограничений, определяющих семейство архитектур, которые удовлетворяют этим ограничениям. Шаблоны проектирования (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 В SWEBOK данная тема, в силу упомянутого выше несоответствия между структурной декомпозицией и описанием области знаний “проектирование”, имеет номер 3.2 (следующая тема, в свою очередь, представлена в SWEBOK как 3.3). Семейства программ и фреймворков (Families of Programs and Frameworks) Один из возможных подходов к повторному использованию архитектурных решений и компонент заключается в формировании линий продуктов (product lines) на основе общего дизайна. В объектно- ориентированном программировании аналогичную смысловую нагрузку несут “фреймворки”, обеспечивающие решение одних и тех же задач – например, внутренней организации компонентов пользовательского интерфейса или общей логики работы распределенных систем. Анализ качества и оценка программного дизайна (Software Design Quality Analysis and Evaluation) Атрибуты качества (Quality Attributes) Существует целый спектр различных атрибутов, помогающих оценить и добиться качественного дизайна. Эти атрибуты могут описывать многие характеристики системы и элементов дизайна как такового – “тестируемость”, “переносимость”, “модифицируемость”, “производительность”, “безопасность” и т.п. Важно понимать, что обсуждаемые атрибуты касаются только дизайна (как результата), но не проектирования (как процесса). В принципе, все эти атрибуты можно разбить на несколько групп: применимые к run-time, то есть ко времени выполнения системы; например, среднее время отклика системы позволяющий оценить качество дизайна с точки зрения производительности; ориентированные на design-time, то есть позволяющие оценивать качество получаемого дизайна еще на этапе проектирования или, в общем случае, вплоть до тестирования, включительно; например, средняя нагруженность классов бизнес- методами (предположим бизнес-методов в каждом классе в среднем 30 – интересно, насколько легко можно поддерживать, модифицировать и развивать систему с такой внутренней структурой….); атрибуты качества архитектурного дизайна как такового, например, концептуальная целостность дизайна, непротиворечивость, полнота, завершенность; например, любой определенный бизнес-метод является вызываемым, то есть создан не просто потому что может понадобиться в будущем, а определен в соответствии с требованиями или необходим для реализации дизайна в выбранном архитектурном стиле. Необходимо понимать, что существуют атрибуты, которые сложно измерить. Например, портируемость или безопасность. Не стоит путать атрибуты качества дизайна с атрибутами качества, фигурируемыми в ряду требований, предъявляемых к системе. Часть из них может отображаться друг на друга и нести эквивалентную смысловую нагрузку, некоторые могут быть связаны, большая часть атрибутов является специфичной именно для дизайна и не связана с требованиями. Например, если мы используем платформу J2EE (Java 2 Enterprise Edition) и ориентируемся на использование компонентой модели EJB (Enterprise JavaBeans), существуют признаки хорошего дизайна, специфичные для данной платформы и компонентной модели, но абсолютно никак не связанные с какими-либо требованиями к создаваемой на этой платформе программной системе. Если вернуться к измеряемым атрибутам качества, они описываются определенными метриками. Приведенный выше пример с количеством бизнес-методов на класс является метрикой, относящейся к теме 4.3 “Измерения”. Эта же метрика позволяет оценить атрибуты качества “модифицируемость” и “сложность” системы. Анализ качества и техники оценки (Quality Analysis and Evaluation Techniques) В индустрии распространены многие инструменты, техники и практики, помогающие добиться качественного дизайна: обзор дизайна (software design review); например, неформальный обзор архитектуры членами проектной команды; статический анализ (static analysis); например, трассировка с требованиями; симуляция и прототипирование (simulation and prototyping) – динамические техники проверки дизайна в целом или отдельных его атрибутов качества; например, для оценки производительности используемых архитектурных решений при симуляции нагрузки, близкой к прогнозируемым пиковым; Измерения (Measures) Также известные как метрики. Могут быть использованы для количественной оценки ожиданий в отношении различных аспектов конкретного дизайна, например, размера <проекта>, структуры (ее сложности) или качества (например, в контексте требований, предъявляемых к производительности). Чаще всего, все метрики разделяют по двум категориям: функционально-ориентированные объектно-ориентированные Нотации проектирования (Software Design Notations) Нотация есть соглашение о представлении. Часто под нотацией подразумевают визуальное (графическое) представление. Нотация может задаваться: стандартом; например, 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) Следующие нотации, в основном (но, не всегда), являются графическими, описывая и представляя структурные аспекты программного дизайна. Чаще всего они касаются основных компонент и связей между ними (статических связей, например, таких как отношения “один-ко-многим”). Языки описания архитектуры (Architecture description language, ADL): текстовые языки, часто – формальные, используемые для описания программной архитектуры в терминах компонентов и коннекторов (специализированных компонентов, реализующих не функциональность, но обеспечивающих взаимосвязь функциональных компонентов между собой и с “внешним миром”); Диаграммы классов и объектов (Class and object diagrams): используются для представления набора классов и <статических> связей между ними (например, наследования); Диаграммы компонентов или компонентные диаграммы (Component diagrams): в определенной степени аналогичны диаграммам классов, однако, в силу специфики концепции или понятия компонента 2 , обычно, представляются в другой визуальной форме; 2 здесь необходимо отметить различие в понятиях класса (или объекта) и компонента: компонент рассматривается как физически реализуемый элемент программного обеспечения, несущий <в определенной степени> самодостаточную логику и реализуемый как конгломерат интерфейса и его реализации (часто, в виде комплекса классов); Карточки <функциональной> ответственности и связей класса (Class responsibility collaborator card, CRC): используются для обозначения имени класса, его ответственности (то есть, что он должен делать) и других сущностей (классов, компонентов, актёров/ ролей и т.п.), с которыми он связан; часто их называют карточками “класс-обязанность- кооперация”; Диаграммы развёртывания (Deployment diagrams): используется для представления (физических) узлов, связей между ними и моделирования других физических аспектов системы; Диаграммы сущность-связь (Entity-relationship diagram, ERD или ER): используется для представления концептуальной модели данных, сохраняемых в процессе работы информационной системы; Языки описания/определения интерфейса (Interface Description Languages, IDL): языки, подобные языкам программирования, не включающие возможностей описания логики системы и предназначенные для определения интерфейсов программных компонентов (имён и типов экспортируемых или публикуемых операций); Структурные диаграммы Джексона (Jackson structure diagrams): используются для описания структур данных в терминах последовательности, выбора и итераций (повторений); Структурные схемы (Structure charts): описываю структуру вызовов в программах (какой модуль вызывает, кем и как вызываем). |