Лекция Унифицированный язык моделирования (Unified Modelling Language) Унифицированный язык моделирования uml (Unified Modeling Language) это язык для определения,




Скачать 179.75 Kb.
НазваниеЛекция Унифицированный язык моделирования (Unified Modelling Language) Унифицированный язык моделирования uml (Unified Modeling Language) это язык для определения,
Дата22.12.2012
Размер179.75 Kb.
ТипЛекция

Лекция 3. Унифицированный язык моделирования (Unified Modelling Language)


Унифицированный язык моделирования UML (Unified Modeling Language) – это язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов.

UML является наследником методов объектно-ориентированного анализа и проектирования, появившихся в конце 1980-х и начале 1990-х годов. Создание UML началось в конце 1994 г., с объединения методов Booch и OMT (Object Modeling Technique) под эгидой компании Rational Software. К концу 1995 г. Гради Буч и Джеймс Рамбо создали первую спецификацию Unified Method, версия 0.8. Тогда же в 1995 г. к ним присоединился создатель метода OOSE (Object-Oriented Software Engineering) Ивар Якобсон. UML является унификацией методов Буча, Рамбо и Якобсона а также суммой передового опыта по разработке ПО:






Разработка UML преследовала следующие цели:

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

  • предусмотреть механизмы расширения и специализации языка;

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

  • интегрировать накопленный практический опыт.

UML широко используется в индустрии ПО. Практически все мировые производители CASE-средств поддерживают UML в своих продуктах. В 1997 году Object Management Group (OMG) приняла стандарт UML 1.1. В 2004 году был пройден следующий важный этап – принят стандарт UML версии 2.0. В настоящее время UML проходит процесс стандартизации ISO. Текущая версия UML – 2.1.2.

Основные «строительные блоки» UML:

  • элементы модели (классы, интерфейсы, компоненты, варианты использования и др.);

  • связи (ассоциации, обобщения, зависимости и др.);

  • механизмы расширения (стереотипы, ограничения, примечания, именованные значения);

  • диаграммы.

Состав диаграмм UML 1.х:

  • структурные:

    • диаграммы классов, моделирующие статическую структуру классов системы и связи между классами;

    • диаграммы компонентов, моделирующие иерархии компонентов ПО;

    • диаграммы размещения, моделирующие физическую архитектуру системы;

  • поведенческие:

    • диаграммы вариантов использования, моделирующие бизнес-процессы и требования к ПО;

    • диаграммы взаимодействия (диаграммы последовательности и коммуникационные диаграммы), моделирующие обмен сообщениями между объектами;

    • диаграммы состояний, моделирующие поведение объектов;

    • диаграммы деятельности, моделирующие поведение системы в целом и потоки управления.

В UML 2.0 введены новые типы диаграмм, которых ранее не было: диаграммы обзора взаимодействия, временные диаграммы и диаграммы составных структур.

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

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

Диаграмма вариантов использования является самым общим представлением функциональных требований к системе. Детально функциональные требования описываются в документе, называемом «сценарий варианта использования» или «поток событий». Он подробно документирует процесса взаимодействия действующего лица с системой, реализуемого в рамках варианта использования.

В диаграммах вариантов использования может присутствовать несколько типов связей:

  • связь коммуникации (линия со стрелкой, обозначающая связь между вариантом использования и действующим лицом, по сути такая свяь – путь для передачи запросов или данных);

  • связь включения (пунктирная линия со стрелкой, обозначающая включение многократно используемой функциональности, представленной в виде отдельного варианта использования);

  • связи расширения (пунктирная линия со стрелкой, соединяющая вариант – особый случай – с базовым вариантом использования);

  • связь обобщения (сплошная линия с треугольным концом, используемая в иерархиях наследования действующих лиц или вариантов использования).

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

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

Д
иаграммы последовательности
отражают временную последовательность событий, происходящих в рамках варианта использования. Экземпляры действующих лиц и объекты (экземпляры классов) системы изображаются в верхней части диаграммы. От каждого из них вниз проведена пунктирная вертикальная черта – «линия жизни». Стрелки, соответствующие сообщениям, которые передаются между экземпляром действующего лица и объектом или между объектами, соединяют линии жизни отправителя и получателя сообщения. Порядок отправки сообщений соответствует их размещению на диаграмме сверху вниз. Вдоль линии жизни прямоугольниками отмечены активации – периоды, когда объекты активны, т. е. выполняются связанные с ними процессы.

