30. Различные представления системы

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

Моделирование системы с использованием различных представлений осуществляется следующим образом:

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

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

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

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

Допустим, если вы моделируете простое приложение, выполняемое на одном компьютере, могут потребоваться только перечисленные диаграммы:

вид с точки зрения вариантов использования - диаграммы прецедентов;

вид с точки зрения проектирования - диаграммы классов для структурного моделирования и диаграммы взаимодействия для моделирования поведения;

Если же разрабатываемая система реактива или относится к управлению рабочим процессом, то для моделирования ее поведения понадобятся соответственно диаграммы состояний и действий. Если система построена на архитектуре "клиент/сервер", то стоит включить в работу диаграммы компонентов и развертывания для моделирования конкретных физических деталей реализации. Наконец моделируя сложную распределенную систему, используйте все имеющиеся в UML диаграммы, Они позволяют выразить ее архитектуру и связанный с проектом технический риск. Вам потребуется следующее:

вид с точки зрения прецедентов - диаграммы прецедентов и диаграммы действий (для моделирования поведения);

вид с точки зрения проектирования - диаграммы классов (структурное моделирование), диаграммы взаимодействия и диаграммы состояний (моделирование поведения);

вид с точки зрения процессов - снова диаграммы классов (структурное моделирование) и диаграммы взаимодействия (моделирование поведения);

вид с точки зрения реализации - диаграммы компонентов;

вид с точки зрения развертывания - диаграммы развертывания.

То, что одном уровне абстракции выглядит как система, на другом, более высоком, представляется подсистемой. Аналогичным образом, то что на одном уровне является подсистемой, вполне может рассматриваться как полноценная система группой проекта, ответственной за ее создание.

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

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

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

Для каждой подсистемы специфицируйте ее контекст, так же как это делается для системы в целом при этом число актеров, окружающих систему включаются все соседние подсистемы, поэтому необходимо проектировать их совместную работу;

Смоделируйте архитектуру каждой подсистемы так же, как это делается для всей системы.

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

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

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