Введение. UML – это графический язык для визуализации, специфицирования, конструирования и документирования артефактов программной системы

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

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

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

В UML предусмотрены средства для графического представления систем и подсистем. Такая нотация позволяет визуализировать декомпозицию системы на меньшие подсистемы. Изображаются система и подсистема в виде пиктограммы стереотипного пакета. Для моделей и видов нет специального графического представления, так как эти сущности – объект манипуляции инструментальных программ, которыми пользуются разработчики для организации представления различных видов системы, в самом плохом случае – это просто листы бумаги с нарисованными на них диаграммами.

Системы и подсистемы. Модели и представления

Система (system), возможно разложенная на ряд подсистем, - это множество элементов, организованных некоторым образом для выполнения определенной цели. Она описывается набором моделей, зачастую с различных точек зрения. Подсистема (subsystem) – это объединение элементов, ряд которых составляет спецификацию поведения, предложенного другими ее элементами. Система и подсистема изображаются в виде пиктограммы стереотипного пакета. Напомним, что модель (model) – это упрощение реальности, абстракция, которая создается для лучшего восприятия системы. Вид или представление (view) – это модель, рассматриваемая под определенным углом зрения: в ней отражены одни сущности и опущены другие, которые с данной точки зрения не представляют интереса.

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

Рис. Системы и подсистемы.

Являясь стереотипным пакетом, система владеет некоторыми элементами. Если рассмотреть систему изнутри, то можно увидеть все ее модели и отдельные элементы, в том числе и диаграммы, которые очень часто будут разложены на более мелкие подсистемы. Подсистемы – это образования, которые используются для декомпозиции системы на более простые, слабо зависящие друг от друга составляющие. То, что на одном уровне абстракции выглядит системой, на другом, более высоком, может рассматриваться как подсистема. В UML подсистема изображается в виде пиктограммы стереотипного пакета (см. рис.).

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

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

Модель – это разновидность пакета. Явно моделировать ее приходится не так уж часто, и поэтому специального графического символа для моделей в рамках UML не предусмотрено. Однако инструментальные средства должны каким-то образом манипулировать моделями, обычно, для этих целей они использую нотацию пакетов. Будучи пакетом, модель владеет некоторыми элементами. Модели, ассоциированные с системой и подсистемой, образуют исчерпывающее разбиение ее элементов. Это означает, что каждый элемент принадлежит одному и только одному пакету. Как правило, артефакты системы и подсистемы организуются в несколько неперекрывающихся моделей. Все возможные модели охватываются пятью представлениями, или видами архитектуры программного обеспечения, о которых мы говорили в начале нашего курса.

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

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

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

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

Моделирование системной архитектуры

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

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

· Идентифицируйте сущности, которые вы будете использовать для представления архитектуры. Чаще всего это виды с точки зрения прецедентов. Процессов, реализации и развертывания.

· Специфицируйте контекст системы, включая окружающих ее актеров.

· При необходимости разложите систему на элементарные подсистемы.

При моделировании системы в целом и ее подсистем выполняются следующие действия:

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

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

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

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

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

· Смоделируйте архитектурные образцы (паттерны) и образцы проектирования с помощью коопераций. Образец (pattern) – это типичное решение типичной проблемы в данном контексте.

Помните, что системная архитектура не рождается в ходе единичного акта творения. Напротив, хорошо структурированный процесс применения UML подразумевает последовательное уточнение архитектуры на основе анализа прецедентов, итеративное и инкрементное (вспомните основные положения Рационального Унифицированного Процесса).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2014-01-07