Introduction to Software Architecture and DesignContentsIntroduction to Software Architecture and Design 1 История развития Архитектуры Программного Обеспечения, Определения и Элементы 1 История 1 Определение 1 Составляющие элементы Архитектуры ПО 1 Key Architecture Principles 4 Инструменты моделирования архитектуры 4 Языки описания архитектуры 4 Представления(Views) 5 Архитектурные фреймфорки(каркасы) 5 Examples of Architectural Styles 5 Sources 6 История развития Архитектуры Программного Обеспечения, Определения и ЭлементыИстория Архитектура программного обеспечения как концепция была впервые определена в работе Дейкстры 1968 и Дэвидом Парнасом в начале 1970-х. Эти ученые делали ударение на том, что структура программного обеспечения играет важную роль и определение правильной структуры является критическим фактором в процессе разработки. Популярность исследований в этой области возросла в начале 1990х с появлением исследовательских работ связанных с архитектурными стилями(шаблонами-паттернами), языками описания архитектуры, документированием архитектуры и формальными методами. Исследовательские организации сыграли ведущую роль в развитии архитектуры программного обеспечения как дисциплины. Мэри Шоу и Дэвид Гарланд из института Карнеги Мелон написали книгу Архитектура Программного обеспечения: Перспективы новой дисциплины в 1996, которая выдвинула такие концепции в Архитектуре ПО как компоненты, коннекторы, стили, и т.д. Исследования, проводимые Калифорнийским Университетом, Институтом Ирвина по Исследованию Программного обеспечения направлены на разработку архитектурных стилей, языков описания архитектуры и динамической архитектруры. СтандартThe IEEE 1471: «ANSI/IEEE 1471-2000: Рекомендованная практика и архитектурное описание программных систем» является первым стандартом в области архитектуры ПО, в 2007 был адаптировн организацией стандартизации ISO как ISO/IEC 42010:2007. Определение “Архитектура — это фундаментальная организация системы, воплощенная в компонентах, их взаимосвязях, среде, и принципах, управляющих их дизайном и эволюцией.” [IEEE 1471] Составляющие элементы Архитектуры ПО Архитетура программной системы состоит из трех взаимодействующих элементов: 1) Структура – статическая составляющая, которая показывает распределение ответственности между подсистемамив, 2) Поведение – динамическая составляющая, взаимосвязи и взаимодействие междуэтими структурами, и 3) Стиль – принципы и руководства которыме использовались и будут использоваться при определении структуры. Структура Структурные элементы архитектуры охватывают статическиц набор подсистем и компонентов составляющих систему а также ответственности этих подсистем и их организыцию в более крупные подсистемы. Важно рассматривать также зависимости между компонентами и другими внешними системами. На этом уровне и с этой точки зрения организация архитектуры важна также для координирования работ и планировния проекта. Часто организация команды разработчиков проекта организуется согласно структуре — различные группы отвечают за реализацию разных подсистем. Постоянство в выбранной архитектуре проекта и «архитектуре» команды разработчиков", работающих над проектом позволяет эффективно управлять планированием и разработкой. Диаграмма показывает часть высокоуровневого представления структуры e-commerce приложения, которое обрабатывает кредитные карты. Фиксация архитектуры с этой точки зрения помогает определить контекст системы и определяет точку отсчета для принятия решений. Поведение Поведение определяет способы при помощи которых подсистемы и отдельные компоненты взаимодействуют друг с другом согласно системным требованиям. Диаграмма поведения показывает последовательность обмена "сообщениями" между компонентами гипотетической e-commerce системы. В этом сценарии мы наблюдаем за действиями компонентов системы такими как: компонент Shopping Cart принимает данные кредитной карты от Пользователя и использует Customer Management System для получения дополнительной информации из профиля пользователя. После получения этих данных, команда к оплате(payment instruction)перенаправляется в Шлюз кредитных карт(Card Gateway), который использует внешний обработчик платежей (Third Party Processor) для выполнения оплаты. После завершения платежной транзакции, компонент Shopping Cart заносит информацию о платеже в систему управления платежами (Payment Management System). Стиль Стиль определяет принципы и шаблоны (паттерны) применяемые для построения структуры и определения поведения архитектуры. Стиль может быть восприниматься как аналогия архитектурного стиля в строительстве зданий(Готический, Викторианский и т.д.) Стиль включает концепции (архитектурных паттернов напр.), технические решения и оценок (простота дизайна напр.). Стиль используется для определения словарей понятий, написания руководств, определения ограничений архитектуры, что используется в дальнейшем для эффективного принятия решений и упрощает понимание предмета при обсуждении архитектуры. Важно чтобы стиль был определен и представлен в документации явным образом, так как дальнейшая эволюция продукта зависит от понимания факторов, которые повлияли на существущую архитектуру. Определение архитектуры программного приложения это процесс определения структурированного решения, которое будет удовлетворять всем техническим и эксплуатационным требованиям, и, в то же время иметь оптимального по таким качественным характеристикам как производительность, безопасность, управляемость. Процесс определения архитектуры включает ряд шагов по принятию решений. Эти решения базируются на множестве влияющих факторов, и каждое из этих решений может иметь существенное влияние на качество, производительность, простоту дальнейшей поддержки в эксплуатации(maintainability), и общий успех приложения. Архитектура фокусируется на том как основные элементы и компоненты внутри приложения должны использоваться или взаимодействуют между собой. Выбор конкретных структур данных и вычислительных алгоритмов и реализыция индивидуальных компонентов относятся к вопросам дизайна программного обеспечения. Задачи рассматриваемые при выборе архитектуры и определения дизайна приложения часто перекрываются. Поэтому эти два процесса построения программного приложения не разделяются а комбинируются. В одних случаях требуется принимать архитектурные решения, в других решения касаются дизайна и определения того как можно реализовать выбранную архитектуру. Архитектура предоставляет решения для нефунциональных требований предъявляемых к приложению, в то время как дизайн отвечает за решения соответствующие функциональным требованиям проекта. ***** Согласно стандарту IEEE функциональные и нефункциональные требования определяются следующим образом: Функциональное требование — это требование к системе/программному приложению, которое должно выполняться соответствующим компонентом. Это требования, которые определяют поведение и действия системы, составляющие фундаментальный процесс или преобразования, которые программные и аппаратные компоненты системы производят над входными данными для получения выходных данных. Пример: «Система распечатывает инвойс» Нефункциональное требование — это требование к программному обеспечению, которое описывает не то что делает программа, но как программа выполняет функции. Например производительность ПО, требования к внешним интерфейсам, требования к качеству программного обеспечения. Част эти требования оцениваются субъективно из-за сложности их тестирования. Пример: «Система распечатывает инвойс быстро» ***** При определении архитектуры программного обеспечения должны рассматриваться следующие вопросы: Как пользователи будут использовать приложение? Как приложение будет внедряться (deployed) и управляться? Каким качественным требованиям должно удовлетворять приложение (безопасность, производительность, возможность распараллеливания, интернационализация, конфигурировация)? Каким образом должно быть спроектировано приложение чтобы оставться гибким и простым в поддержке с течением времени? Какие архитектурные направления могут повлиять на приложение сейчас или после внедрения? Key Architecture Principles Ключевые архитектурные принципы: Строить так чтобы затем изменять. Необходимо рассматривать как приложение может изменяться с течением времени чтобы удовлетворять новым требованиям и выбирать гибкую конструкцию, которая предоставит возможность изменения. Моделировать чтобы анализировать и уменьшить риск. Необходимо использовать средства проектирования, моделирования систем, такие как Unified Modeling Language (UML), и визуализации, которые помогут зафиксировать требования и решения архитектуры и дизайна приложения, и анализировать их влияние. Однако необходимо избегать чрезмерной формализации модели, чтобы не подавить способность итеративных адаптивных изменений. Использование моделей и визуализаций в качестве средства коммуникации и сотрудничества Эффективное обсуждение дизайна, принимаемых решений и предстоящих изменений дизайна критично для построения хорошей архитектуры. Используйте модели, представления и визуализации архитектуры для обсуждения и представления архитектуры для рассмотрения всем заинтересованным лицам, а также для возможности быстрого обсуждения изменений дизайна. Определение ключевых инженерных решений. Необходимо определить и понимать какие ключевые решения используются и области наиболее вероятного возникновения ошибок. Инвестируйте ресурсы в выбор правильных решений с самого начала чтобы выбранныйдизайн был наиболее гибким и риски связанные с изменениями минимальными. Рассмотрите итеративный подход к улучшению выбранной архитектуры. Начните с базовой архитектуры, чтобы определить общую картину, и затем, затем развивайте в процессе тестирования и внесения изменений. Не расчитывайте построить правильную архитектуру с первого раза — проектируйте пошагово и тестируйте чтобы определить архитектуру, соответствующую требованиям и предположениям. Добавляйте детали архитектуры итеративно, так чтобы главные решения были принять в первую очередь, затем внимание должно уделяться деталям. Общей ошибкой является слишком быстрое погружение в проектирование деталей, в то время как основные решения принимаются неверно из-за неверных предположений или неспособности эффективно оценить архитектуры. При тестировании архитектуры рассмотрите следующие вопросы: Какие предположения я сделал при выборе этой архитектуры? С каими явными или подразумевающимися требованиями столкнется эта архитектура? Какие основные риски связаны с выбранным архитектурным подходом? Какие контрмеры могут быть приняты для смягчения рисков? Чем эта выбранная архитектура лучше чем базовая архитектура или последняя принятая в качестве кандидата архитектура? Инструменты моделирования архитектуры Языки описания архитектуры Языки описания архитектуры Architecture description languages (ADLs) используются для описания Архитектуры ПО. Существует несколь различных ADLs, которые были разработаны различными организациями: AADL (SAE standard), Wright (developed by Carnegie Mellon), Acme(developed by Carnegie Mellon), xADL (developed by UCI), Darwin (developed by Imperial College London), DAOP-ADL (developed by University of Málaga). Общие элементы языков описания архитектуры это компонент, коннектор и конфигурация. Язык UML был признан стандартом для моделирования систем(не только программных) и таким образом применяется для представлений архитектуры ПО. Представления(Views) Архитектура ПО организована в виде представлений ( views), что является аналогом калек используемых в строительной архитектуре. Согласно определению ANSI/IEEE 1471-2000, представления являются экземплярами точек зрения??( viewpoints), где viewpoint используется для описания архитектуры с точки зрения перспективы определенных заинтересованных лиц. Примеры возможных представлений views (actually, viewpoints in the 1471 ontology): Функциональное /Логическое представление Представление модульное/кода Структурное представление Представвление Параллелизм/процессов/потоков Физическое/внедрения представление User action/feedback view Представление данных Архитектурные фреймфорки(каркасы) Фреймворки (каркасы) области архитектуры ПО: 4+1 RM-ODP (Reference Model of Open Distributed Processing) Service-Oriented Modeling Framework (SOMF) Other architectures such as the Zachman Framework, DODAF, and TOGAF relate to the field of Enterprise architecture. Examples of Architectural Styles There are many common ways of designing computer software modules and their communications, among them: Blackboard Client-server (2-tier, n-tier, peer-to-peer, Cloud Computing all use this model) Database-centric architecture (broad division can be made for programs which have database at its center and applications which don't have to rely on databases, E.g. desktop application programs, utility programs etc.) Distributed computing Event Driven Architecture Front-end and back-end Implicit invocation Monolithic application Peer-to-peer Pipes and filters Plugin Representational State Transfer Rule evaluation Search-oriented architecture (A pure SOA implements a service for every data access point) Service-oriented architecture Shared nothing architecture Software componentry (strictly module-based, usually object-oriented programming within modules, slightly less monolithic) Space based architecture Structured (module-based but usually monolithic within modules) Three-tier model (An architecture with Presentation, Business Logic and Database tiers)
