Затраты 3 страница

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

Операция 7: мозговой штурм и расстановка сценариев согласно приоритетам

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

мозгового штурма, подлежит сравнению с перечнем, составленным согласно де­реву полезности. Если эти два документа не противоречат друг другу, значит, намерения архитектора и ожидания заинтересованных лиц сходятся. Выявление новых значимых сценариев — это уже риск, свидетельствующий о рассогласова­нии целей заинтересованных лиц, с одной стороны, и архитектора — с другой.

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

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

После сбора сценариев следует операция по расстановке среди них приорите­тов. Такая необходимость вызвана теми же факторами, которые обусловливают назначение приоритетов на дереве полезности, — участники группы оценки долж­ны знать, чему следует уделить ограниченные временные ресурсы. Во-первых, заинтересованных лиц просят соединить воедино сценарии, которые, по их мне­нию, выражают один и тот же тип поведения или одну и ту же задачу по атрибуту качества. Затем путем голосования из числа получившихся сценариев выбираются наиболее важные. Каждому заинтересованному лицу предоставляется количе­ство голосов, составляющее 30 % от общего числа сценариев^[3], после чего полу­ченное число округляется. Так, если сценариев всего двадцать, каждое заинтере­сованное лицо получает по шесть голосов. Распоряжаться ими заинтересованное лицо может произвольно — если потребуется, оно отдаст все шесть голосов за один сценарий, или по одному голосу за'каждый из любых шести сценариев, или примет какое-либо промежуточное решение.

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

Операция 8: анализ архитектурных методик

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

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

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

Операция 9: презентация результатов

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

♦ документированные архитектурные методики;

♦ набор сценариев, сформулированных методом мозгового шторма, и их при­оритеты;

♦ дерево полезности;

♦ выявленные риски;

♦ установленные нерисковаиные решения;

♦ найденные точки чувствительности и компромиссы.

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

Для каждого из установленных магистральных рисков группа определяет на­ходящиеся под его воздействием коммерческие факторы (они должны были быть выявлены в ходе операции 2). Определение магистральных рисков и их связей с конкретными факторами замыкает процесс оценки, поскольку его конечные ре­зультаты соотносятся с первоначальной презентацией. Не менее важно, что оно раскрывает перед ответственными лицами суть установленных рисков. То, что руководитель ранее рассматривал как далекий от практического контекста технический вопрос, теперь со всей очевидностью предстает как угроза, лежащая в зоне его ответственности.

В табл. 11.3 отражены все девять операций АТАМ и показана степень их вли­яния на конечные продукты оценки по этой методике. обозначает операции, которые напрямую воздействуют на эти результаты, а «*» — операции, влияющие на них лишь косвенно.

Таблица 11.3. Коррелированные операции и продукты АТАМ’

^a В ходе установления коммерческих факторов излагается первоначальное, наиболее общее описание атрибутов качества.

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

^с В своей презентации архитектор может установить дополнительные риски.

^d В своей презентации архитектор может выявить дополнительные точки чувствительности или комп­ромиссы.

^e Стандартные сопутствующие риски характерны для многих архитектурных методик.

^f Многим архитектурным методикам свойственны стандартные сопутствующие варианты чувстви­тельности и компромиссы между атрибутами качества.

^f В ходе рассматриваемых аналитических операций возможно выявление новых архитектурных ме­тодик, не замеченных во время операции 4; в таком случае формулируются новые методико-ориен- тированные вопросы.

¹ Источник: приводится по изданию [Clements 02а] (адаптированная версия).

ИХ РЕШЕНИЕ НЕ ГОДИТСЯ---------------------------------------------------------------------------------------------------

Возможно, у вас сложилось такое впечатление, что роль заинтересованных лиц в ходе прове­дения оценки по методу АТАМ сводится к формулированию задач архитектуры и сценариев. В этом контексте следует заметить, что их присутствие во время презентации и оценки архи­тектуры не раз сыграло очень важную роль. Уровень знаний, которыми обладают заинтере­сованные лица, позволяет им заострять внимание на важных проблемах, которые архитекту­ра (или специалист, выступающий на ее презентации) обходит стороной. В качестве примера приведем случай с оценкой системы управления финансами — прикладной области, в кото­рой оценщики не слишком хорошо разбирались. Из-за этого во время оценки неоднократно разгорались дискуссии — в частности, такая.

Оценщик: Ладно, перейдем к следующему сценарию. Предоставляет ли ваша система такую-то возможность?

