На этом шаге рассмотрим практическое использование диаграмм в UML.
Язык UML представляет собой подробную спецификацию, но это не означает, что необходимо постоянно использовать все его аспекты. Семантику большей части задач анализа и проектирования можно выразить с помощью подмножества этой системы обозначений. Это подмножество будет выделено в ходе описания системы обозначений. Возможно, что некоторые детали останутся за пределами этого подмножества. Иногда эти элементы языка выражают важные тактические решения. Кроме того, существуют определенные детали инфраструктуры языка UML, привнесенные поставщиками программных средств для облегчения синтеза и анализа систем. Такие внутренние детали позволяют осуществлять интеграцию внешних CASE-средств, поддерживающих эту систему обозначений со средами разработки программного обеспечения, предназначенных для работы с объектно-ориентированными языками.
Следует помнить, что обозначения — это только средство выражения размышлений о поведении и архитектуре системы, а не самоцель. Таким образом, следует пользоваться только самыми необходимыми элементами обозначений. Чересчур подробно описывать решение задачи так же вредно, как ставить слишком жесткие ограничения.
Если система очень велика и связана с интенсивным использованием программного обеспечения, а конструкторы недостаточно опытны или разделены пространством, временем или контрактом, то процесс проектирования необходимо описывать более подробно.
В процессе проектирования модели системы могут иметь разные уровни детализации. Концептуальная модель описывает систему в терминах реальных или предполагаемых сущностей из предметной области, а также отношений между ними. На концептуальном уровне моделирование должно использовать терминологию предметной области и не должно зависеть от технологических проблем.
Логическая модель системы использует понятия, вошедшие в концептуальную модель, а также устанавливает существование и смысл основных абстракций и механизмов, определяющих архитектуру системы и весь проект. Физическая модель системы описывает конкретное программное и аппаратное обеспечение, необходимое для реализации системы. Очевидно, что физическая модель сильно зависит от технологической специфики.
Со временем проект эволюционирует от концептуальной к логической и физической моделям. На каждом из этих этапов используются разные диаграммы. Некоторые диаграммы используются лишь на ранних стадиях проектирования, а другие — на протяжении всего проекта. Кроме того, на использование диаграмм влияет тип создаваемой системы. Например, система для торговли ценными бумагами, предназначенная для биржевого брокера, как правило, описывается большим количеством диаграмм конечных автоматов и диаграмм синхронизации, чем система, моделирующая чековую книжку.
Концептуальная, логическая и физическая модели выражают результаты анализа и проектирования. В совокупности эти разные модели имеют богатую семантику. Они достаточно выразительны, для того чтобы охватить все интересные стратегические и тактические решения, необходимые на этапах анализа системы и формирования ее архитектуры. Кроме того, эти модели достаточно полны, для того чтобы обеспечить реализацию систем на практически любом объектно-ориентированном языке.
Проектирование крупных систем требует применения автоматизированных средств поддержки. Любая система автоматического проектирования использует определенную систему обозначений.
Инструменты проектирования обеспечивают проверку согласованности, ограничений и полноты, а также анализ моделей. Это позволяет разработчику свободно обозревать результаты анализа и проектирования. Например, взглянув на диаграмму компонентов, проектировщик может изучить конкретный механизм или локализовать все классы, связанные с определенным компонентом. Изучая диаграмму последовательностей, описывающую некий сценарий, разработчик может углубиться в иерархию наследования. Если исследуемый сценарий связан с активным объектом, то разработчик может использовать инструменты проектирования для идентификации процессора, через который проходит конкретный поток управления, а затем просмотреть анимацию конечного автомата, связанного с этим процессором. Избавившись от необходимости удерживать в памяти все детали, связанные с анализом и проектированием, разработчик, использующий такие инструменты, может сосредоточиться лишь на творческой работе.
С другой стороны, инструмент проектирования не может подсказать проектировщику, что необходимо изобрести новый класс или упростить структуру какого-то класса. Все это может сделать лишь человек.
Как правило, анализ системы предусматривает изучение совокупности сценариев и диаграмм деятельности (для описания системы с помощью сценариев), диаграмм классов (для выражения ролей и обязанностей агентов, обеспечивающих определенные функции системы), а также диаграмм взаимодействия и/или диаграмм конечных автоматов (для демонстрации поведения агентов, обусловленного последовательностью событий). Аналогично, архитектура системы может состоять из набора диаграмм пакетов, классов, объектов, компонентов и развертывания, а также соответствующих динамических представлений.
Между этими диаграммами существуют связи, позволяющие отслеживать требования в обратном направлении — от реализации к спецификации. Этот процесс начинается с диаграммы развертывания. Ее узел может изображать некий артефакт, представляющий собой компонент, определенный в конкретной диаграмме компонентов. В свою очередь, эта диаграмма компонентов может содержать определения совокупности классов, описанных в диаграмме классов. В заключение, определения отдельных классов ссылаются на некие сценарии и требования, поскольку эти классы в общем прямо отражают словарь предметной области.
Язык UML одинаково хорошо подходит для описания как небольших систем, состоящих из десятков классов, так и крупных систем, содержащих тысячи классов. Не следует создавать диаграммы и откладывать их как нечто не подлежащее изменению. Наоборот, диаграммы должны постоянно уточняться с учетом новых проектных решений и выявленных деталей. Кроме того, язык UML не зависит от каких-либо языков объектно-ориентированного программирования и может использоваться с любым из них.
Диаграммы UML можно использовать двумя основными способами: для специфицирования моделей, на основе которых вы конструируете исполняемую систему (прямое проектирование), и для реконструкции моделей на основе частей существующих исполняемых систем (обратное проектирование). В каждом случае, подобно тому как это происходит при строительстве дома, вам придется выстраивать диаграммы шаг за шагом, добавляя по одному элементу, и итерационно, повторяя цикл "проектируем – строим".
На следующем шаге рассмотрим типичные приемы моделирования различных представлений системы.