Каждое сообщение может быть описано в таком формате:

[сторожевое условие] *[повторение] номер : переменная := операция (аргументы)

[сторожевое условие] – сообщение посылается только при выполненном условии, при невыполненном не посылается;

*[повторение] – итерация, которая указывает, что сообщение посылается столько раз, сколько указано внутри [ ];

номер : – порядковый номер сообщения;

переменная := – указание, где будет сохранен результат;

операция (аргументы) – какая операция с какими аргументами будет вызвана.

Любая из частей описания может отсутствовать.





В примере показано взаимодействие при проверке посещаемости. В начале занятия по каждому студенту из списка преподаватель ждет ответа от старосты, присутствует ли студент.

В
UML 2.0 диаграммы последовательности могут содержать блоки разных типов:

  • alt – несколько альтернатив (каждая альтернатива – часть блока помеченная сторожевым условием);

  • opt – необязательный блок (взаимодействие выполняемое при истинности сторожевого условия);

  • par – блок из параллельно выполняемых разделов;

  • loop – цикл (пока истинно условие);

  • region – критический участок;

  • neg – неверное взаимодействие;

  • ref – ссылка на другую диаграмму;

  • sd – блок, включающий диаграмму последовательности целиком.





Вторым видом диаграмм взаимодействия являются коммуникационные диаграммы (в UML 1 их называли кооперативными). Как и диаграммы последовательности, они отображают поток событий варианта использования. На коммуникационных диаграммам внимание сконцентрировано на соединениях между объектами. Из них легче понять связи между объектами, однако, труднее уяснить последовательность событий. Объекты и/или действующие лица, обменивающиеся сообщениями, связываются линиями (соединениями), над которым в виде стрелок обозначаются сообщения. Нумерация сообщений указывает их последовательность во времени.





Р
ефлексивные сообщения (который объект посылает сам себе) изображаются над псевдосоединением – дугой над объектом.

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

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

Д
иаграмма классов определяет классы системы и различного рода связи, которые существуют между ними (ассоциации, агрегации, композиции, зависимости, обобщения, реализации). На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами. Классы изображаются в виде прямоугольников, ассоциации – в виде сплошных линий, направления ассоциаций указываются стрелками, агрегации и композиции – в виде сплошных линий с ромбом на конце, связь обобщения – в виде сплошных линий с треугольником на конце, зависимость – в виде пунктирной линии со стрелкой. Роль, возложенная на класс изображается на диаграммах с помощью стереотипов. Класс может быть помечен как граничный (boundary), если он отвечает за взаимодействие с пользователем или внешней системой. Класс-контроллер реализует бизнес-логику приложения. Класс-сущность отвечает за представление данных. Активные классы (процессы или потоки) на диаграмме выделяют с помощью более толстых, чем у обычных классов границ.


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

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

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

С
обытия бывают разных видов: событие вызова (наступает, когда вызывается операция объекта, например, вклАвтопилот); событие изменения (наступает, когда становится истинным условие, например, when(NumUses=0), всегда начинается со слова when); событие времени (наступает, когда наступает заданный момент времени, или истекает заданный промежуток времени, например after 5min). События, приписанные переходам, вызывают смену состояний. Если событие не отмечено на диаграмме, объект на него не реагирует. Если переходу не приписано событие, то это переход по завершению, который может осуществиться по окончании деятельности внутри события.


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

Когда объект находится в каком-то конкретном состоянии, могут выполняться различные процессы. Они, называются деятельностями состояния и указываются на диаграмме (см. состояние Превышение кредита, деятельность помечена do:). Деятельность состояния – это прерываемое поведение. Оно может выполняться до своего завершения, пока объект находится в данном состоянии, или может быть прервано переходом объекта в другое состояние. Деятельность состояния изображают внутри самого состояния, ей должно предшествовать слово do и двоеточие. Для состояния могут быть указаны входное и выходное действия. Входное действие выполняется всякий раз, когда объект переходит в данное состояние. В отличие от деятельности, входное действие рассматривается как непрерываемое. Входное действие также показывают внутри состояния, ему предшествует слово entry и двоеточие. Выходное действие осуществляется как составная часть любого выхода из состояния. Оно также является непрерываемым. Его изображают внутри состояния, ему предшествует слово exit и двоеточие. Действия, выполняемые в состоянии по наступлению события, помечаются словом именем события, после которого через двоеточие указывается действие. Это так называемые внутренние переходы. При выполнении внутреннего перехода действия по выходу и по входу не выполняются. Если вместо внутреннего перехода создать переход из состояния в само себя, то входное и выходное действия выполняются.

