Читайте также: |
|
Моделирование упрощается и ведется более эффективно, если придерживаться некоторых соглашений. Работу с UML существенно облегчает последовательное использование общих механизмов, которые мы сейчас перечислим:
· спецификации (specifications);
· дополнения (adornments);
· принятые деления (common divisions);
· механизмы расширения (extensibility mechanisms).
UML является не просто графическим языком, за каждой частью его системы графической нотации состоит спецификация, содержащая текстовое представление соответствующей конструкции языка. Например, пиктограмме класса соответствует спецификация, которая полностью описывает его атрибуты, операции (совместно с полными сигнатурами) и поведение, хотя визуально, на диаграмме пиктограмма часто отражает только малую часть этой совокупности. Более того, в модели может присутствовать другое представление этого класса, отражающее совершенно иные его аспекты, но тем не менее соответствующее спецификации. Таким образом, графическую нотацию UML используют для визуализации системы, а с помощью спецификаций описывают ее детали. Эта двоякость дает с одной стороны, возможность построения моделей инкрементным, то есть пошаговым образом. Сначала нарисовать диаграмму, а потом добавить семантику в спецификацию модели. И наоборот, начать со спецификации (возможно, применив обратное проектирование к реальному проекту), а потом уже рисовать диаграммы.
Спецификации UML определяют семантический задний план, который полностью включает в себя составные части всех моделей системы, и обеспечивает согласование их между собой. В этом разрезе диаграммы UML можно считать визуальными проекциями на это задний план, при этом каждая из них показывает один или несколько значимых аспектов системы.
Практически каждый из элементов UML имеет соответствующее ему уникальное графическое представление, которое дает визуальную картину о самых важных аспектах этого элемента. Нотация класса содержит самые важные его характеристики: имя, атрибуты и операции. Спецификация класса может содержать и другие детали, например, видимость атрибутов и операций, комментарии или указание на то, что класс является абстрактным. Многие из этих деталей можно визуализировать в виде графических или текстовых дополнений к стандартному прямоугольнику, который изображает класс.
При моделировании объектно-ориентированных систем реальность делится с учетом, по крайней мере, двух методов.
Во-первых, существует деление на классы и объекты. Класс - это абстракция, а объект - конкретное воплощение этой абстракции. В связи с этим, практически все конструкции языка характеризуются дихотомией "класс/объект". Например, имеются прецеденты и экземпляры прецедентов, компоненты и экземпляры компонентов, узлы и экземпляры узлов и т. д. В графическом представлении для объекта принято использовать тот же символ, что и для класса, а название подчеркивать.
Во-вторых, существует деление на интерфейс и его реализацию. Интерфейс декларирует обязательства, а реализация представляет конкретное воплощение этих обязательств и обязуется точно следовать объявленной семантике интерфейса. А в связи с этим, почти все конструкции UML характеризуются дихотомией "интерфейс/реализация". Например, прецеденты реализуются кооперациями, а операции - методами.
UML - это стандартный язык разработки моделей программных систем, но ни один замкнутый язык не в состоянии охватить нюансы всех возможных моделей в различных предметных областях. Поэтому UML является открытым языком, то есть допускает контролируемые расширения. Механизмы расширения UML включают:
· стереотипы (stereotype), которые расширяют словарь UML, позволяя на основе существующих блоков языка создавать новые, специфичные для решения конкретной проблемы.;
· помеченные значения (tagged value), которые расширяют свойства основных конструкций UML, позволяя включать новую информацию в спецификацию элемента;
· ограничения (constraints), которые расширяют семантику конструкций UML, позволяя создавать новые и отменять существующие правила.
Ограничение - это семантическое отношение между элементами модели, определяющее всегда истинные условия и теоремы. Основные виды ограничений (такие как ограничение - соединение "или") предопределены в UML, другие определяются пользователем. Для описания определенных пользователем ограничений в конкретном программном обеспечении системы моделирования может использоваться один или более формальных языков. Предопределенным языком для записи ограничений является OCL. При отсутствии поддержки формального языка ограничений, они описываются на естественном языке.
Ограничение изображается как текстовая строка в фигурных скобках ({ }).
Для элементов, чье описание текстовая строка (таких как атрибут и т.п.), строчка ограничений может следовать за строкой элемента (при это не надо забывать о фигурных скобках).
Для списка элементов, описание которого - список текстовых строк (например атрибуты в классе), строчка ограничений представляется как элемент списка. Ограничение применяется ко всем следующим за ним элементам списка, пока не встретится другое ограничение, или до конца списка. Ограничение, присоединенное к индивидуальному элементу списка, не заменяет основное ограничение, но может прибавить или модифицировать индивидуальное ограничение для данного элемента.
Для одиночного графического символа (такого как класс или ассоциативный путь) строка ограничение может быть помещена рядом с символом, а еще лучше рядом с именем символа.
Для двух графических символов (таких как два класса или два ассоциативных пути) строка ограничения показывается как пунктирная стрелка от одного элемента к другому, помеченная строкой ограничения (в фигурных скобках). Направление стрелки выбирается в зависимости от информации содержащейся в ограничении.
Для трех и более графических символов ограничение помещается в символ сноски и присоединяется к каждому символу пунктирной линией. Этот способ описания может также быть использован и для других случаев. Для трех и более путей одного вида (таких как обобщенные или связывающие пути) ограничение может быть присоединено к пунктирной линии пересекающей все пути.
Дата добавления: 2015-07-25; просмотров: 78 | Нарушение авторских прав
<== предыдущая страница | | | следующая страница ==> |
Правила языка UML | | | Системы и подсистемы. Модели и представления |