. Целостность (как элементы должны правильно и согласованно соотноситься друг с другом).
. Выполнение (что значит выполнить или имитировать некоторую динамическую модель).
Модели, создаваемые в процессе разработки программных систем, эволюционируют со временем и могут неоднозначно рассматриваться разными участниками проекта в разное время. По этой причине создаются не только хорошо оформленные модели, но и такие, которые:
- содержат скрытые элементы (ряд элементов не показывают, чтобы упростить восприятие).
- неполные (отдельные элементы пропущены).
- несогласованные (целостность модели не гарантируется).
Появление не слишком хорошо оформленных моделей неизбежно в
процессе разработки, пока не все детали системы прояснились в полной мере.
Правила языка UML побуждают - хотя не требуют - в ходе работы над моделью
решать наиболее важные вопросы анализа, проектирования и реализации, в
результате чего модель со временем становится хорошо оформленной.
Строительство упрощается и ведется более эффективно, если придерживаться некоторых соглашений. Следуя определенным архитектурным образцам, можно оформить здание в викторианском или французском стиле. Тот же принцип применим и в отношении UML. Работу с этим языком существенно облегчает последовательное использование общих механизмов, перечисленных ниже:
- спецификации (Specifications);
- дополнения (Adornments);
- принятые деления (Common Pisions);
- механизмы расширения (Extensibility mechanisms).- это не просто графический язык. За каждой частью его системы графической нотации стоит спецификация, содержащая текстовое представление синтаксиса и семантики соответствующего строительного блока. Например, пиктограмме класса соответствует спецификация, полностью описывающая его атрибуты, операции (включая полные сигнатуры) и поведение, хотя визуально пиктограмма порой отражает только малую часть этой совокупности. Более того, может существовать другое представление этого класса, отражающее совершенно иные его аспекты, но тем не менее соответствующее все той же спецификации. С помощью графической нотации UML вы визуализируете систему, с помощью спецификаций UML - описываете ее детали. Таким образом, допустимо строить модель инкрементно, то есть пошаговым образом - сначала нарисовать диаграмму, а потом добавить семантику в спецификацию модели, или наоборот - начать со спецификации (возможно, применив обратное проектирование к существующей системе), а потом на ее основе создавать диаграммы. [3]
Спецификации UML создают семантический задний план, который полностью включает в себя составные части всех моделей системы, согласованные между собой. Таким образом, диаграммы UML можно считать визуальными проекциями на этот задний план, при этом каждая из них раскрывает один из значимых аспектов системы.
Почти каждый из элементов UML имеет соответствующее ему уникальное графическое обозначение, которое дает визуальное представление о самых важных аспектах этого элемента. Например, обозначение класса специально придумано так, чтобы его было легко рисовать, поскольку классы - наиболее употребительный элемент при моделировании объектно-ориентированных систем. Нотация класса содержит самые важные его характеристики: имя, атрибуты и операции.
Спецификация класса может содержать и другие детали, например
видимость атрибутов и операций или указание на то, что класс является
абстрактным. Многие такие детали, можно визуализировать в виде графических или
текстовых дополнений к стандартному прямоугольнику, служащему изображением
класса. Так, на рисунке 16 показан класс, в обозначение которого включены
сведения о том, что он абстрактный и содержит две открытые, одну защищенную и
одну закрытую операцию.
Рисунок 16 – Дополнения
Каждый элемент нотации UML содержит базовый для него символ, к которому можно добавлять разнообразные специфичные для него дополнения.
Принятые деления. При моделировании объектно-ориентированных систем реальность членится с учетом, по крайней мере, двух подходов.
Прежде всего, существует разделение на классы и объекты.
Класс - это абстракция, объект - конкретная материализация этой абстракции. В
языке UML можно моделировать и классы, и объекты, как показано на рисунке 17.
На этом рисунке показан один класс Customer (Клиент) и три объекта: Jan (явно определенный как
объект данного класса), Customer (анонимный объект класса Customer) и Elyse (спецификация которого
относит его к классу Customer, хотя это и не выражено явно).
Рисунок 17 – Классы и объекты
Практически все строительные блоки UML характеризуются дихотомией «класс / объект». Так, имеются прецеденты и экземпляры прецедентов, компоненты и экземпляры компонентов, узлы и экземпляры узлов и т.д. В графическом представлении для объекта принято использовать тот же символ, что и для его класса, а название объекта подчеркивать.
Еще одним вариантом членения является деление на интерфейс и
его реализацию. Интерфейс декларирует контракт, а реализация представляет
конкретное воплощение этого контракта и обязуется точно следовать объявленной
семантике интерфейса. UML позволяет моделировать обе эти категории, интерфейсы
и их реализации, как показано на рисунке18.
Рисунок 18 – Интерфейсы и реализации
Механизмы расширения. UML - это стандартный язык для разработки «чертежей» программного обеспечения, но ни один замкнутый язык не в состоянии охватить нюансы всех возможных моделей в различных предметных областях. Поэтому UML является открытым языком, то есть допускает контролируемые расширения. Механизмы расширения UML включают:
- стереотипы;
- помеченные значения;
- ограничения.
Стереотип (Stereotype) расширяет словарь UML, позволяя на основе
существующих блоков языка создавать новые, специфичные для решения конкретной
проблемы. Например, работая с такими языками программирования, как Java или
C++, часто приходится моделировать исключения (Exceptions) - они являются
обыкновенными классами, хотя и рассматриваются особым образом. Обычно
требуется, чтобы исключения можно было возбуждать и перехватывать, и ничего
больше. Если пометить исключения соответствующим стереотипом, то с ними можно
будет обращаться как с обычными строительными блоками языка. На рисунке 19 это
продемонстрировано на примере класса Overflow.
Рисунок 19 – Механизмы расширения
Помеченное значение (Tagged value) расширяет свойства строительных блоков UML, позволяя включать новую информацию в спецификацию элемента. Скажем, если вы работаете над «коробочным» продуктом и выпускаете много его версий, то зачастую необходимо отслеживать версию и автора какой-нибудь важной абстракции. Ни версия, ни автор не являются первичными концепциями UML, но их можно добавить к любому блоку, такому, например, как класс, задавая для него новые помеченные значения. На рисунке 19 показано, как это можно сделать, на примере класса Event Queue.
Ограничения (Constraints) расширяют семантику строительных блоков UML, позволяя определять новые или изменять существующие правила. Вы можете, например, ограничить класс Event Queue так, чтобы все события добавлялись в очередь по порядку. На рисунке 19 показано, как можно определить ограничение, которое явно постулирует это правило для операции add.
Совместно эти три механизма расширения языка позволяют модифицировать UML в соответствии с потребностями вашего проекта. Кроме того, они дают возможность адаптировать UML к новым технологиям разработки программного обеспечения, например к вероятному появлению более мощных языков распределенного программирования. С помощью механизмов расширения можно создавать новые строительные блоки, модифицировать существующие и даже изменять их семантику. Не забывайте, однако, о чувстве меры. За расширениями важно не потерять главную цель UML - возможность обмена информацией. [1]
В первой главе рассмотрены основные понятия унифицированного
языка моделирования UML, позволяющего рассмотреть систему со всех точек зрения,
имеющих отношение к ее разработке и последующему развертыванию. Сделан вывод,
что несмотря на обилие выразительных возможностей, язык UML прост для понимания
и использования.
Диаграмма в UML - это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями). Диаграммы рисуют для визуализации системы с разных точек зрения. Диаграмма - в некотором смысле одна из проекций системы. Как правило, за исключением наиболее тривиальных случаев, диаграммы дают свернутое представление элементов, из которых составлена система. Один и тот же элемент может присутствовать во всех диаграммах, или только в нескольких (самый распространенный вариант), или не присутствовать ни в одной. Теоретически диаграммы могут содержать любые комбинации сущностей и отношений. На практике, однако, применяется сравнительно небольшое количество типовых комбинаций, соответствующих пяти наиболее употребительным видам, которые составляют архитектуру программной системы. Таким образом, в UML выделяют девять типов диаграмм:
1. Диаграммы классов.
2. Диаграммы объектов.
. Диаграммы прецедентов.
. Диаграммы последовательностей.
. Диаграммы кооперации.
. Диаграммы состояний.
. Диаграммы действий.
. Диаграммы компонентов.
. Диаграммы развертывания.
На диаграмме классов показывают классы, интерфейсы, объекты и кооперации, а также их отношения. При моделировании объектно-ориентированных систем этот тип диаграмм используют чаще всего. Диаграммы классов соответствуют статическому виду системы с точки зрения проектирования. Диаграммы классов, которые включают активные классы, соответствуют статическому виду системы с точки зрения процессов.
На диаграмме объектов представлены объекты и отношения между ними. Они являются статическими «фотографиями» экземпляров сущностей, показанных на диаграммах классов. Диаграммы объектов, как и диаграммы классов, относятся к статическому виду системы с точки зрения проектирования или процессов, но с расчетом на настоящую или макетную реализацию.
На диаграмме прецедентов представлены прецеденты и актеры (частный случай классов), а также отношения между ними. Диаграммы прецедентов относятся к статическому виду системы с точки зрения прецедентов использования. Они особенно важны при организации и моделировании поведения системы.
Диаграммы последовательностей и кооперации являются частными случаями диаграмм взаимодействия. На диаграммах взаимодействия представлены связи между объектами; показаны, в частности, сообщения, которыми объекты могут обмениваться. Диаграммы взаимодействия относятся к динамическому виду системы. При этом диаграммы последовательности отражают временную упорядоченность сообщений, а диаграммы кооперации - структурную организацию обменивающихся сообщениями объектов. Эти диаграммы являются изоморфными, то есть могут быть преобразованы друг в друга. [6]
На диаграммах состояний (State chart diagrams) представлен автомат, включающий в себя состояния, переходы, события и виды действий. Диаграммы состояний относятся к динамическому виду системы; особенно они важны при моделировании поведения интерфейса, класса или кооперации. Они акцентируют внимание на поведении объекта, зависящем от последовательности событий, что очень полезно для моделирования реактивных систем.
Диаграмма деятельности - это частный случай диаграммы состояний; на ней представлены переходы потока управления от одной деятельности к другой внутри системы. Диаграммы деятельности относятся к динамическому виду системы; они наиболее важны при моделировании ее функционирования и отражают поток управления между объектами.
На диаграмме компонентов представлена организация совокупности компонентов и существующие между ними зависимости. Диаграммы компонентов относятся к статическому виду системы с точки зрения реализации. Они могут быть соотнесены с диаграммами классов, так как компонент обычно отображается на один или несколько классов, интерфейсов или коопераций.
На диаграмме развертывания представлена конфигурация обрабатывающих узлов системы и размещенных в них компонентов. Диаграммы развертывания относятся к статическому виду архитектуры системы с точки зрения развертывания. Они связаны с диаграммами компонентов, поскольку в узле обычно размещаются один или несколько компонентов.
Инструментальные средства позволяют генерировать и другие
диаграммы, но девять перечисленных встречаются на практике чаще всего.
На рисунке 20 представлена метамодель понятия «компетентность».
Статическая структура Competence представляет компетентность
специалиста и ее составляющие в виде пакетов, с каждым из которых в свою
очередь связываются статические структуры. Статическая структура на рисунке 3
легко может быть восстановлена в виде UML-модели с помощью, например, Microsoft
Office Visio (при создании файла - пункт контекстного меню Software/UML Model
Diagram).
Рисунок 20 – Метамодель понятия «компетентность»
Понятие компетентность представляется в модели пакетом с именем Competence, отнесенным к стереотипу «system». Содержание самого понятия отображается во вкладке Tagged Values (помеченные значения) c трех позиций.
. С точки зрения базового определения (Tag Documentation Value) компетентность - интегральное свойство личности, характеризующее его стремление и способность (готовность) реализовать свой потенциал (знания, умения, опыт, личностные качества и др.) для успешной деятельности в определенной области.
. С точки зрения результата образования (Outcome of education) смысл понятия компетентность (Tag OutcomeEducation Value) определяется как «реализованная образованность».
. С точки зрения умения (Skill) смысл понятия компетентность (Tag Skill Value) определяется как «проявленные специалистом на практике стремление и способность (готовность) реализовать свой потенциал…».
Интегральность как свойство компетентности отражается на диаграмме рисунка 1 отношениями со своими конкретными проявлениями - потомками.
. Пакет «Готовность к реализации» (Readiness for realization). Tagged Values - Стремление и способность (готовность) реализовать свой потенциал.
. Пакет «Практическая способность к реализации» (Practical capacity to realization). Tagged Values - Проявленная на практике способность реализовать свои знания, умения, опыт для успешной творческой деятельности.
. Пакет «Стремление к совершенствованию» (Tendency to perfecting). Tagged Values - Осознание социальной значимости и личной ответственности за результаты своей деятельности, необходимость ее постоянного совершенствования.
. Пакет «Результат образования» (Outcome of education). Tagged Values - Это сам человек, прошедший обучение в определенной образовательной системе. Это его опыт как совокупность сформированных интеллектуальных, личностных, поведенческих качеств, знаний и умений позволяет ему адекватно действовать на основе этих знаний в любой ситуации.
Содержание перечисленных пакетов должно быть основано на анализе практической деятельности выпускников колледжа составляющей еще один пакет этой диаграммы - Профессиональная деятельность (Professional work). Моделирование компетенций.