Переходом (transition) называется смена одного состояния объекта на другое. На диаграмме все переходы изображают в виде линий со стрелками. Объект может перейти в то же состояние, в котором он в настоящий момент находится. С переходом можно связать событие, сторожевое условие и действие. Событие вызывает переход из одного состояния в другое. Событие размещают на диаграмме вдоль линии перехода. Сторожевые условия определяют, когда переход может произойти, а когда нет. Их изображают на диаграмме вдоль линии перехода после имени события, заключая в квадратные скобки [ ]. Действие, являющееся частью перехода, изображают вдоль линии перехода после имени события и сторожевого условия, ему предшествует косая черта.

П
ример перехода по событию вызова:

Когда объект находится в состоянии State1, и из очереди событий (а все они считаются упорядоченными и не совпадающими по времени) извлекается событие вызова операции Ev с аргументами Arg, то диаграмма предписывает сделать следующее:

  1. Убрать событие Ev(Arg) из очереди.

  2. Проверить сторожевое условие Guard, если ложно – отменить переход (не делать пункты 3-7).

  3. Прервать деятельность ActDo1 состояния State1, если она не закончилась.

  4. Выполнить действие по выходу ActExit1.

  5. Выполнить действие перехода ActTrans(Arg, Arg1).

  6. Выполнить действие по входу ActEntry2 и назначить текущим состояние State2.

  7. Запустить деятельность состояния ActDo2.

П
ример перехода по событию изменения:

Когда объект находится в состоянии State1, все время проверяется условие Guard. Заметьте, что это не сторожевое условие, это условие, являющееся частью события изменения. Если оно стало истинным, то диаграмма предписывает сделать следующее:

  1. Прервать деятельность ActDo1 состояния State1, если она не закончилась.

  2. Выполнить действие по выходу ActExit1.

  3. Выполнить действие перехода ActTrans(Arg1).

  4. Выполнить действие по входу ActEntry2 и назначить текущим состояние State2.

  5. Запустить деятельность состояния ActDo2.

П
ример перехода по завершению:

Когда объект находится в состоянии State1, и завершается выполнение деятельности ActDo1, диаграмма предписывает сделать следующее:

  1. Проверить сторожевое условие Guard, если ложно – отменить переход (не делать пункты 2-5, заметим, что если потом условие станет истинным, переход уже не произойдет, т. е. условие проверяется единожды, сразу после окончания ActDo1).

  2. Выполнить действие по выходу ActExit1.

  3. Выполнить действие перехода ActTrans(Arg1).

  4. Выполнить действие по входу ActEntry2 и назначить текущим состояние State2.

  5. Запустить деятельность состояния ActDo2.

В
нутри состояния можно отложить событие, для этого используется действие defer, например:

Пусть текущее состояние State1, очередь событий начинается с Ev1, Ev. Событие Ev1 откладывается. По событию Ev срабатывает переход в State2. Событие Ev1 в состоянии State2 не является отложенным, поэтому оно реактивируется (если отложено несколько событий, они активизируются в произвольном порядке). По событию Ev1 срабатывает переход в State1. Без defer событие Ev1 было бы извлечено из очереди и проигнорировано. Заметим, что если бы событие Ev было также отложенным в состоянии State1, то переход по Ev все равно произошел бы, без откладывания. Т. е. откладывать следует лишь те события, которые не приписаны переходам из данного состояния.

Д
ля некоторых состояний (называемых суперсостояниями или композитными состояниями) указывают вложенные подсостояния. Внутри каждого такого состояния могут быть указано начальное и финальные состояния. Также в них может быть указано так называемое историческое состояние, переход в которое означает возврат к предыдущему активному подсостоянию, которое запоминается всякий раз при выходе из суперсостояния. Выход из композитного состояния относится ко всем подсостояниям (в C можно перейти по событию interrupt из A1 и A2).

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

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

