· Правильное формирование архитектуры ПО позволяет с самого начала управлять производительностью программной системы. Рассмотрим ситуацию, в которой требуется обслуживание кода во всем объеме программной системы. Если проект был случайным и плохо спланированным, один и тот же код придется повторять снова и снова, что даст в итоге непредсказуемую производительность. Напротив, программная система с хорошей архитектурой, в которой обслуживание производится через один компонент, обеспечивает более предсказуемую производительность.
· Благодаря правильной архитектуре можно достичь большей степени повторного использования. Рассмотрим линейку продуктов, для которых требуются одни и те же базовые операции сопровождения с небольшими вариациями. Если применять многоуровневый подход, задача сводится к замене только самых верхних уровней. Без распределения по уровням придется вносить обширные изменения во множество продуктов.
· Непродуманные ограничения могут препятствовать развитию ПО. Например, требование, чтобы система была монолитной, нераспределенной, поскольку распределенные программные системы труднее формировать, затруднит возможный переход к распределенной архитектуре.
· Рано или поздно понадобится приспособить программное обеспечение к большему количеству пользователей и обработке больших объемов данных, введению новых функций, использованию новых технологий и т.д. Невозможность на раннем этапе понять и предсказать, как можно будет изменить программное обеспечение для этих целей, может привести к ситуации, когда программную систему придется переписывать заново, поскольку изначальная архитектура не учитывала аспектов развития и универсальности. Доступность и надежность программной системы в значительной степени зависят от универсальности.
· Наличие документированной архитектуры позволяет легче понять назначение и сущность программной системы и передать эту информацию группе разработки.
· Внутренне присущая программной системе безопасность, способность к тестированию, удобство сопровождения и общая управляемость программного обеспечения также в большой степени зависят от архитектуры программной системы.
В этом разделе рассматривается ряд понятий, имеющих первостепенное значение для достижения хорошей программной архитектуры. Безусловно, понятие архитектуры шире рассматриваемых элементов, но мы остановимся именно на них. Эти элементы играют немаловажную роль при разработке крупномасштабного программного обеспечения.
Декомпозиция
Декомпозиция означает разбиение системы на меньшие логические части с целью преодолеть общую сложность системы. Результатом декомпозиции являются, например, модули, подсистемы и компоненты.
Декомпозиция помогает в определении и выяснении интерфейсов между различными частями системы. Она также может быть полезна в ситуациях, когда требуется интегрировать в систему старые или приобретенные на стороне приложения.
Декомпозиция может также облегчить распространение программного обеспечения на несколько машин. Конечно, она имеет тот недостаток, что неправильное или слишком дробное разбиение легко может привести к серьезному падению производительности вследствие роста издержек на сообщение между частями.
Дополнительное преимущество декомпозиции в том, что она позволяет естественным образом разделить задачи по разработке и распределить их между членами большой группы.
В языке UML декомпозиция моделируется посредством пакетов, модулей и подсистем. На платформе J2EE декомпозиция может быть реализована через Web-компоненты и компоненты Enterprise JavaBeans (EJB).
На рис. 6.1 изображена простая система, разбитая на несколько подсистем.
Компоненты
Компонент— это связный модуль программного обеспечения, предоставляющий набор родственных функций и услуг.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.