Этот список не подразумевает, что не может быть других представлений. Например, для приложений на J2EE было бы разумно и желательно иметь представление безопасности или транзакций.
Четыре архитектурных представления Хофмайстера и др.
Хофмайстер (Hofmeister), Норд (Nord) и Сони (Soni) представили несколько отличный подход к программной архитектуре (Hofmeister, 2000), базирующийся на четырех представлениях. Некоторые из этих представлений частично совпадают с представлениями модели "4 +1", описанными выше.
· Концептуальное представление занимается прежде всего концептуальной декомпозицией системы на очень крупные компоненты, называемые капсулами. Эти капсулы взаимодействуют друг с другом через концептуальные соединители. Капсулы и соединители образуют основу для возможной программной системы.
· Представление модулей связано с реализацией капсул и соединителей. Крупные компоненты отображаются на реально существующие подсистемы и модули в контексте определенной технологии, которая будет использована для проекта.
· Представление выполнения связано с передачей управления в исполняющей системе. К нему относятся такие вопросы, как параллельная обработка, распределение и производительность.
· Представление кода показывает, как компоненты отображаются на исходный текст и исполняемые файлы, а также такие аспекты, как время и средства разработки.
Заключительные штрихи
Что должно быть сначала — программная архитектура или анализ? Ответ, по крайней мере частично, зависит от того, кто задает такой вопрос.
Архитектура создает черновой набросок программного обеспечения, но без надлежащего анализа нельзя по-настоящему разобраться в системе, как это требуется для создания такого чернового наброска. Таким образом, этот процесс можно назвать итерационным в том смысле, что требования вносят ключевой вклад в программную архитектуру, и в тоже время может потребоваться скорректировать или прояснить требования, чтобы достичь определенной архитектуры.
Разработка программной архитектуры — в значительной степени эволюционный процесс. Хотя архитектор и предпочел бы начать работу с каких-то общих соображений о приемлемости или неприемлемости, основываясь на предыдущем опыте, он не может просто принять требования и ожидать, что внезапно появится окончательная архитектура. Архитектура принимает окончательный вид постепенно, по мере того, как принимаются осознанные, обоснованные решения с учетом определенных требований и компромиссов.
Следует подчеркнуть, что понятия, рассматриваемые в данной главе, надо представлять себе прежде всего как инструменты в распоряжении архитектора. Как и любые инструменты, они могут приносить пользу, только если применяются в надлежащем контексте, а не просто ради использования каких-то концепций. Например, если для возникшей проблемы нельзя найти подходящего шаблона, не имеет смысла менять проект так, чтобы приспособить его к доступным шаблонам.
Далее мы будем рассматривать архитектурные аспекты в их надлежащем контексте, т. е. наряду с анализом и проектированием, по мере того как будут возникать определенные проблемы.
Резюме
Программная архитектура — это крайне важный, но часто игнорируемый или по крайней мере неправильно толкуемый аспект разработки программного обеспечения предприятия.
Программная архитектура имеет много аспектов и означает больше, чем просто структуру программы. Программную архитектуру нельзя описать какой-то одной диаграммой.
Ключевые понятия в области программной архитектуры — это декомпозиция, многоуровневое представление, ярусы, шаблоны, контуры и компонентное программирование. Это скорее инструменты, которыми по своему усмотрению может пользоваться архитектор, чем обязательно подлежащие выполнению элементы любого программного проекта.
Разработка программной архитектуры является эволюционным процессом и должна происходить в контексте требований и одновременно с анализом. Именно такой подход принят в данной книге.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.