П
ереходы могут разделяться (см. ниже переход из S11) и сливаться (см переходы в S23). Переход из S11 в S12 осуществляется как обычно, когда активно S11. Переход в S23 осуществляется, когда одновременно активны S11 и S22.

Д
ля сокращения количества переходов иногда применяют переходные псевдосостояния (черный кружок). На исходящих из него стрелках не могут быть отмечены события. В примере справа заданы 6 переходов. Каждый обозначается 2мя стрелками. Сторожевые условия получаются логическим умножением. То есть, имеем 3 перехода из State0 по событию e2: в State2 со сторожевым условием [b<0 and a<0], в State3 со сторожевым условием [b<0 and a=5], в State4 со сторожевым условием [b<0 and a>7]. И 3 перехода из State1 по событию e1: в State2 со сторожевым условием [b<0 and a<0], в State3 со сторожевым условием [b<0 and a=5], в State4 со сторожевым условием [b<0 and a>7]. Переход не может остановиться в переходном псевдосостоянии. Действия, приписанные частям сложного перехода, выполняются последовательно.

Н
а диаграммах состояний могут применяться псевдосостояния выбора (choice pseudostate). Разница между переходным псевдосостоянием и псевдосостоянием выбора в том, что сторожевые условия на стрелках выходящих из выбора вычисляются после выполнения действий на входящих стрелках (в случае с переходным псевдосостоянием все действия совершаются после вычисления условий). В примере диаграмма состояний описывает автомат ожидающий 1000 нажатий на клавиши без учета нажатий на CAPS LOCK.

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

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

В UML 2 проведена граница между диаграммами состояний, базирующимися на формализме конечных автоматов, и диаграммами деятельности, основанными на сетях Петри. Основным элементом диаграмм деятельности является узел действия. Каждый такой узел представляет собой элементарную единицу работы (это может быть решение некоторой задачи, которую необходимо выполнить вручную или автоматизированным способом, или выполнение метода класса). Узел действия изображается в виде закругленного прямоугольника с текстовым описанием. Диаграмма деятельности может иметь входной узел, вообще говоря, не один, (в UML 1 должен быть ровно один), определяющий начало потока управления. Финальный узел необязателен. На диаграмме может быть несколько финальных узлов. На диаграмме могут присутствовать объекты и потоки объектов, в тех случаях, если объект используется или изменяется в одном из узлов действий. Поток объектов отмечается сплошной или пунктирной стрелкой от узла действия к объектному узлу или от объектного узла к узлу действия, использующего объект. Ребра (сплошные стрелки) между узлами действий показывают потоки управления или потоки объектов. Узел разветвления (узел принятия решения), а также узел объединения потоков изображается ромбом. Если необходимо показать, что две или более ветвей потока выполняются параллельно, используются «линейки синхронизации» – узлы разделения и узлы слияния (на рисунке – жирные горизонтальные линии).

К
ак уже говорилось, диаграммы деятельности интерпретируются в соответствии с формализмом сетей Петри. Начальная точка порождает один курсор управления (или маркер) для каждого исходящего перехода. Если для ребра определено событие, то курсор достигает конца ребра только после наступления такого события. Ограничивающее (сторожевое) условие также определяет, возможно ли перемещение курсора по ребру. При попадании курсора в узел действия происходит ожидание курсоров на всех входящих ребрах и лишь потом запускается единица работы. По завершении выполнения работы генерируются курсоры на всех исходящих ребрах. При попадании в узел разветвления (он имеет один вход и несколько выходов) курсор проходит дальше лишь по тому ребру, для которого выполнено сторожевое условие (вообще говоря, лучше когда оно одно, если несколько – произвольно выбирается единственное для передачи курсора). При попадании в узел объединения курсор из любого входа копируется на выходе (единственном). При попадании в узел разделения курсор дублируется на все выходы одновременно (происходит распараллеливание). Синхронизация обеспечивается узлом слияния, где происходит ожидание курсоров на всех входах и лишь затем выдается курсор на выходе. При попадании курсора в любой финальный узел вся деятельность, описываемая диаграммой, прекращается. Примерно по тем же правилам перемещаются курсоры объектов. Узлы действия могут иметь входные и выходные контакты для приема/выдачи курсоров объектов, изображаемые в виде квадратиков на границе узла. Если входных контактов несколько, действие в узле выполняется лишь тогда, когда на всех их пришли курсоры объектов. Пример:

