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

В этой главе дается также краткое описание внедрения других аспектов технологически нейтральной архитектуры.

Реализация сценариев использования и контрактов

Сценарии использования служат одним из первых артефактов (после проек­ции eTOM/SID), которые описывают взаимодействие между пользователем и системой, выражая его в терминах бизнес-сущностей, вовлеченных во вза­имодействие. Поэтому не следует задаваться вопросом, должны ли внедрять­ся сценарии использования или какая-то другая форма артефакта, описыва­ющая взаимодействие между пользователем и системой. Поскольку сценарии использования — это неотъемлемая часть NGOSS, ниже мы будем исходить из того, что для описания взаимодействия используются именно они.

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

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

• выгода (или, наоборот, ее отсутствие) в поддержке обоих ракурсов,

• заинтересованность исполнителей, внедряющих NGOSS, в сохранении различий между ракурсами,

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

• возможность (или ее отсутствие) объединить оба ракурса с помощью имеющихся инструментов, когда это необходимо.

Диаграммы последовательностей представляют собой первый этап фор­мализации превращения сценариев использования в контракты. Исполни­телям при этом рекомендуется задаться вопросом: «Имеет ли смысл строить диаграммы последовательности для каждого сценария использования?» От­вет на этот вопрос часто зависит от сложности сценария. Выгоды, достигае­мые за счет разработки диаграмм последовательностей для простых сцена­риев использования, не всегда окупают затраты на их разработку.

Контракты как базовые блоки, обеспечивающие совместимость компо­нентов решения, являются неотъемлемой частью NGOSS. Контракты дают детальное описание интерфейса, в чем-то схожее с прикладным программ­ным интерфейсом (API), а также механизм отслеживания, который связыва­ет контракт с другими артефактами NGOSS, такими как процессы еТОМ, объекты SID, диаграммы последовательностей и др.

Цель контракта почти совпадает с задачей традиционной спецификации разработки приложения.

Бизнес-контракт включает в себя:

• заглавную часть, содержащую имя, идентификатор и версию конт­ракта,

• описательную часть, содержащую цель, описание и критерии поиска,

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

• нефункциональную часть, содержащую описание развертывания, ор­ганизационные, юридические и прочие аспекты контракта,

• управленческую часть, определяющую управленческие операции, рас­пределение ответственности И Т. П.,

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

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

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