Влияние коммерческих компонентов

Как мы говорили в главе 18, возможности коммерческих компонентов неуклон­но возрастают и они становятся все более доступными. Аналогичные тенденции наблюдаются в области предметно-ориентированных вариантов архитектуры и кар­касов, облегчающих применение коммерческих компонентов. Справедливы они и в отношении спецификации J2EE, направленной на информационно-техноло­гические варианты архитектуры. Через некоторое время предметно-ориентирован­ные варианты архитектуры и каркасы появятся в большинстве общеупотребитель­ных на сегодняшний день предметных области. Когда это случится, архитекторам придется озаботиться ограничениями, присущими выбранному каркасу, — веро­ятно, проектирование на основе каркасов будет распространено не меньше, чем индивидуальное проектирование.

Но даже наличие компонентов с расширенной функциональностью не освобо­дит архитектора от решения проектных задач. В первую очередь, архитектор дол­жен определиться со свойствами применяемых компонентов. Компоненты, выра­жающие архитектурные допущения, требуют идентификации и оценки воздействия на проектируемую систему — все это должен делать архитектор. Для этого нужен богатый выбор атрибутных моделей и серьезные лабораторные исследования, а иногда и то и другое. В поисках надежных прогнозов потребители компонентов обращаются к зарекомендовавшим себя аттестационным агентствам (одно из них — Underwriters Laboratories).

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

Наконец, требуются новые компоненты и соответствующие им каркасы; про­изводиться они должны в расчете на реализацию желаемых атрибутов качества. Проектировщики должны ориентироваться не на конкретную компанию, а на совокупность заинтересованных лиц в масштабах всей отрасли. Более того, тре­бования по атрибутам качества, сформулированные общими усилиями заинтере­сованных лиц в индустрии в целом, скорее всего, будут значительно разнообраз­нее, чем требования заинтересованных лиц в масштабах отдельной компании.

Заключение

В каком направлении движутся исследования программной архитектуры и их практические результаты? Мы не более проницательны, чем многие другие, что, впрочем, совершенно не означает, что мы воздержимся от прогнозов. Помимо расширения возможностей методик проектирования, развития инструментов жизненного цикла в сторону упрочения позиций архитектурной информации, а также усложнения стандартных блоков компонентов, мы возьмем на себя сме­лость предположить направление дальнейшего развития архитектуры в целом.

Когда Фреда Брукса однажды спросили, почему его книга «Мифический че­ловеко-месяц» стала хрестоматийной, он ответил в том духе, что книга на самом деле не о компьютерах, а о людях. С программной инженерией — то же самое. Дэйв Парнас очень удачно сформулировал различие между программированием и программной инженерией. По его мнению, для продуктов, которые разрабаты­вает один человек в единственной версии, программирования вполне достаточ­но. Однако если вы предполагаете, что с продуктом будут работать сторонние пользователи (или хотя бы хотите впоследствии дать ему самостоятельную оцен­ку), без программной инженерии не обойтись. Те же слова можно сказать и про архитектуру Если бы наши заботы ограничивались вычислением правильного ответа, хватило бы банальной монолитной архитектуры. Архитектура нужна для удовлетворения потребностей тех людей, которые будут работать с проектиру­емой системой, — она обеспечивает достаточную производительность, позволяет укладываться в рамки бюджета, достигать желаемых выгод, консолидировать коллектив разработчиков, упрощать задачи специалистов по сопровождению и, на­конец, растолковывать суть системы заинтересованным лицам.

Учитывая все эти обстоятельства, мы сделаем прогноз, в котором уверены на все сто. Позиции архитектуры будут сохраняться до тех пор, пока в проектирова­нии и разработке программных средств участвуют живые люди.

ПРОГРАММНАЯ АРХИТЕКТУРА В ОБРАЗОВАНИИ

В этой главе мы обсудили техническую будущность программной архитектуры и изложили наши соображения по поводу ее дальнейшего развития. Но есть и другой вопрос — какое место займет изучение архитектуры в будущих образовательных программах в области про­граммной инженерии? Наблюдательный читатель, вероятно, заметил, что в написании этой книги участвовали три члена семейства Бассов. Я получил степень бакалавра математики в 1964 году, Таня стала бакалавром компьютерных наук в 1991-м, а Мэтт — в 2000-м. Из моего опыта и опыта членов моей семьи можно сделать некоторые выводы.

К моменту получения диплома я видел компьютер один раз в жизни (нас водили на экс­курсию лишь затем, чтобы его увидеть). Я абсолютно ничего не смыслил в программирова­нии и принципах работы компьютеров. Естественно, меня сразу взяли на работу программи­стом. Мир тогда был совсем другим.

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

Таня, получив диплом, уже знала несколько языков программирования, в том числе С; курс по С++ в ее время еще не читался, равно как и курсы по основам объектно-ориентиро­ванной технологии. Когда выпускником стал Мэтт, он тоже успел изучить несколько языков программирования, но уже других — в частности, С++ и Java. Кроме того, он имел представ­ление об объектно-ориентированном проектировании.

Итак, за девять лет в учебный план вошли объектно-ориентированные языки и соответ­ствующие методики. Мэтт не изучал архитектуру, однако к моменту его выпуска курсы по про­граммной архитектуре успели войти в норму на старших курсах и начали появляться на млад­ших.

Получив образование, Мэтт освоил значительно больше элементов абстракции и проек­тирования, чем Таня, и эта тенденция, конечно, будет продолжаться. Таким образом, по мое­му мнению, к 2010 году курсы программной архитектуры на младших курсах станут совер­шенно обычным явлением, а в некоторых университетах на этом уровне будет предусмотрено сразу несколько дисциплин. Выпускников-специалистов в области программной архитекту­ры будет уже в достатке.

Мы надеемся на то, что материал, изложенный в этой книге, в 2010 году будет читаться в университетах, и на то, что наш курс программной архитектуры не будет единственным.

-LJB