У
злы разделения и слияния могут синхронизировать потоки управления с потоками объектов. Например:

З
десь прием возвращаемой позиции заказа на склад синхронизируется с изменением состояния объекта Item, который должен перейти в состояние returned (возвращен). Аналогично, возврат денег по возвращенному заказу синхронизируется со сменой состояния объекта Item на available (доступен). Обратите внимание, диаграмма с помощью вертикальных линий – «плавательных дорожек» разделяется на зоны ответственности (заказчик, продажи, бухгалтерия, склад).

Диаграммы деятельности следует использовать в следующих ситуациях:

  • при анализе потоков событий в конкретном варианте использования;

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

Диаграммы компонентов моделируют физический уровень системы. На них изображаются компоненты ПО и связи между ними. На такой диаграмме обычно выделяют два типа компонентов: исполняемые компоненты и библиотеки кода. Каждый класс модели (или подсистема) преобразуется в компонент исходного кода. Между отдельными компонентами изображают зависимости, соответствующие зависимостям на этапе компиляции или выполнения программы. В модели системы может быть несколько диаграмм компонентов, в зависимости от числа подсистем или исполняемых файлов. Каждая подсистема является пакетом компонентов. Диаграммы компонентов применяются теми участниками проекта, кто отвечает за компиляцию и сборку системы.





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

• узел (node) – вычислительный ресурс – процессор (изображаемый с закрашенными боковыми гранями) или устройство (дисковая память, контроллеры различных устройств и т.д.);

• соединение (connection) – канал взаимодействия узлов.

Для узла можно задать выполняющиеся на нем процессы.

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

При моделировании встроенных систем диаграмма размещения отображает связи микропроцессоров и устройств в составе системы.

Т
радиционный средства описания «линейных» языков (т. е. языков состоящих из цепочек символов) – БНФ, регулярные выражения, грамматики – плохо подходят для описания «плоского» языка, каковым является UML. Поэтому для описания UML применяется UML, таковое описание называется метамоделью. Ниже приведен фрагмент метамодели. Подробнее о ней можно узнать из стандарта.

Механизмы расширения UML предназначены для того, чтобы разработчики могли адаптировать язык моделирования к своим конкретным нуждам, не меняя при этом его основу (метамодель). Наличие механизмов расширения принципиально отличает UML от других средств моделирования и позволяет расширять его область применения. К механизмам расширения UML относятся: стереотипы; теги (именованные значения); примечания; ограничения.

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

Стереотипы классов – это механизм, позволяющий разделять классы на категории. Например, основными стереотипами, используемыми в процессе анализа системы, являются: Boundary (граничный класс), Entity (класс-сущность) и Control (управляющий класс).

Помимо упомянутых стереотипов, разработчики ПО могут создавать свои собственные наборы стереотипов, формируя тем самым специализированные подмножества UML (например, для описания бизнес-процессов, Web-приложений, баз данных и т.д.). Такие подмножества (наборы стереотипов) в стандарте языка UML носят название профилей языка.

Теги (именованные значения) – специальные термины, используемые спецификации ограничений и свойств, такие как disjoint, complete, incomplete и др., могут сопровождаться указанием значения свойства, например, author=Вася или location=server.

Примечание – элемент диаграммы для комментария или другой текстовой информации. Примечание может содержать дополнительные сведения об элементах модели (с ними его соединяет пунктирная линия).

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

  • описание инвариантов классов и типов в модели классов;

  • описание пред- и постусловий в операциях и методах;

  • описание ограничивающих условий элементов модели;

  • навигация по структуре модели;

  • спецификация ограничений на операции.