Производитель (мило улыбаясь): Конечно! От пользователя требуется лишь ввести но­мер счета, вызвать таблицу дебиторской задолженности и перенести результаты в файл уве­домления спонсора.

Оценщик (одобрительно кивая, проверяя «нерискованность» сценария и радуясь тому, что оценка обещает пройти легче, чем он предполагал): Здорово! Так, теперь следующий сценарий.

Пользователь системы 1 (возмущенно): Секундочку! Вы хотите сказать, что перемещать данные автоматически нельзя? Это что ж получается — мне придется их вводить во все фай­лы уведомлений?

Производитель (с первыми признаками нервозности): Ну-у-у, вы знаете...

Пользователь системы 1 (в оскорбленных чувствах): Да вы знаете, сколько спонсоров у крупного университета вроде нашего?!

Производитель (теребит свой воротник): Что, много?

Пользователь системы 1 (теперь его черед мило улыбнуться): Да! Много.

Пользователь системы 2: А что, если я не знаю, какой номер счета вводить? Операция-то проводится именно по этой причине. В противном случае легче взять расписку об обновле­нии платежа.

Пользователь системы 1 (оценщику): Их решение не годится,

Оценщик (честно пытаясь вспомнить, что такое файл уведомления спонсора, почесывая голову по поводу этой загадочной расписки об обновлении платежа и, наконец, осторожно затирая поставленную было галочку): Так... кажется, у нас здесь риск. Как вы считаете, что следует изменить?

Вывод один. Компетентные заинтересованные лица способны выискать проблему, недо­ступную людям со стороны.

-РСС

Эффективное распоряжение ограниченными временными ресурсами

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

11.4. Система Nightingale: конкретный пример проведения оценки по методу АТАМ

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

Нулевой этап: установление партнерских отношений и подготовка

Заказчик оценки, который связался с нами, ознакомившись с опубликованными на нашем веб-сайте материалами но методу АТАМ, оказался представителем круп­ного производителя программных систем для учреждений здравоохранения, со­трудничавшего с больницами, клиниками и НМО. Система, которую нам пред­стояло проверить, называлась Nightingale. Нам рассказали, что это крупная система, состоящая из нескольких миллионов строк кода, довольно давно перешедшая в стадию реализации. У нее уже был первый покупатель — сеть из сорока с лиш­ним больниц, расположенных на юго-западе Соединенных Штатов.

Естественно, мы недоумевали, зачем заказчику проводить оценку архитекту­ры, если система почти готова к выпуску и распространению? Оказывается, он руководствовался двумя соображениями. Во-первых, если в архитектуре есть се­рьезные недостатки, в чем бы они ни проявлялись, об этом лучше узнать как можно раньше; во-вторых, компания, намеревавшаяся продавать систему другим своим клиентам, осознавала необходимость ее адаптации к потребностям, вари­антам применения и регулятивному окружению каждого из них. Следовательно, пусть даже архитектура оказалась подходящей для первого, дебютного заказчи­ка, компании нужно было убедиться в том, что она в достаточной степени вынос­лива и модифицируема а, значит, сможет послужить основой для создания се­мейства систем управления в области здравоохранения.

Предполагалось, что рассматриваемая система после ее установки в учрежде­ниях здравоохранения будет исполнять роль информационной магистрали. В ее функции, помимо прочего, входило предоставление данных об истории болезни пациентов, отслеживание их страховых и прочих взносов. Являясь одновременно информационным хранилищам, она должна была выявлять разного рода тенден­ции (например, предшественников и рецидивы отдельных болезней). Система также должна была генерировать большое количество периодических отчетов и отчетов по требованию, причем каждый из них следовало адаптировать к по­требностям конкретного учреждения. Для тех пациентов, которые вносили пла­тежи самостоятельно, система должна была выполнять последовательность дей­ствий, связанных с инициализацией и обслуживанием ссуды на протяжении всего периода ее погашения. Более того, поскольку система должна была работать (или, по меньшей мере, быть доступной) во всех подразделениях данного учреждения здравоохранения, от нее требовалась настраиваемость на все возможные конфи-

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

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

Таблица 11.4. Распределение ролей между участниками группы оценки

Участник	Роль
	Руководитель группы, руководитель специалистов по оценке, дознаватель
	Руководитель специалистов по оценке, дознаватель
	Хронометрист, дознаватель
	Секретарь по сценариям, дознаватель, сборщик данных
	Дознаватель, координатор процесса
	Секретарь по результатам, наблюдатель за процессом

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

