Часть 4. От одной системы к множеству

Часть 3. Анализ архитектуры

Глава 11. Метод анализа компромиссных архитектурных решений — комплексный подход к оценке архитектуры. Метод анализа компромиссных архитектурных решений (Architecture Tradeoff Analysis Method, АТАМ) позволяет оценить архитектурные решения в контексте требований к поведению и атрибутам качества. Наряду с описанием метода АТАМ в этой главе приводится полноценный пример его применения.

Глава 12. Метод анализа стоимости и эффективности — количественный подход к принятию архитектурно-проектных решений. Программные архитекторы и руководители проектов всегда стремятся довести до максимума разницу между прибылью от системы и стоимостью ее реализации. Метод анализа стоимости и эффективности (Cost Benefit Analysis Method, СВАМ) позволяет принимать экономические решения, исходя из анализа архитектуры. Основываясь на АТАМ, метод СВАМ обеспечивает возможность моделирования издержек и прибыли архитектурно-проектных решений и предусматривает средства их оптимизации. В этой главе мы не только представим метод СВАМ, но и охарактеризуем конкретный пример его применения.

Глава 13. Всемирная паутина. Конкретный пример реализации способности к взаимодействию. Начало развитию Всемирной паутины положило намерение руководства отдельно взятой организации наладить обмен информацией между штатными исследователями; в контексте конечного результата эта первоначальная задача кажется незначительной. В данной главе описывается архитектура программного обеспечения, на основе которого функционирует Всемирная паутина, объясняется, каким образом оно определило дальнейший рост глобальной сети и какое влияние этот рост в свою очередь оказал па обращающиеся к ее услугам организации.

Глава 14. Линейки продуктов. Повторное использование архитектурных средств. Программная архитектура, применяемая в качестве основы для формирования линейки программных продуктов, оказывается крайне эффективной. В этой главе представлены элементарные принципы производства линеек программных продуктов, причем архитектура преподносится в роли основного фактора обеспечения подвижек по части продуктивности, сроков выхода на рынок, качества и затрат. Ряд действий в рамках разработки программных средств и управления Этим процессом рассматриваются в этой главе достаточно подробно, поскольку в контексте формирования линеек продуктов они занимают особое место.

Глава 15. CelsiusTech. Конкретный пример разработки линейки продуктов CelsiusTech — это название компании, которой удалось с успехом реализовать выстроенную на архитектуре линейку продуктов. Эта архитектура и предметом рассмотрения в данной главе; здесь мы делаем попытку объясню] почему именно архитектура оказалась основным условием достижений CelsiusTech Выбери компания какую-либо другую методику, ей не удалось бы сконструировать намеченные системы — у нее просто не хватило бы сотрудников. Ориентация на линейки продуктов отразилась как на организационной структуре компании, так и на стиле аргументации и ведения переговоров с клиентами.

Глава 16. J2EE/EJB. Конкретный пример стандартной вычислительной инфраструктуры. В этой главе речь идет о спецификации корпоративной архитектуры Java 2 (Java 2 Enterprise Edition, J2EE) от компании Sun Microsystems, а также об одной из ее важнейших составляющих — архитектурной спецификации Enterprise JavaBeans (Enterprise JavaBeans, EJB). Спецификация J2EE содержит стандартное описание процессов проектирования и разработки распределенных объектно-ориентированных программ на языке Java. Мы анализируем коммерческие факторы, обусловившие создание стандартной архитектуры производства распределенных систем, а также рассматриваем ориентированные на удовлетворение соответствующих потребностей средства J2EE/EJB.

Глава 17. Архитектура Luther. Конкретный пример мобильных приложений на основе архитектуры J2EE. Архитектура Luther изначально мыслилась как универсальная структура, позволяющая внедрять специализированные решения в предметной области технического обслуживания и эксплуатации крупногабаритных транспортных средств и в рамках промышленной инфраструктуры. Поскольку в ее основе лежит архитектура J2EE, эту главу можно считать обзором одного из вариантов применения рассматриваемой в главе 16 универсальной структуры J2EE/EJB. Приведенный в ней конкретный пример ориентирован на такую среду, в которой конечный пользователь, располагая соединением по беспроводной сети, оперирует неким устройством с ограниченными возможностями ввода- вывода и/или ограниченными вычислительными возможностями.

Глава 18. Конструирование систем из коробочных компонентов. Чем дальше, тем больше в процессе конструирования систем используется готовых, «коробочных», компонентов. Поскольку они способны накладывать на архитектуру определенные ограничения, их использование некоторым образом видоизменяет процесс проектирования. Как правило, отбор компонентов диктуется намерением реализовать некий набор функциональных возможностей; с другой стороны, компоненты предполагают некие архитектурные допущения, а следовательно, и допущения в отношении качества. В этой главе рассматривается довольно простой процесс, при помощи которого любой архитектор сможет отобрать только те компоненты, которые способны к успешному взаимодействию. Иллюстрируется эта методика на примере недавно созданной системы.

Глава 19. Будущее программной архитектуры. Здесь мы еще раз пробежимся по архитектурно-экономическую циклу, попробуем сформулировать задачи программной архитектуры, которые еще предстоит решить, и приведем доводы в пользу проведения дальнейших исследований в этой области.

Дата добавления: 2015-04-25