Литература к лекции 3


  1. Г. Буч, И. Якобсон, Дж. Рамбо «UML. Классика CS». 2-е изд. – СПб.: Питер, 2006.

  2. Г. Буч, Дж. Рамбо, И. Якобсон «UML. Руководство пользователя». 2-е изд. – М.: ДМК Пресс, 2007

  3. Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд.: Пер. с англ. – СПб.: Питер, 2006. – Главы 1, 2.

  4. Арлоу Дж., Нейштадт А. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование – СПб. Символ-Плюс, 2007.

  5. Фаулер М. UML. Основы. 3-е издание. Краткое руководство по стандартному языку объектного моделирования.: Пер. с англ. – СПб: Символ-Плюс, 2005.

  6. Леоненков А. Самоучитель UML 2 – СПб.: БХВ-Петербург, 2007.

  7. Шмуллер Дж. Освой самостоятельно UML за 24 часа – М.: Вильямс, 2005.

Ссылки:


http://www.uml.org

http://www.uml2.ru




Похожие:

Лекция Унифицированный язык моделирования (Unified Modelling Language) Унифицированный язык моделирования uml (Unified Modeling Language) это язык для определения, iconУчебный курс «Технологии программирования. Курс на базе Microsoft Solutions Framework (msf)» для подготовки по направлению «Информационные технологии»
Лекции 3 Визуальное моделирование при анализе и проектировании. Основы Unified Modeling Language (uml)
Лекция Унифицированный язык моделирования (Unified Modelling Language) Унифицированный язык моделирования uml (Unified Modeling Language) это язык для определения, iconЛитературный язык и культура речи
Что такое язык. Язык и его функции. Язык как система. Язык и речь. Язык и речевое общение. Общее понятие о культуре речи
Лекция Унифицированный язык моделирования (Unified Modelling Language) Унифицированный язык моделирования uml (Unified Modeling Language) это язык для определения, iconЛекция 18. Инструментальные средства моделирования систем. Основы систематизации языков имитационного моделирования. Моделирование систем и языки программирования.
Язык программирования представляет собой набор символов, распознаваемых ЭВМ и обозначающих операции, которые можно реализовать на...
Лекция Унифицированный язык моделирования (Unified Modelling Language) Унифицированный язык моделирования uml (Unified Modeling Language) это язык для определения, iconI. мир и язык • the world and the language

Лекция Унифицированный язык моделирования (Unified Modelling Language) Унифицированный язык моделирования uml (Unified Modeling Language) это язык для определения, icon1. Понятия «язык», «литературный язык»
На протяжении многих лет учёные не разграничивали понятия «язык» и «речь», подразумевая, что это одно и то же. Действительно язык...
Лекция Унифицированный язык моделирования (Unified Modelling Language) Унифицированный язык моделирования uml (Unified Modeling Language) это язык для определения, iconЯзык программирования Паскаль
Си (C). Язык Pascal лучше других языков подходит для обучения программированию. Это обусловлено тем, что язык был разработан в 70-е...
Лекция Унифицированный язык моделирования (Unified Modelling Language) Унифицированный язык моделирования uml (Unified Modeling Language) это язык для определения, icon«Основы теории управления»
Основной целью данного курса является ознакомление студентов с современными методами моделирования. В частности, изучение методологий...
Лекция Унифицированный язык моделирования (Unified Modelling Language) Унифицированный язык моделирования uml (Unified Modeling Language) это язык для определения, iconРоссийской Федерации Московский государственный институт электронной техники (технический университет) Кафедра вычислительной техники
И эта же компания первой разработала инструментальное объектно-ориентированное case-средство, в котором был реализован язык uml как...
Лекция Унифицированный язык моделирования (Unified Modelling Language) Унифицированный язык моделирования uml (Unified Modeling Language) это язык для определения, iconРеспублики казахстан национальный центр тестирования единое национальное тестирование
Книжка-вопросник содержит тестовые задания по предметам: русский язык, история Казахстана, математика, физика, химия, биология, география,...
Лекция Унифицированный язык моделирования (Unified Modelling Language) Унифицированный язык моделирования uml (Unified Modeling Language) это язык для определения, iconРеспублики казахстан национальный центр тестирования единое национальное тестирование
Книжка-вопросник содержит тестовые задания по предметам: русский язык, история Казахстана, математика, физика, химия, биология, география,...
Разместите кнопку на своём сайте:
Библиотека


База данных защищена авторским правом ©lib.znate.ru 2014
обратиться к администрации
Библиотека
Главная страница