Мы провели однодневное вступительное совещание, на котором присутство­вали участники группы оценки, руководитель проекта, главный архитектор, а также руководитель проекта первого покупателя Nightingale. Троих последних можно причислить к категории лиц, ответственных за проект. В результате мы узнали много нового о возможностях системы и требованиях к ней, получили каталог готовой архитектурной документации (из которого мы выбрали нужные для на­ших целей документы) и составили список заинтересованных лиц, которых пред­полагалось пригласить во время проведения второго этапа. Кроме того, мы согла­совали график проведения совещаний на первом и втором этапах и установили срок предоставления сводного отчета. Наконец, мы обговорили подробности пре­зентаций, которые во время операций 2 и 3 первого этапа должны были сделать руководитель проекта и архитектор соответственно, и убедились в том, что им понятно, что мы хотим от них услышать.

¹ Шесть оценщиков — это много. Как мы уже говорили, п группу оценки, как правило, входят от трех до пяти специалистов; и среднем — четыре. В данном случае группу расширили за счет двух новых сотрудников, которым предстояло ознакомиться с процессом АТАМ более подробно и на практике наработать опыт.

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

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

Этап 1: оценка

Согласно схеме первого этапа, участники группы оценки встретились с ответ­ственными за проект лицами. Помимо специалистов, присутствовавших на всту­пительном совещании (руководитель проекта, главный архитектор и еще один руководитель проекта, представляющий первого покупателя Nightingale), к нам присоединились двое главных проектировщиков.

Операция 1: презентация АТАМ

В ходе презентации руководитель специалистов по оценке обратился к стандарт­ному пакету схем нашей организации и с его помощью объяснил присутству­ющим суть метода. На протяжении часа он рассказывал им об операциях и эта­пах АТАМ, описывал концептуальные основы метода (сценарии, архитектурные методики, точки чувствительности и т. п.) и перечислял продукты, которые пред­полагалось получить в результате его проведения.

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

Операция 2: презентация коммерческих факторов

Руководитель проекта от компании-заказчика изложил коммерческие задачи, поставленные перед системой Nightingale компанией-разработчиком и потенци­альными заказчиками. Как выяснилось, компания-разработчик предъявляла к Nightingale следующие требования:

♦ поддержка различных вариантов использования системы дебютным заказ­чиком (в частности, отслеживание историй болезни и платежных историй, выявление тенденций и т. д.);

♦ создание новой версии системы (предназначенной для установки в кабине­тах врачей), которую компания-разработчик могла бы предлагать другим заказчикам.

Последний коммерческий фактор свидетельствовав! о том, что на основе рас- сматриваемой архитектуры планировалось не просто разработать отдельную си­стему, а учредить целую линейку программных продуктов (см. главу 14).

Первый заказчик Nightingale планировал развернуть ее взамен существующих систем, которые:

♦ устарели (одной из них было больше 25 лет);

♦ были основаны на старых языках и технологиях (в частности, COBOL и ас­семблере IBM);

♦ оказались неудобными по части сопровождения;

♦ не отвечали текущим и перспективным коммерческим потребностям уч­реждений системы здравоохранения, в которых размещались.

Первый заказчик выдвигал следующие коммерческие требования:

♦ способность реагировать на культурные и региональные различия;

♦ поддержка нескольких языков (в основном английского и испанского) и ва­лют (в особенности американского доллара и мексиканского песо);

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

♦ новая единая система должна была сочетать в себе разнородные унаследо­ванные системы управления финансами.

Коммерческие ограничения были таковы:

♦ соблюдение принципа неувольнения сотрудников, осуществляемого путем их переподготовки;

♦ приверженность принципу разработки «лучше купить, чем сконструиро­вать»;

♦ учет сокращения рыночного положения заказчика (за счет повышения кон­куренции).

Технические ограничения были сформулированы следующим образом:

♦ при любой возможности предпочтение следовало отдавать коробочным программным компонентам;

♦ реализовать систему требовалось в течение двух лет, имея в виду, что заме­на аппаратного обеспечения проводится регулярно, каждые 26 недель.

Первостепенными были признаны следующие атрибуты качества:

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

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

♦ Удобство сопровождения. Система должна быть удобной в сопровождении, легко конфигурируемой и расширяемой. Только в этом случае она сможет адаптироваться к выходу на новые рынки (в частности, к размещению в кабинетах врачей), удовлетворять новым требованиям заказчиков, при­спосабливаться к изменению законов и норм штатов и к культурным и региональным различиям.

