20. Назначение и структура языка uml
Язык UML предназначен для решения следующих задач, возникающих при разработке информационных систем:
предоставить разработчикам легко воспринимаемый и выразительный язык визуального моделирования, специально предназначенный для разработки и документирования моделей сложных систем различного целевого назначения;
снабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей систем в конкретной предметной области;
графическое представление моделей в нотации UML не должно зависеть от конкретных языков программирования и инструментальных средств проектирования;
описание языка UML должно включать в себя семантический базис для понимания общих особенностей объектно-ориентированного анализа и проектирования;
способствовать распространению объектных технологий и стимулировать развитие рынка программных инструментальных средств;
интегрировать
в себя новейшие и наилучшие практики
объектноориентированного анализа и
проектирования.
21. Отношение зависимости, ассоциации, агрегации и композиции между классами.
Ассоциация показывает, что объекты одной сущности (класса) связаны с объектами другой сущности таким образом, что можно перемещаться от объектов одного класса к другому. Является общим случаем композиции и агрегации.
Например, класс Человек и класс Школа имеют ассоциацию, так как человек может учиться в школе. Ассоциации можно присвоить имя «учится в».
Агрегация — это разновидность ассоциации при отношении между целым и его частями. Как тип ассоциации агрегация может быть именованной. Одно отношение агрегации не может включать более двух классов (контейнер и содержимое).
Агрегация встречается, когда один класс является коллекцией или контейнером других. Если контейнер будет уничтожен, то его содержимое — нет. Пример: мебель и комната. Мебель может существовать и вне комнаты.
Композиция — более строгий вариант агрегации. Известна также как агрегация по значению. Композиция имеет жёсткую зависимость времени существования экземпляров класса контейнера и экземпляров содержащихся классов. Если контейнер будет уничтожен, то всё его содержимое будет также уничтожено. Пример: комната и стены. Стены и комната жестко связаны, если разрушить комнату – не будет и стен.
Зависимостью называется отношение использования, определяющее, что изменение в спецификации одной сущности может повлиять на другую сущность, которая ее использует, причем обратное в общем случае не верно.
Ассоциации
Ассоциацией называется структурное отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа. Если между двумя классами определена ассоциация, то можно перемещаться от объектов одного класса к объектам другого. Вполне допустимы случаи, когда оба конца ассоциации относятся к одному и тому же классу. Это означает, что с объектом некоторого класса можно связать другие объекты из того же класса.
Ассоциация, связывающая два класса, называется бинарной. Можно, хотя это редко бывает необходимым, создавать ассоциации, связывающие сразу несколько классов; они называются n-арными. Графически ассоциация изображается в виде линии, соединяющей класс сам с собой или с другими классами. Помимо описанной базовой формы, существует четыре дополнения, применимых к ассоциациям: имя, роль, кратность и ограничения.
Ассоциации может быть присвоено имя, описывающее природу отношения. Чтобы избежать возможных двусмысленностей в понимании имени, достаточно с помощью черного треугольника указать направление, в котором оно должно читаться. Класс, участвующий в ассоциации, играет в ней некоторую роль. По существу, это «лицо», которым класс, находящийся на одной стороне ассоциации, обращен к классу с другой ее стороны. Можете явно обозначить роль, которую класс играет в ассоциации. Например, класс «Человек», играющий роль работника, ассоциирован с классом «Фирма», играющем роль работодателя рис.
Ассоциации отражают структурные отношения между объектами. Часто при моделировании бывает важно указать, сколько объектов может быть связано посредством одного экземпляра ассоциации. Это число называется кратностью роли ассоциации и записывается либо как выражение, значением которого является диапазон значений, либо в явном виде. Обозначая кратность на одном конце ассоциации, разработчик тем самым указывает, что на этом конце именно столько объектов должно соответствовать каждому объекту на противоположном конце. Кратность можно задать следующим образом:
точно один………..……………………….1
ноль или один…………………………………0…1
ноль или более …………..……………………..0…*
один или более …………..……………………..1…*
числовой диапазон от m до n ………..………..m…n
заданное конкретное количество ……………….3
С помощью ограничения «ordered» (упорядоченный) можно указать, упорядочены ли объекты на одном конце ассоциации (если ее кратность больше единицы). Ограничение «ordered» - определяет, что объекты на одном конце ассоциации явным образом упорядочены. Например, в ассоциации User/Password связанные с пользователем (User) пароли (Password) могут храниться в порядке их использования; в этом случае они должны быть помечены ключевым словом «ordered».
Пример:
class Человек
{ private Фирма работодатель; }
class Фирма
{ private Человек работник; }
Агрегирование
Простая ассоциация между двумя классами отражает структурное отношение между равноправными сущностями, когда оба класса находятся на одном концептуальном уровне и ни один не является более важным, чем другой. Но иногда приходится моделировать отношение типа «часть/целое», в котором один из классов имеет более высокий ранг (целое) и состоит из нескольких меньших по рангу (частей). Отношение такого типа называют агрегированием; оно причислено к отношениям типа «имеет» (с учетом того, что объект-целое имеет несколько объектов-частей). Агрегирование является частным случаем ассоциации и изображается в виде простой ассоциации с незакрашенным ромбом со стороны «целого».
Например,
объект фирма состоит из отделов,
которые, в свою очередь состоят из групп
Композиция
Простое агрегирование - чисто концептуальное отношение, оно лишь позволяет отличить «целое» от «части», но не изменяет смысла навигации по ассоциации между целым и его частями и не накладывает никаких ограничений на соотношение времен жизни целого и частей. Однако существует вариация простого агрегирования - композиция, добавляющая к семантике агрегирования новые важные особенности. Композицией называется форма агрегирования с четко выраженным отношением владения, причем время жизни частей и целого совпадают. Части с нефиксированной кратностью могут быть созданы уже после самого композита, но, будучи созданы, живут и умирают вместе с ним. Однако, части могут быть удалены явным образом еще до уничтожения композита. Это означает, что в случае композитного агрегирования объект в любой момент времени может быть частью только одного композита. Например, в оконной системе класс Frame принадлежит только одному классу Window, тогда как при простом агрегировании «часть» может принадлежать одновременно нескольким «целым» (в модели дома объект «стена» может принадлежать нескольким объектам «комната»). Еще одним примером композиции может служить материнская плата и устройства, расположенные на ней рис.
Зависимость
Зависимостью называют отношение использования, согласно которому изменение в спецификации одного элемента может повлиять на другой элемент, его использующий, причем обратное не обязательно. Графически зависимость изображается штриховой линией со стрелкой, направленной от данного элемента на тот, от которого он зависит (рис. 1.12). Чаще всего зависимости применяются при работе с классами, чтобы отразить в сигнатуре операции тот факт, что один класс использует другой в качестве аргумента. Это хороший пример отношений зависимости - изменение одного класса отразится на работе другого, так как используемый класс может теперь представлять
(?) 22. Правила построения диаграмм классов и объектов.
Класс (class) в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами других классов. Графически класс изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на разделы или секции. В этих разделах могут указываться имя класса, атрибуты (переменные) и операции (методы).
Имя класса должно быть уникальным в пределах пакета, который описывается некоторой совокупностью диаграмм классов или одной диаграммой. Оно указывается в первой верхней секции прямоугольника. В дополнение к общему правилу наименования элементов языка UML, имя класса записывается по центру секции имени полужирным шрифтом и должно начинаться с заглавной буквы. Рекомендуется в качестве имен классов использовать существительные, записанные без пробелов. Имена классов образуют словарь предметной области.
Атрибуты класса или свойства записываются во второй сверху секции прямоугольника класса. В языке UML каждому атрибуту класса соответствует отдельная строка текста, которая состоит из квантора видимости атрибута, имени атрибута, его кратности, типа значений атрибута и, возможно, его исходного значения:
<квантор видимости><имя атрибута>[кратность]: <тип атрибута> = <исходное значение>{строка-свойство}
Квантор видимости может принимать одно из трех возможных значений и отображается при помощи соответствующих специальных символов:
«+» обозначает атрибут с областью видимости типа общедоступный (public). Атрибут с этой областью видимости доступен или виден из любого другого класса пакета, в котором определена диаграмма;
«#» обозначает атрибут с областью видимости типа защищенный (protected). Атрибут с этой областью видимости недоступен или невиден для всех классов, за исключением подклассов данного класса;
«-» обозначает атрибут с областью видимости типа закрытый (private). Атрибут с этой областью видимости недоступен или невиден для всех классов без исключения.
Кратность атрибута характеризует общее количество конкретных атрибутов данного типа, входящих в состав отдельного класса.
Исходное значение служит для задания начального значения соответствующего атрибута в момент создания отдельного экземпляра класса.
Операция (operation) - это сервис, предоставляемый каждым экземпляром или объектом класса по требованию своих клиентов, в качестве которых могут выступать другие объекты, в том числе и экземпляры данного класса. Операции класса записываются в третьей сверху секции прямоугольника класса, которую часто называют секцией операций. Совокупность операций характеризует функциональный аспект поведения всех объектов данного класса.
Общий формат записи отдельной операции класса следующий:
<квантор видимости> <имя операции>(список параметров): <выражение типа возвращаемого значения> {строка-свойство}
Графическое обозначение класса и объекта на UML показано на рис. На самом высоком уровне абстракции для моделирования структурных свойств класса (атрибутов) указываются их имена. Обычно этого вполне достаточно, чтобы читатель мог понять общее назначение модели. В дополнение к этому, можно определить видимость, область действия и кратность каждого атрибута. Кроме того, можно задать тип, начальное значение и изменяемость атрибутов. А для обозначения множества логически связанных атрибутов допустимо использовать стереотипы
Видимость атрибутов и методов может быть определена следующими ключевыми словами:
private – собственный атрибут (метод) класса, доступный только классу. Обозначается символом «-»;
protected – защищенный атрибут (метод) класса, доступный классу и потомкам данного. Обозначается символом «#»;
public – открытый атрибут (метод) класса, к которому имеют доступ все классы. Обозначается символом «+»;
package – атрибут (метод) класса, к которому имеют доступ все классы, находящиеся в одном пакете с данным классом. Обозначается символом «~».
Полная форма описания атрибута на UML имеет следующий вид
[Видимость] [/] Имя [:тип] [кратность] [= значение по умолчанию] [{строка свойств}]
Квадратные скобки обозначают необязательность соответствующего элемента. Обратная наклонная черта перед именем атрибута означает, что его значение может быть вычислено на основе других атрибутов. Например, если имеется атрибут «Дата рождения», то значение атрибута «Возраст» может быть вычислено на основе этого атрибута. Кратность атрибута показывает сколько экземпляров атрибута, содержится в каждом объекте. Строка свойств описывает некоторые важные свойства атрибута, например, ReadOnly.
Полная форма описания метода имеет следующий вид:
[Видимость] Имя [(список параметров)] [{строка свойств }].
Список параметров метода разделяется запятыми и представляют данные передаваемые вызывающим методом или объектом. Общее описание параметра имеет следующий вид: [Направление] Имя :тип [кратность] [= значение по умолчанию].
Направление параметра может быть
in- входной,
out-выходной и
inout – входной/выходной.
В качестве строки свойств метода может быть, например, присоединена строка «IsQuery», обозначающая, что операция не изменяет состояние объекта.
У метода класса может быть определена семантика его параллельных вызовов. Возможны следующие значения параллелизма вызова метода:
последовательный (sequential) - вызывающие объекты должны быть скоординированы таким образом, чтобы одновременно осуществлялся только один вызов любой последовательной операции объекта. В случае если вызовы будут идти параллельно, гарантировать семантику и целостность системы невозможно;
контролируемый (guarded) - от параллельных потоков управления может производиться несколько вызовов одного объекта, однако выполняются они не все сразу, а один за, другим. Все прочие вызовы блокируются до того момента, пока не завершится выполнение первой операции. Разработчик должен спроектировать систему таким образом, чтобы в подобной ситуации в ней не возникало взаимоблокировок;
параллельный (concurrent) - от параллельных потоков управления может одновременно осуществляться несколько вызовов одного метода объекта. Все они могут происходить одновременно. Семантика при этом остается корректной. Класс может быть активным, т.е. иметь свой поток или процесс управления. В этом случае изображение класса имеет вид:
Диаграммы классов - это основа объектно-ориентированного моделирования. Они используются для отображения того, что делает система (анализ) и как она будет построена (проектирование). Информация, содержащаяся в диаграммах классов, напрямую отображается в исходный код для реализации приложения, поэтому диаграммы классов всегда создаются для объектно-ориентированных приложений.
Также на диаграммах документируются:
классы – описанием, что они делают;
методы - описанием их логики;
атрибуты - описанием, что они содержат, какой тип имеют, диапазон значений и т.д.
При создании диаграммы классов на языке UML необходимо помнить, что это всего лишь графическое изображение статического вида системы с точки зрения проектирования. Взятая в отрыве от остальных, ни одна диаграмма классов не может и не должна охватывать этот вид целиком. Совокупность диаграмм классов описывает его полностью, но каждая в отдельности диаграмма классов - лишь один из его аспектов. Каждая диаграмма классов должна иметь название, отражающее изображенный аспект моделирования.
Диаграммы объектов позволяют моделировать экземпляры сущностей, которые содержатся в диаграммах классов. Диаграмма объектов отображает множество объектов и отношений между ними в некоторый момент времени.
Диаграммой объектов называется диаграмма, на которой показаны объекты и их отношения в некоторый момент времени. Диаграммы объектов выражают статическую составляющую взаимодействия и состоят из сотрудничающих объектов. Они применяются для визуализации, специфицирования, конструирования и документирования определенных экземпляров в системе, а также отношений между этими экземплярами. Диаграммы объектов особенно полезны при моделировании сложных структур данных.
Каждая диаграмма должна быть законченным представлением соответствующего фрагмента системы и описывать особенности построения или поведения только данного фрагмента
Все сущности на одной диаграмме должны быть одного концептуального уровня. Вся необходимая информация о сущностях должна быть представлена на соответствующей диаграмме, чтобы ее восприятие было целостным.
Диаграммы не должны содержать противоречивой информации. Большинство CASE-средств моделирования на базе UML могут частично проверять непротиворечивость диаграмм. Однако правильность и непротиворечивость разработанных диаграмм полностью возлагается на их автора и не требует обязательной проверки, как это делают компиляторы языков программирования.
Диаграммы не следует перегружать текстовой информацией, так как большое количество текста свидетельствует о недостаточной проработанности модели. Для текстовой информации на диаграмме необходимо использовать термины моделируемой предметной области.
Каждая диаграмма должна быть самодостаточной для правильной интерпретации всех ее элементов. Количество элементов на диаграмме не должно быть большим, а точнее, оно должно подчиняться правилу - 7±2 для обеспечения целостности восприятия диаграммы.
Если диаграмма получается большой, то рекомендуется ее разбить на несколько более мелких диаграмм. Как правило, диаграмма не должна занимать более одной страницы.
Рекомендуется так располагать элементы диаграмм, чтобы обеспечить минимальное количество пересечений линий, связывающих эти элементы. 80 % диаграмм должны использовать лишь основные элементы нотации языка UML и только 20 % – дополнительные и расширенные возможности языка.
Количество типов диаграмм для конкретной модели не фиксируется, оно должно быть достаточным для понимания принципа ее функционирования
(?) 23. Построение управляемых диаграмм классов.
Диаграмма классов показывает фиксированную структуру классов, объектов, атрибутов, операций, ассоциаций, обобщений и агрегаций.
Если выполняется моделирование или разработка большого проекта, то построение одной большой диаграммы классов для проекта в целом приводит к тому, что эта диаграмма становится слишком сложной и трудной для чтения и понимания. В сложных проектах необходимо разделять классы всей системы на несколько диаграмм классов, выделяя в них соответствующий аспект.
Для получения управляемых диаграмм классов приемлемых размеров эффективно использовать следующий простой процесс. Для иллюстрации этого процесса рассмотрим пример компании, которая занимается торговым бизнесом и продает воздушные фильтры и формирует складские запасы, покупая фильтры от своих поставщиков.
Процесс построения управляемых диаграмм классов выглядит следующим образом:
Выполняется построение диаграмм верхнего уровня, содержащих не более 15-20 ключевых классов.
Высокоуровневые диаграммы обеспечивают разработчикам обзор наиболее важных классов, не отвлекаясь на многие другие подробности. Ключевые классы - это группа объектов, которые наиболее важны для соответствующего бизнеса и могут включать в себя такие классы, как клиент, воздушный фильтр и поставщик. Диаграмма верхнего уровня должна быть достаточно простой, без большого количества дополнительных подробностей загромождающих ее
Далее выполняется построение диаграмм второго уровня, в которых один из ключевых классов находится в окружении от 5 до 10 поддерживающих классов и их ассоциаций с ключевым классом.
Выбирается один из ключевых классов из диаграмм верхнего уровня, дополняется атрибутами, операциями, другими поддерживающими классами и ассоциациями, связывающими ключевой класс с этими классами. Иногда, на диаграмму классов второго уровня помещают один или несколько классов верхнего уровня для того чтобы правильно ассоциировать контекст ключевого класса.
Если имеется достаточно сложный агрегат, то необходимо отобразить его составные части на отдельной диаграмме.
Если имеется сложная иерархия наследования необходимо поместить базовый класс и его наследников на отдельную диаграмму классов. Для описанного примера это могут быть различные виды купонов (рис. 1.28). 5. Если какая-либо из диаграмм второго уровня классов оказывается достаточно сложной и содержит более 10 поддерживающих класса, то необходимо построить диаграммы третьего уровня. После выполнения данного процесса, каждая диаграмма будет сфокусирована на конкретной специфике и заинтересованные лица смогут достаточно быстро понять эту специфику
Когда рисуется диаграмма классов, отображающая составляющие ее классы и ассоциации между ними, то она привязывается к некоторому периоду времени. Это кажется странным из-за статической природы этих диаграмм. Но, когда моделируются кратности ассоциаций, необходимо определить период времени, в течение которого они существуют. На диаграмме классов все кратности ассоциаций должны быть привязаны к одинаковому периоду времени.