Нижеследующие атрибуты качества руководитель проекта признал важными, но не в такой степени, как вышеперечисленные:

♦ Безопааюстъ. Система должна была соответствовать коммерческому стан­дарту безопасности (другими словами, обеспечивать конфиденциальность и целостность данных) для систем управления финансами.

♦ Готовность. В рабочие часы от системы требовалось высокая готовность.

♦ Расширяемость. В перспективе расширять систему предполагалось для ее адаптации к потребностям крупных больниц, а сокращать — в расчете на самые миниатюрные клиники.

♦ Модульность. Компания-разработчик планировала продавать не только новые версии Nightingale в целом, но и ее отдельные компоненты. Для того чтобы осуществить эту затею, необходимо было реализовать атрибуты ка­чества, близкородственные удобству сопровождения и масштабируемости.

♦ Контролепригодность и удобство поддержки. Система должна была быть доступной для понимания техническими специалистами в штате заказчи­ка; такая необходимость обусловливалась перспективами обучения персо­нала и продолжительного использования.

Операция 3: презентация архитектуры

В ходе совместной работы участников группы оценки и архитектора — как до, так и во время оценки — было сформулировано несколько новых представлений архитектуры и архитектурных методик. Основные выводы состояли в следу­ющем.

♦ В составе Nightingale было две крупные подсистемы: диспетчер оператив­ных транзакций (OnLine Transaction Manager, OLTM) и диспетчер приня­тия решений и составления отчетов (Decision Support and Report Generation Manager, DSRGM). OLTM должен был отвечать требованиям по интерак­тивной производительности, a DSRGM исполнял роль системы пакетной обработки, исполнявшей периодически инициируемые задания.

♦ При конструировании системы Nightingale в ней предусматривалась высо­кая конфигурируемость.

♦ Подсистема OLTM состояла из нескольких четко разделенных уровней.

♦ Nightingale была системой репозитарного типа; ее основу составляла круп­ная коммерческая база данных.

♦ Nightingale испытывала исключительную зависимость от коробочного про­граммного обеспечения; в такой форме в ней были реализованы центральная база данных, процессор правил, механизм автоматизации документооборо­та, CORBA, блок веб-хостинга, инструменты распределения программных средств и многое другое.

♦ Для Nightingale было характерно строгое следование объектно-ориентиро­ванной технологии и реализация конфигурируемости по большей части за счет объектных каркасов.

Рис. 11.2. Многоуровневое представление OLTM, изображенное архитектором в неформальной нотации

На рис. 11.2 показано многоуровневое представление OLTM, изображенное архитектором в неформальной нотации. На рис. 11.3 представлена схема функ­ционирования OLTM в период исполнения — основные потоки информации и дан­ных между частями системы, размещенными на различных аппаратных процес­сорах. Обе схемы мы приводим почти без изменений, для того чтобы наилучшим образом отразить реальные условия проведения оценки по методу АТАМ. Обра­тите внимание на их неполное соответствие — на рис. 11.2 диспетчер транзакций и CORBA присутствуют, а на рис. 11.3 их нет. Подобного рода упущения во вре­мя оценки случаются сплошь и рядом, и в этом смысле значительную важность представляет один из шагов третьей операции, во время которого оценщики, пытаясь лучше понять архитектуру, задают вопросы о несоответствиях на диа­граммах. Аналогичное представление периода прогона для OLTM, где любую транз­акцию можно проследить в масштабе всей системы, показано на рис, 11.4; здесь,

Рис. 11.3. Представление, изображающее передачу информации, потоки данных и процессоры OLTM

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

Все перечисленные представления системы Nightingale в равной степени ра­зумны и несут важную смысловую нагрузку. На них изображены отдельные ас­пекты, значимые в контексте различных задач. Все они впоследствии были за­действованы при проведении аналитических действий в рамках АТАМ.

Операция 4: выявление архитектурных методик

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

♦ многоуровневая организация, в особенности в OLTM;

♦ объектно-ориентированная технология;

♦ реализация модифицируемости через конфигурационные классы без запи­си или перекомпиляции;

♦ обработка транзакций по схеме «клиент-сервер»;

Рис. 11.4. Архитектурная проекция потока данных внутри OLTM

♦ информационно-ориентированный архитектурный образец с коммерческой базой данных в качестве основы.

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