Forráskód Böngészése

диаграмма классов

Евгений Колесников 3 éve
szülő
commit
e68a45d6d0

+ 2 - 4
articles/5_1_1_10_uml_use_case.md

@@ -41,7 +41,7 @@
 
 Содержание *варианта использования* может быть представлено в форме дополнительного пояснительного текста, который раскрывает смысл или семантику действий при выполнении данного *варианта использования*. Такой пояснительный текст получил название текста-сценария или просто сценария. Далее рассматривается один из шаблонов, который может быть рекомендован для написания сценариев вариантов использования.
 
-Отдельный *вариант использования* обозначается на диаграмме эллипсом, внутри которого содержится его краткое имя в форме существительного или глагола с пояснительными словами. Сам текст имени варианта использования должен начинаться с заглавной буквы.
+Отдельный *вариант использования* обозначается на диаграмме эллипсом, внутри которого содержится его краткое имя в форме **отглагольного существительного** с пояснительными словами. Сам **текст** имени варианта использования должен начинаться **с заглавной буквы**.
 
 ![существительное или глагол](../img/10007.png)
 
@@ -59,7 +59,7 @@
 
 Имена *акторов* должны начинаться с заглавной буквы и следовать рекомендациям использования имен для типов и классов модели.
 
-Имя *актора* должно быть достаточно информативным с точки зрения семантики. Для этой цели подходят наименования должностей в компании (например, продавец, кассир, менеджер, президент).
+Имя *актора* должно быть достаточно информативным с точки зрения семантики. Для этой цели подходят наименования должностей в компании (например, Продавец, Кассир, Менеджер, Президент).
 
 *Акторы* используются для моделирования внешних по отношению к проектируемой системе сущностей, которые взаимодействуют с системой. В качестве *акторов* могут выступать другие системы, в том числе подсистемы проектируемой системы или ее отдельные классы. Важно понимать, что каждый *актор* определяет согласованное множество ролей, в которых могут выступать пользователи данной системы в процессе взаимодействия с ней. В каждый момент времени с системой взаимодействует вполне определенный пользователь, при этом он играет или выступает в одной из таких ролей. Наиболее наглядный пример *актора* — конкретный покупатель в магазине автозапчастей.
 
@@ -115,8 +115,6 @@
 
 ![границы проектируемой системы](../img/10013.png)
 
-НИ В КОЕМ СЛУЧАЕ НЕ ИСПОЛЬЗУЙТЕ ЭТУ ДИАГРАММУ КАК ПРИМЕР ДЛЯ ПОДРАЖАНИЯ. Это первый "сырой" вариант, как минимум автосервис нужно выносить в отдельную подсистему и *прецедент* "покупка запчастей" инициируется менеджером автосервиса, а не сам по себе. 
-
 Мы рассмотрели только базовые элементы для диаграммы вариантов использования, на самом деле их больше. Но для нашего уровня обучения этого достаточно.
 
 ## Разбор скринкаста семинара "Системный анализ и проектирование"

+ 35 - 0
articles/uml.md

@@ -0,0 +1,35 @@
+# UML
+
+**Унифицированный язык моделирования** (UML) в настоящий момент является стандартом де-факто при описании (документирования) результатов проектирования и разработки объектно-ориентированных систем. Начало разработки UML было положено в 1994 г. Гради Бучем и Джеймсом Рамбо, работавшим в компании Rational Software. Осенью 1995 г. к ним присоединился Ивар Якобсон и в октябре того же года была выпущена предварительная версия 0.8 унифицированного метода. С этого времени было выпущено несколько версий спецификации UML.
+
+## Нотация UML
+
+Нотация представляет собой графическую интерпретацию семантики для ее визуального представления.
+
+В UML определено три **типа сущностей**:
+
+- структурная – абстракция, являющаяся отражением концептуального или физического объекта;
+- группирующая – элемент, используемый для некоторого смыслового объединения элементов диаграммы;
+- поясняющая (аннотационная) – комментарий к элементу диаграммы.
+
+
+
+**Диаграмма** представляет собой группировку элементов нотации для отображения некоторого аспекта разрабатываемой информационной системы. Диаграммы представляют собой, как правило, связный граф, в котором сущности являются вершинами, а отношения – дугами. В следующей таблице дана краткая характеристика диаграмм UML:
+
+Диаграмма | Назначение
+----------|-----------
+[Вариантов использования](../articles/5_1_1_10_uml_use_case.md)<br/>(use case) | Отображает функции системы, взаимодействие между актерами и функциями
+[Классов](../articles/uml_class.md)<br/>(class) | Отображает набор классов, интерфейсов и отношений между ними
+Пакетов<br/>(package) | Отображает набор пакетов и отношений между ними
+Автоматов<br/>(state machine) | Отображает состояния сущности и переходы между ними в процессе ее жизненного цикла
+[Деятельности](../articles/uml_activity.md)<br/>(activity) | Отображает бизнес-процессы в системе (описание алгоритмов поведения)
+[Последовательности](../articles/uml_sequence.md)<br/>(sequence) | Отображает последовательность передачи сообщений между объектами и актерами
+[Коммуникации](../articles/uml_communication.md)<br/>(communication) | Аналогична диаграмме последовательности, но основной акцент делается на структуру взаимодействия между объектами
+Компонентов<br/>(component) | Отображает компоненты системы (программы, библиотеки, таблицы и т.д.) и связи между ними
+Развертывания<br/>(deployment) | Отображает размещение компонентов по узлам сети, а также ее конфигурацию
+
+<!-- диаграммы состояний,  -->
+
+
+Часть диаграмм после их построения требует развития и уточнения в рамках разработки следующей модели (технологического процесса). Так, например, диаграммы вариантов использования должны быть уточнены при разработке модели анализа. В моделях вариантов использования и анализа разрабатывается и уточняется диаграмма классов анализа, а в модели проектирования – итоговая детализированная диаграмма классов. Как правило, диаграмма классов анализа и диаграмма классов существуют независимо.
+

+ 1 - 0
articles/uml_activity.md

@@ -0,0 +1 @@
+# Диаграмма деятельности (activity)

+ 225 - 0
articles/uml_class.md

@@ -0,0 +1,225 @@
+# Диаграмма классов
+
+<!-- https://intuit.ru/studies/courses/32/32/lecture/1008 -->
+
+Центральное место в методологии ООАП занимает разработка логической модели системы в виде диаграммы классов. **Диаграмма классов** отражает, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов может служить дальнейшим развитием концептуальной модели проектируемой системы
+
+Диаграмма классов (class diagram) — диаграмма языка UML, на которой представлена совокупность декларативных или статических элементов модели, таких как классы с атрибутами и операциями, а также связывающие их отношения.
+
+Диаграмма классов предназначена для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. При этом диаграмма классов может содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры классификаторов, такие как объекты и связи. Когда говорят о данной диаграмме, имеют в виду статическую структурную модель проектируемой системы, т.е. графическое представление таких структурных взаимосвязей логической модели системы, которые не зависят от времени.
+
+## Класс
+
+Класс (class) — абстрактное описание множества однородных объектов, имеющих одинаковые атрибуты, операции и отношения с объектами других классов.
+
+Графически класс в нотации языка UML изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на разделы или секции. В этих секциях могут указываться имя класса, атрибуты и операции класса.
+
+![Варианты графического изображения класса на диаграмме классов](../img/uml_class_01.gif)
+
+На начальных этапах разработки диаграммы отдельные классы могут обозначаться простым прямоугольником, в котором должно быть указано имя соответствующего класса (а). По мере проработки отдельных компонентов диаграммы описание классов дополняется атрибутами (б) и операциями (в). Четвертая секция (г) не обязательна и служит для размещения дополнительной информации справочного характера, например, об исключениях или ограничениях класса, сведения о разработчике или языке реализации. Предполагается, что окончательный вариант диаграммы содержит наиболее полное описание классов, которые состоят из трех или четырех секций.
+
+Даже если секции атрибутов и операций пусты, в обозначении класса они должны быть выделены горизонтальной линией, с тем чтобы отличить класс от других элементов языка UML. 
+
+Примеры графического изображения конкретных классов:
+
+![Примеры графического изображения конкретных классов](../img/uml_class_02.gif)
+
+В первом случае для класса **Окружность** (а) указаны только его атрибуты – точка на координатной плоскости, которая определяет расположение ее центра и длина радиуса окружности. Для класса **Окно** (б) указаны только его операции, при этом секция его атрибутов оставлена пустой. Для класса **Счет** (в) дополнительно изображена четвертая секция, в которой указано требование – реализовать резервное копирование объектов этого класса.
+
+## Имя класса
+
+Имя класса должно быть уникальным в пределах пакета, который может содержать одну или несколько диаграмм классов. Имя указывается в самой верхней секции прямоугольника, поэтому она часто называется секцией имени класса. В дополнение к общему правилу именования элементов языка UML, имя класса записывается по центру секции имени полужирным шрифтом и должно начинаться с заглавной буквы. Рекомендуется в качестве имен классов использовать существительные, записанные по практическим соображениям без пробелов. Необходимо помнить, что имена классов образуют словарь предметной области при ООАП.
+
+В секции имени класса могут также находиться стереотипы или ссылки на стандартные шаблоны, от которых образован данный класс и, соответственно, от которых он наследует атрибуты и операции. В этой секции может также приводиться информация о разработчике данного класса и статус состояния разработки. Здесь также могут записываться и другие общие свойства этого класса, имеющие отношение к другим классам диаграммы или стандартным элементам языка UML.
+
+Класс может иметь или не иметь экземпляров или объектов. В зависимости от этого в языке UML различают конкретные и абстрактные классы.
+
+**Конкретный класс** — класс, на основе которого могут быть непосредственно созданы экземпляры или объекты.
+
+Рассмотренные выше обозначения относятся к конкретным классам. От них следует отличать абстрактные классы.
+
+**Абстрактный класс** (abstract class) — класс, который не имеет экземпляров или объектов.
+
+Для обозначения имени абстрактного класса используется наклонный шрифт (курсив). В языке UML принято общее соглашение о том, что любой текст, относящийся к абстрактному элементу, записывается курсивом. Это имеет принципиальное значение, поскольку является семантическим аспектом описания абстрактных элементов языка UML.
+
+В некоторых случаях необходимо явно указать, к какому пакету относится тот или иной класс. Для этой цели используется специальный символ разделитель – двойное двоеточие - `(::)`. Синтаксис строки имени класса в этом случае будет следующий: `<Имя пакета>::<Имя класса>`. Другими словами, перед именем класса должно быть явно указано имя пакета, к которому его следует отнести. Например, если определен пакет с именем **Банк**, то класс **Счет** в этом банке может быть записан в виде: **Банк::Счет**.
+
+## Атрибуты класса
+
+Атрибут (attribute) — содержательная характеристика класса, описывающая множество значений, которые могут принимать отдельные объекты этого класса.
+
+Атрибут класса служит для представления отдельного свойства или признака, который является общим для всех объектов данного класса. Атрибуты класса записываются во второй сверху секции прямоугольника класса. Эту секцию часто называют секцией атрибутов.
+
+В языке UML принята определенная стандартизация записи атрибутов класса, которая подчиняется некоторым синтаксическим правилам. Каждому атрибуту класса соответствует отдельная строка текста, которая состоит из квантора видимости атрибута, имени атрибута, его кратности, типа значений атрибута и, возможно, его исходного значения. Общий формат записи отдельного атрибута класса следующий:
+
+`<квантор видимости> <имя атрибута> [кратность] :
+<тип атрибута> = <исходное значение> {строка-свойство}`.
+
+* **Видимость** (visibility) — качественная характеристика описания элементов класса, характеризующая потенциальную возможность других объектов модели оказывать влияние на отдельные аспекты поведения данного класса.
+
+    Видимость в языке UML специфицируется с помощью квантора видимости (visibility), который может принимать одно из 4-х возможных значений и отображаться при помощи специальных символов.
+
+    * Символ " **+** " – обозначает атрибут с областью видимости типа общедоступный (**public**). Атрибут с этой областью видимости доступен или виден из любого другого класса пакета, в котором определена диаграмма.
+    * Символ " **#** " – обозначает атрибут с областью видимости типа защищенный ( **protected** ). Атрибут с этой областью видимости недоступен или не виден для всех классов, за исключением подклассов данного класса.
+    * Символ " **-** " – обозначает атрибут с областью видимости типа закрытый (**private**). Атрибут с этой областью видимости недоступен или не виден для всех классов без исключения.
+    * И, наконец, символ " **~** " - обозначает атрибут с областью видимости типа пакетный (**package**). Атрибут с этой областью видимости недоступен или не виден для всех классов за пределами пакета, в котором определен класс -владелец данного атрибута.
+
+    Квантор видимости может быть опущен. Его отсутствие означает, что видимость атрибута не указывается. Эта ситуация отличается от принятых по умолчанию соглашений в традиционных языках программирования, когда отсутствие квантора видимости трактуется как **public** или **private**. Однако вместо условных графических обозначений можно записывать соответствующее ключевое слово: **public**, **protected**, **private**, **package**.
+
+* **Имя атрибута** представляет собой строку текста, которая используется в качестве идентификатора соответствующего атрибута и поэтому должна быть уникальной в пределах данного класса. Имя атрибута - единственный обязательный элемент синтаксического обозначения атрибута, должно начинаться со строчной (малой) буквы и не должно содержать пробелов.
+
+* **Кратность** (multiplicity) — спецификация области значений допустимой мощности, которой могут обладать соответствующие множества.
+
+    Кратность атрибута характеризует общее количество конкретных атрибутов данного типа, входящих в состав отдельного класса. В общем случае кратность записывается в форме строки текста из цифр в квадратных скобках после имени соответствующего атрибута, при этом цифры разделяются двумя точками: [нижняя граница .. верхняя граница], где нижняя и верхняя границы положительные целые числа. Каждая такая пара служит для обозначения отдельного замкнутого интервала целых чисел, у которого нижняя (верхняя) граница равна значению нижней границы (верхней). В качестве верхней границы может использоваться специальный символ " __*__ " (звездочка), который означает произвольное положительное целое число, т.е. неограниченное сверху значение кратности соответствующего атрибута.
+
+    Интервалов кратности для отдельного атрибута может быть несколько. В этом случае их совместное использование соответствует теоретико-множественному объединению соответствующих интервалов. Значения кратности из интервала следуют в монотонно возрастающем порядке без пропуска отдельных чисел, лежащих между нижней и верхней границами. При этом придерживаются следующего правила: соответствующие нижние и верхние границы интервалов включаются в значение кратности.
+
+    Если в качестве кратности указывается единственное число, то кратность атрибута принимается равной данному числу. Если же указывается единственный знак " __*__ ", то это означает, что кратность атрибута может быть произвольным положительным целым числом или нулем. В языке UML кратность широко используется также для задания ролей ассоциаций, составных объектов и значений атрибутов. Если кратность атрибута не указана, то по умолчанию в языке UML принимается ее значение равное [1..1], т.е. в точности 1.
+
+* **Тип атрибута** представляет собой выражение, семантика которого определяется некоторым типом данных, определенным в пакете Типы данных языка UML или самим разработчиком. В нотации UML тип атрибута иногда определяется в зависимости от языка программирования, который предполагается использовать для реализации данной модели. В простейшем случае тип атрибута указывается строкой текста, имеющей осмысленное значение в пределах пакета или модели, к которым относится рассматриваемый класс.
+
+* **Исходное значение** служит для задания начального значения соответствующего атрибута в момент создания отдельного экземпляра класса. Здесь необходимо придерживаться правила принадлежности значения типу конкретного атрибута. Если исходное значение не указано, то значение соответствующего атрибута не определено на момент создания нового экземпляра класса. С другой стороны, конструктор объекта может переопределять исходное значение в процессе выполнения программы, если в этом возникает необходимость.
+
+При задании атрибутов могут быть использованы дополнительные синтаксические конструкции — это подчеркивание строки атрибута, пояснительный текст в фигурных скобках и косая черта перед именем атрибута. Подчеркивание строки атрибута означает, что соответствующий атрибут общий для всех объектов данного класса, т.е. его значение у всех создаваемых объектов одинаковое (аналог ключевого слова static в некоторых языках программирования).
+
+Пояснительный текст в фигурных скобках может означать две различные конструкции. Если в этой строке имеется знак равенства, то вся запись Строка-свойство служит для указания дополнительных свойств атрибута, которые могут характеризовать особенности изменения значений атрибута в ходе выполнения программы. Фигурные скобки как раз и обозначают фиксированное значение соответствующего атрибута для класса в целом, которое должны принимать все вновь создаваемые экземпляры класса без исключения. Это значение принимается за исходное значение атрибута, которое не может быть переопределено в последующем. Отсутствие строки-свойства по умолчанию трактуется так, что значение соответствующего атрибута может быть изменено в программе.
+
+Знак " / " перед именем атрибута указывает на то, что данный атрибут является производным от некоторого другого атрибута этого же класса.
+
+Производный атрибут (derived element) — атрибут класса, значение которого для отдельных объектов может быть вычислено посредством значений других атрибутов этого же объекта.
+
+## Операции класса
+
+Операция (operation) - это сервис, предоставляемый каждым экземпляром или объектом класса по требованию своих клиентов, в качестве которых могут выступать другие объекты, в том числе и экземпляры данного класса .
+
+Операции класса записываются в третьей сверху секции прямоугольника класса, которую часто называют секцией операций. Совокупность операций характеризует функциональный аспект поведения всех объектов данного класса. Запись операций класса в языке UML также стандартизована и подчиняется определенным синтаксическим правилам. При этом каждой операции класса соответствует отдельная строка, которая состоит из квантора видимости операции, имени операции, выражения типа возвращаемого операцией значения и, возможно, строка-свойство данной операции. Общий формат записи отдельной операции класса следующий:
+
+`<квантор видимости> <имя операции>(список параметров):<выражение типа возвращаемого значения>{строка-свойство}`
+
+**Квантор видимости**, как и в случае атрибутов класса, может принимать одно из четырех возможных значений и, соответственно, отображается при помощи специального символа либо ключевого слова. Символ " + " обозначает операцию с областью видимости типа общедоступный ( public ). Символ " # " обозначает операцию с областью видимости типа защищенный ( protected ). Символ " - " используется для обозначения операции с областью видимости типа закрытый ( private ). И, наконец, символ " ~ " используется для обозначения операции с областью видимости типа пакетный ( package ).
+
+Квантор видимости для операции может быть опущен. В этом случае его отсутствие просто означает, что видимость операции не указывается. Вместо условных графических обозначений также можно записывать соответствующее ключевое слово: public, protected, private, package.
+
+**Имя операции** представляет собой строку текста, которая используется в качестве идентификатора соответствующей операции и поэтому должна быть уникальной в пределах данного класса. Имя операции - единственный обязательный элемент синтаксического обозначения операции, должно начинаться со строчной (малой) буквы, и, как правило, записываться без пробелов.
+
+**Список параметров** является перечнем разделенных запятой формальных параметров, каждый из которых, в свою очередь, может быть представлен в следующем виде:
+
+```
+<направление параметра> <имя параметра>:
+ <выражение типа> = 
+     <значение параметра по умолчанию>
+```
+
+*Параметр* (parameter) — спецификация переменной операции, которая может быть изменена, передана или возвращена.
+
+Параметр может включать имя, тип, направление и значение по умолчанию. Направление параметра — есть одно из ключевых слов in, out или inout со значением in по умолчанию, в случае если вид параметра не указывается. Имя параметра есть идентификатор соответствующего формального параметра, при записи которого следуют правилам задания имен атрибутов. Выражение типа является спецификацией типа данных для допустимых значений соответствующего формального параметра. Наконец, значение по умолчанию в общем случае представляет собой некоторое конкретное значение для этого формального параметра.
+
+**Выражение типа возвращаемого значения** также указывает на тип данных значения, которое возвращается объектом после выполнения соответствующей операции. Две точки и выражение типа возвращаемого значения могут быть опущены, если операция не возвращает никакого значения. Для указания нескольких возвращаемых значений данный элемент спецификации операции может быть записан в виде списка отдельных выражений.
+
+Операция с областью действия на весь класс показывается подчеркиванием имени и строки выражения типа. В этом случае под областью действия операции понимаются все объекты этого класса. В этом случае вся строка записи операции подчеркивается.
+
+**Строка-свойство** служит для указания значений свойств, которые могут быть применены к данной операции. Строка-свойство может отсутствовать, если свойства не специфицированы.
+
+Список формальных параметров и тип возвращаемого значения не обязателен. Квантор видимости атрибутов и операций может быть указан в виде специального значка или символа, которые используются для графического представления моделей в инструментальном средстве. Еще раз следует напомнить, что имена операций, так же как атрибутов и параметров, записываются со строчной (малой) буквы, а их типы параметров — с заглавной (большой) буквы. При этом обязательной частью строки записи операции является наличие имени операции и круглых скобок.
+
+# Расширение языка UML для построения моделей программного обеспечения и бизнес-систем
+
+Одним из несомненных достоинств языка UML является наличие механизмов расширения, которые позволяют ввести в рассмотрение дополнительные графические обозначения, ориентированные для решения задач из определенной предметной области. Язык UML содержит два специальных расширения: профиль для процесса разработки программного обеспечения (The UML Profile for Software Development Processes) и профиль для бизнес-моделирования (The UML Profile for Business Modeling).
+
+В рамках первого из них предложено три специальных графических примитива, которые могут быть использованы для уточнения семантики отдельных классов при построении различных диаграмм:
+
+* **Управляющий класс** (control class) — класс, отвечающий за координацию действий других классов. На каждой диаграмме классов должен быть хотя бы один управляющий класс, причем количество посылаемых объектам управляющего класса сообщений мало, по сравнению с числом рассылаемых ими. Управляющий класс отвечает за координацию действий других классов. У каждой диаграммы классов должен быть хотя бы один управляющий класс, контролирующий последовательность выполнения действий этого варианта использования. Как правило, данный класс является активным и инициирует рассылку множества сообщений другим классам модели. Кроме специального обозначения управляющий класс может быть изображен в форме прямоугольника класса со стереотипом `<<control>>`.
+* **Класс -сущность** (entity class) — пассивный класс, информация о котором должна храниться постоянно и не уничтожаться с выключением системы. Класс -сущность содержит информацию, которая должна храниться постоянно и не уничтожается с уничтожением объектов данного класса или прекращением работы моделируемой системы, связанные с выключением системы или завершением программы. Как правило, этот класс соответствует отдельной таблице базы данных. В этом случае его атрибуты являются полями таблицы, а операции – присоединенными или хранимыми процедурами. Этот класс пассивный и лишь принимает сообщения от других классов модели. Класс -сущность может быть изображен также стандартным образом в форме прямоугольника класса со стереотипом `<<entity>>`.
+* **Граничный класс** (boundary class) — класс, который располагается на границе системы с внешней средой и непосредственно взаимодействует с актерами, но является составной частью системы. Граничный класс может быть изображен также стандартным образом в форме прямоугольника класса со стереотипом `<<boundary>>`.
+
+
+![Графическое изображение классов для моделирования программного обеспечения](../img/uml_class_03.gif)
+
+В рамках второго профиля также предложено три специальных графических примитива, которые могут быть использованы для уточнения семантики отдельных классов при построении моделей бизнес-систем:
+
+* **Сотрудник** (business worker) — класс, служащий на диаграмме классов для представления любого сотрудника, который является элементом бизнес-системы и взаимодействует с другими сотрудниками при реализации бизнес-процесса. Этот класс также может быть изображен в форме прямоугольника класса со стереотипом `<<worker>>` или `<<internalWorker>>`.
+* **Сотрудник для связи с окружением** (caseworker) – класс, служащий для представления в бизнес-системе такого сотрудника, который, являясь элементом бизнес-системы, непосредственно взаимодействует с актерами (бизнес-актерами) при реализации бизнес-процесса. Этот класс также может быть изображен в форме прямоугольника класса со стереотипом `<<caseWorker>>`.
+* **Бизнес-сущность** (business entity) — специальный случай класса -сущности, который также не инициирует никаких сообщений. Этот класс служит для сохранения информации о результатах выполнения бизнес-процесса в моделируемой бизнес-системе или организации. Этот класс также может быть изображен в форме прямоугольника класса со стереотипом `<<business entity>>`.
+
+![Графическое изображение классов для моделирования бизнес-систем](../img/uml_class_04.gif)
+
+## Интерфейс
+
+Интерфейс (interface) — именованное множество операций, которые характеризуют поведение отдельного элемента модели.
+
+Интерфейс в контексте языка UML является специальным случаем класса, у которого имеются операции, но отсутствуют атрибуты. Для обозначения интерфейса используется специальный графический символ окружность или стандартный способ – прямоугольник класса со стереотипом `<<interface>>`.
+
+На диаграмме классов интерфейс изображается в виде маленького круга, рядом с которым записывается его имя. В качестве имени может использоваться существительное, которое характеризует соответствующую информацию или сервис, например, " **Датчик температуры** ", " **Форма ввода** ", " **Сирена** ", " **Видеокамера** ". С учетом языка реализации модели имя интерфейса, как и имена других классов, рекомендуется записывать на английском и начинать с заглавной буквы I, например, **ITemperatureSensor**, **IsecureInformation**.
+
+![Примеры графического изображения интерфейсов на диаграммах классов](../img/uml_class_05.gif)
+
+Интерфейсы на диаграмме служат для спецификации таких элементов модели, которые видимы извне, но их внутренняя структура остается скрытой от клиентов. Интерфейсы не могут содержать ни атрибутов, ни состояний, ни направленных ассоциаций. Они содержат только операции без указания особенностей их реализации. Формально интерфейс не только отделяет спецификацию операций системы от их реализации, но и определяет общие границы проектируемой системы. В последующем интерфейс может быть уточнен явным указанием тех операций, которые специфицируют отдельный аспект поведения системы. Графическое изображение интерфейсов в форме окружности могут использоваться и на других типах канонических диаграмм, например, диаграммах компонентов и развертывания.
+
+# Отношения и их графическое изображение на диаграмме классов
+
+Кроме внутреннего устройства классов важную роль при разработке проектируемой системы имеют различные отношения между классами, которые также могут быть изображены на диаграмме классов. Совокупность допустимых типов таких отношений строго фиксирована в языке UML и определяется самой семантикой этих отношений. Базовые отношения, изображаемые на диаграммах классов:
+
+* Отношение ассоциации (association relationship)
+* Отношение обобщения (generalization relationship)
+* Отношение агрегации (aggregation relationship)
+* Отношение композиции (composition relationship)
+
+Каждое из этих отношений имеет собственное графическое представление, которое отражает семантический характер взаимосвязи между объектами соответствующих классов.
+
+## Отношение ассоциации
+
+**Ассоциация** (association) - семантическое отношение между двумя и более классами, которое специфицирует характер связи между соответствующими экземплярами этих классов.
+
+**Отношение ассоциации** соответствует наличию произвольного отношения или взаимосвязи между классами. Данное отношение, как уже отмечалось в лекции 3, обозначается сплошной линией со стрелкой или без нее и с дополнительными символами, которые характеризуют специальные свойства ассоциации. Ассоциации рассматривались при изучении элементов диаграммы вариантов использования, применительно к диаграммам классов, тем не менее, семантика этого типа отношений значительно шире. В качестве дополнительных специальных символов могут использоваться имя ассоциации, символ навигации, а также имена и кратность классов-ролей ассоциации.
+
+**Имя ассоциации** - необязательный элемент ее обозначения. Однако если оно задано, то записывается с заглавной буквы рядом с линией ассоциации. Отдельные классы ассоциации могут играть определенную роль в соответствующем отношении, на что явно указывает имя концевых точек ассоциации на диаграмме.
+
+Наиболее простой случай данного отношения - **бинарная ассоциация** (binary association), которая служит для представления произвольного отношения между двумя классами. Она связывает в точности два различных класса и может быть ненаправленным (симметричным) или направленным отношением. Частный случай бинарной ассоциации - рефлексивная ассоциация, которая связывает класс с самим собой. Ненаправленная бинарная ассоциация изображается линией без стрелки. Для нее на диаграмме может быть указан порядок чтения классов с использованием значка в форме треугольника рядом с именем данной ассоциации.
+
+В качестве простого примера ненаправленной бинарной ассоциации можно рассмотреть отношение между двумя классами - классом **Компания** и классом **Сотрудник**. Они связаны между собой бинарной ассоциацией **Работает**, имя которой указано на рисунке рядом с линией ассоциации. Для данного отношения определен следующий порядок чтения следования классов - сотрудник работает в компании.
+
+![Графическое изображение ненаправленной бинарной ассоциации между классами](../img/uml_class_06.gif)
+
+Направленная бинарная ассоциация изображается сплошной линией с простой стрелкой на одной из ее концевых точек. Направление этой стрелки указывает на то, какой класс является первым, а какой - вторым.
+
+В качестве простого примера направленной бинарной ассоциации можно рассмотреть отношение между двумя классами - классом **Клиент** и классом **Счет**. Они связаны между собой бинарной ассоциацией с именем **Имеет**, для которой определен порядок следования классов. Это означает, что конкретный объект класса **Клиент** всегда должен указываться первым при рассмотрении взаимосвязи с объектом класса **Счет**. Другими словами, эти объекты классов образуют кортеж элементов, например, `<клиент, счет_1, счет_2,…, счет_n>`.
+
+![Графическое изображение направленной бинарной ассоциации между классами](../img/uml_class_07.gif)
+
+Частный случай отношения ассоциации - так называемая исключающая ассоциация (Xor-association). Семантика данной ассоциации указывает на то, что из нескольких потенциально возможных вариантов данной ассоциации в каждый момент времени может использоваться только один. На диаграмме классов исключающая ассоциация изображается пунктирной линией, соединяющей две и более ассоциации, рядом с которой записывается ограничение в форме строки текста в фигурных скобках: {xor}.
+
+![Графическое изображение исключающей ассоциации между тремя классами](../img/uml_class_08.gif)
+
+Тернарная ассоциация связывает отношением три класса. Ассоциация более высокой арности называется n-арной ассоциацией.
+
+**n-арная ассоциация (n-ary association) - ассоциация между тремя и большим числом классов**.
+
+Каждый экземпляр такой ассоциации представляет собой упорядоченный набор (кортеж), содержащий n экземпляров из соответствующих классов. Такая ассоциация связывает отношением более чем три класса, при этом класс может участвовать в ассоциации более чем один раз. Каждый экземпляр n-арной ассоциации представляет собой n-арный кортеж, состоящий из объектов соответствующих классов. В этом контексте бинарная ассоциация является частным случаем n-арной ассоциации, когда значение **n=2**, но имеет собственное обозначение. Бинарная ассоциация - это специальный случай n-арной ассоциации.
+
+Графически n-арная ассоциация обозначается ромбом, от которого ведут линии к символам классов данной ассоциации. Сам же ромб соединяется с символами классов сплошными линиями. Обычно линии проводятся от вершин ромба или от середины его сторон. Имя n-арной ассоциации записывается рядом с ромбом соответствующей ассоциации. Однако порядок классов в n-арной ассоциации, в отличие от порядка множеств в отношении, на диаграмме не фиксируется.
+
+В качестве примера тернарной ассоциации можно рассмотреть отношение между тремя классами: **Сотрудник**, **Компания** и **Проект**. Данная ассоциация указывает на наличие отношения между этими тремя классами, которое может представлять информацию о проектах, реализуемых в компании, и о сотрудниках, участвующих в выполнении отдельных проектов.
+
+![Графическое изображение тернарной ассоциации между тремя классами](../img/uml_class_09.gif)
+
+Класс может быть присоединен к линии ассоциации пунктирной линией. Это означает, что данный класс обеспечивает поддержку свойств соответствующей n-арной ассоциации, а сама n-арная ассоциация имеет атрибуты, операции и/или ассоциации. Другими словами, такая ассоциация является классом с соответствующим обозначением в виде прямоугольника и самостоятельным элементом языка UML - ассоциативным классом (Association Class).
+
+**Класс ассоциация (association class) - модельный элемент, который одновременно является ассоциацией и классом. Ассоциация класс может рассматриваться как ассоциация, которая обладает свойствами класса, или как класс, имеющий также свойства ассоциации**.
+
+Как уже упоминалось, отдельный класс в ассоциации может играть определенную роль в данной ассоциации. Эта роль может быть явно специфицирована на диаграмме классов. С этой целью в языке UML вводится в рассмотрение специальный элемент - концевая точка ассоциации или конец ассоциации (Association End), который графически соответствует точке соединения линии ассоциации с отдельным классом.
+
+**Конец ассоциации (association end) - концевая точка ассоциации, которая связывает ассоциацию с классификатором**.
+
+Конец ассоциации - часть ассоциации, но не класса. Каждая ассоциация может иметь два или больше концов ассоциации. Наиболее важные свойства ассоциации указываются на диаграмме рядом с этими элементами ассоциации и должны перемещаться вместе с ними. Одним из таких дополнительных обозначений является имя роли отдельного класса, входящего в ассоциацию.
+
+**Роль (role) - имеющее имя специфическое поведение некоторой сущности, рассматриваемой в определенном контексте. Роль может быть статической или динамической**.
+
+Имя роли представляет собой строку текста рядом с концом ассоциации для соответствующего класса. Она указывает на специфическую роль, которую играет класс, являющийся концом рассматриваемой ассоциации. Имя роли не обязательный элемент обозначений и может отсутствовать на диаграмме.
+
+Следующий элемент обозначений - **кратность ассоциации**. Кратность относится к концам ассоциации и обозначается в виде интервала целых чисел, аналогично кратности атрибутов и операций классов, но без прямых скобок. Этот интервал записывается рядом с концом соответствующей ассоциации и означает потенциальное число отдельных экземпляров класса, которые могут иметь место, когда остальные экземпляры или объекты классов фиксированы.
+
+Так, для примера кратность " **1** " для класса **Компания** означает, что каждый сотрудник может работать только в одной компании. **Кратность** " **1..*** " для класса **Сотрудник** означает, что в каждой компании могут работать несколько сотрудников, общее число которых заранее неизвестно и ничем не ограничено. Вместо кратности " __1..*__ " нельзя записать только символ " __*__ ", поскольку последний означает кратность " __0..*__ ". Для данного примера это означало бы, что отдельные компании могут совсем не иметь сотрудников в своем штате. Такая кратность приемлема в ситуациях, когда в компании вообще не выполняется никаких проектов.
+
+Имя ассоциации рассматривается в качестве отдельного атрибута у соответствующих классов ассоциаций и может быть указано на диаграмме явным способом в определенной секции прямоугольника класса.
+
+Ассоциация является наиболее общей формой отношения в языке UML. Все другие типы рассматриваемых отношений можно считать частным случаем данного отношения. Однако важность выделения специфических семантических свойств и дополнительных характеристик для других типов отношений обусловливают необходимость их самостоятельного изучения при построении диаграмм классов. Поскольку эти отношения имеют специальные обозначения и относятся к базовым понятиям языка UML, следует перейти к их последовательному рассмотрению.

+ 250 - 0
articles/uml_class_alt.md

@@ -0,0 +1,250 @@
+# Назначение и состав диаграммы классов
+
+>Особенности задания атрибутов, методов и отношений между классами будут иллюстрироваться с учетом специфики (синтаксиса и семантики) языка программирования Java (постепенно буду переводить на C#).
+
+Графически класс отображается в виде прямоугольника, который может быть разделен горизонтальными линиями на секции. В этих секциях указывается имя, атрибуты (свойства) и операции (методы).
+
+![Способы отображения класса](../img/uml_class.png)
+
+Секция атрибутов выделяется горизонтальной линией, даже если у класса отсутствуют атрибуты (характерно для классов-интерфейсов). На следующем рисунке приведен пример определения интерфейса, выполняющего доступ к характеристикам отрезка пути с однородными уровнями допускаемой скорости.
+
+
+![Пример класса без атрибутов (интерфейса)](../img/uml_class_02.png)
+
+С точки зрения структурного подхода, атрибуты – это переменные, а методы – это функции, описанные в теле класса. Они могут быть доступны или не доступны для изменения (атрибуты) или выполнения (методы) внешними объектами.
+
+Обязательным элементом обозначения класса на диаграмме является его имя. Оно должно быть уникальным в пределах пространства имён (namespace). Если класс является абстрактным, то его имя пишется *курсивом*. **Абстрактный класс** – это класс, на основе которого нельзя создать объекты. Такие классы используются в качестве шаблона для дочерних классов при наследовании.
+
+В секции имени класса может быть указан стереотип (например, "entity", "boundary", "interface" и т.п.).
+
+Во второй секции каждому атрибуту соответствует отдельная строка со следующей спецификацией:
+
+`[видимость] [/] имя [: тип [‘[‘кратность‘]‘] [ = исходное значение]] [‘{‘модификаторы’}’]`.
+
+Квадратные скобки означают, что соответствующий элемент спецификации может отсутствовать. Таким образом, при описании обязательным является только имя атрибута.
+
+**Видимость** (англ. visibility) характеризует возможность чтения и модификации значения атрибута объекта описываемого класса, из объектов других классов. Модификация значения возможна лишь при условии, что атрибут не является константой. Видимость отображается с помощью следующих символов:
+
+- "+" – общедоступный атрибут (англ. public) – доступен для чтения и модификации из объектов любого класса;
+
+- "#" – защищенный атрибут (англ. protected) – доступен только объектам описываемого класса и его потомкам при наследовании;
+
+- "–" – закрытый атрибут (англ. private) – доступен только объектам описываемого класса;
+
+- "~" – пакетный атрибут (англ. package) – доступен только объектам классов, входящих в тот же пакет.
+
+**Символ "/"** перед именем атрибута указывает на то, что он является производным (т.е. его значение вычисляется из значений других атрибутов или ассоциаций).
+
+**Имя** (англ. name) атрибута представляет собой строку текста, которая используется для его идентификации. Оно должно быть уникальным в пределах класса.
+
+**Тип** (англ. type) атрибута выбирается исходя из семантики значений, которые должны храниться в атрибуте, и, как правило, возможностей целевого языка программирования по представлению этих значений. Он соответствует одному из стандартных типов, определенных в этом языке (например, String, Boolean, Integer, Color и т. д.) или имени класса, на объект которого в этом атрибуте будет храниться ссылка. Во втором случае класс, имя которого указано в качестве типа, должен быть определен на диаграмме или в модели.
+
+**Кратность** (англ. multiplicity) атрибута характеризует количество значений, которые можно хранить в атрибуте. Если кратность атрибута не указана, то по умолчанию принимается ее значение, равное 1, т. е. атрибут является атомарным. Такой вариант допускает и отсутствие значения в атрибуте (null). Для атрибута, представляющего собой массив, множество, список и т. п., требуется указание кратности, которая записывается после типа в квадратных скобках. Варианты указания кратности, имеющие смысл, могут быть следующие:
+
+- [0..*] или [*] – количество хранимых значений может принимать любое положительное целое число, большее или равное 0. Такой вариант задания кратности характерен для множеств, списков и других атрибутов, допускающих добавление или удаление элементов;
+
+- [0..<число>] – количество хранимых значений, может быть не более указанного числа. Данный вариант применяется при описании массивов фиксированного размера. При этом не обязательно, чтобы все элементы массива имели конкретные значения;
+
+- [0..<число>] [0..<число>] – применяется при описании двумерных массивов. Аналогичным образом можно описать трехмерные, четырехмерные и т.д. массивы.
+
+**Исходное значение** (англ. default value) служит для задания некоторого начального значения атрибута в момент создания отдельного экземпляра класса (объекта).
+
+**Mодификатор** (англ. modifier) описывает особенности реализации атрибута, например:
+
+- {final} / {readOnly} – атрибут является константой, т.е. доступен только для чтения;
+
+- {static} – атрибут при выполнении программы в конкретный момент времени будет иметь одно и то же значение для всех объектов класса;
+
+- {transient} – атрибут и его значение при записи объекта в БД или файл (сериализации объекта) не должны запоминаться;
+
+- {redefines <имя атрибута родительского класса>} – атрибут переопределяет (заменяет) атрибут родительского класса;
+
+- {id} – значение атрибута используется в качестве идентификатора объекта класса;
+
+- {unique} или {nonunique} – значения неатомарного атрибута должны быть уникальны или допускаются повторы значений;
+
+- {ordered} или {unordered} – значения неатомарного атрибута должны быть отсортированы или могут содержаться в произвольном порядке;
+
+- {seq} / {sequence} – значения неатомарного атрибута хранятся упорядочено (к ним можно обращаться по индексу или выполнять перебор в соответствии с порядком их добавления в список/массив/множество) и могут повторяться.
+
+Допускается указывать несколько модификаторов через запятую. Например, {unique, ordered} означает, что элементы массива должны быть уникальны и следовать в строго определенном порядке (например, по возрастанию значений).
+
+В следующей таблице приведены примеры указания спецификации атрибутов и соответствующий им код программы, автоматически генерируемый Case-средством для языка Java.
+
+Спецификация атрибута в UML | Генерируемый код для языка Java
++ name : String	| public String name;
++ pi : double = 3.1415 {final, static} | public final static double pi = 3.1415;
+– coordinateXY : int[][] = {{1, 1}, {2, 4}, {3, 9}} | private int[][] coordinateXY = {{1, 1}, {2, 4},{3, 9}};
+`#` visible : boolean = true | protected boolean visible = true;
+– connect : ConnectDB = null; | private ConnectDB connect = null;
+
+В Java типы, указанные с прописной буквы, называются примитивными (например, double или boolean). Значения атрибутов такого типа непосредственно хранится в объекте. Типы, указанные с заглавной буквы, называются ссылочными (например, String или ConnectDB). В атрибуте такого типа хранится ссылка на объект, созданный на базе соответствующего класса.
+
+В третьей секции указывается перечень методов класса. Можно выделить шесть основных типов методов:
+
+- конструктор – метод, создающий и инициализирующий объект. В Java имя конструктора совпадает с именем класса;
+
+- деструктор – метод, уничтожающий объект. В некоторых языках программирования (в частности в Java) определение деструкторов не требуется, так как очистка памяти от неиспользуемых объектов (сборка мусора) выполняется автоматически;
+
+- модификатор – метод, который изменяет состояние объекта (значения атрибутов). Имена модификаторов начинаются, как правило, со слова set (англ. – установить). Например, установить атрибуту Name новое значение setName(newName : String);
+
+- селектор – метод, который может только считывать значения атрибутов объекта, но не изменяет их. Имена селекторов начинаются, как правило, со слов get (англ. – получить) или is при возврате логического результата. Например, считать значение атрибута Name – getName() или определить видимость на экране элемента графического интерфейса – isVisible();
+
+- итератор – метод, позволяющий организовать доступ к элементам объекта. Например, для объекта, представляющего собой множество Set или список List, это могут быть методы перехода к первому элементу first(), следующему next(), предыдущему previous() и т. п.;
+
+- событие – метод, запускаемый на выполнение автоматически при соблюдении определенных условий.
+
+Тип метода при построении диаграммы классов, как правило, указывается с помощью стереотипа.
+
+Каждому методу соответствует отдельная строка со следующей спецификацией:
+
+`[видимость] имя ([список параметров]) [: тип] [‘{‘свойства’}’]`.
+
+**Видимость и имя** метода задаются по тем же правилам, что и для атрибутов класса.
+
+Список параметров является перечнем разделенных запятой параметров метода, каждый из которых может быть представлен в следующем виде:
+
+`имя : тип [‘[‘кратность‘]‘] [ = значение по умолчанию] [‘{‘строка-свойство’}’]`.
+
+**Имя и кратность** параметра задаются по тем же правилам, что и для атрибутов класса.
+
+**Тип параметра** – тип значений, которые может принимать параметр.
+
+**Значение по умолчанию** – значение, которое передается в метод, если при вызове метода данный параметр не определен.
+
+**Тип метода** – тип результата, возвращаемого методом. Если тип не указан, то метод не возвращает никакого результата (в языках программирования такие методы, как правило, обозначаются модификатором void).
+
+**Свойства** служат для указания специфических свойств метода, например:
+
+- {native} – реализация метода зависит от платформы (операционной системы);
+
+- {abstract} – метод в описываемом классе не имеет тела. Код метода должен быть определен в дочерних классах;
+
+- {sequential} – метод допускает только последовательный вызов. Парралельный вызов операции может вызвать сбой программы;
+
+- {guarded} – метод автоматически блокируется (ждет очереди) до завершения других вызовов (экземпляров) метода;
+
+- {concurrent} – допускается параллельное (одновременное) выполнение нескольких вызовов (экземпляров) метода;
+
+- {query} – метод не меняет состояние системы. Как правило, в языках программирования имена таких методов начинаются на get или is;
+
+- {redefines <имя метода родительского класса>} – метод переопределяет (заменяет) метод родительского класса;
+
+- {unique} или {nonunique} – возвращает множество значений без или с повторами;
+
+- {ordered} или {unordered} – возвращает отсортированное или неотсортированное множество значений;
+
+- {seq} / {sequence} – возвращает упорядоченное множество значений.
+
+В следующей таблице приведены примеры указания спецификации методов и соответствующий им код программы, автоматически генерируемый Case-средством для языка Java.
+
+Спецификация метода в UML | Генерируемый код для языка Java
+"constructor" + TextFieldInt(value : int, length : int, alligment : int, fontField : Font) | public TextFieldInt(int value, int length, int alligment, Font fontField) { }
+`+ saveData()` | public void saveData() {return;}
+`+ isVisible() : boolean` | public boolean isVisible() {return false;}
+`# init(text : String, icon : Icon)` | protected void init(String text, Icon icon) {return;}
+
+В Java методы, не возвращающие результата, обозначаются с помощью модификатора void. Для остальных методов обязательно должен указываться тип возвращаемого результата. Исключение составляют конструкторы, для которых тип результата не указывается, а возвращаемое значение является ссылкой на объект, который был создан при вызове конструктора.
+
+**Отношения**, которые можно устанавливать между классами, и их смысловая нагрузка (семантика) были рассмотрены в подразделе по диаграммам классов анализа. Далее иллюстрируется связь между графическим отображением классов и отношений на диаграммах и исходными текстами программ. Современные Case-средства при разработке классов, как правило, работают в режиме синхронизации диаграмм и исходных текстов. Т. е. если меняется диаграмма классов, то это приводит к автоматической корректировке текста программы и наоборот.
+
+**Отношение ассоциации** означает наличие атрибута, в котором будет храниться ссылка (ссылки) на объект (объекты) класса, в сторону которого направлена стрелка ассоциации.
+
+![Интерпретация ассоциации в тексте программы](../img/uml_class_03.png)
+
+Графический символ класса Class_A преобразуется в строки определения самого класса "public class Class_A" и его конструктора "public Class_A() {}". Аналогично для Class_B. Ассоциация от Class_B в сторону Class_A преобразуется в строку "public Class_A object_A;", описывающую атрибут object_A, в котором будет храниться ссылка на объект класса Class_A. Ввиду отсутствия указания кратности отношения, она по умолчанию принимается равной 1. На следуюшей рисунке приведен пример двунаправленной ассоциации кратностью более 1.
+
+![Интерпретация двунаправленной ассоциации](../img/uml_class_04.png)
+
+Наличие двунаправленной ассоциации или ассоциации без стрелок свидетельствует о наличии в обоих классах атрибутов, содержащих ссылки на объекты. Кратность более 1 подразумевает хранение не одной, а нескольких ссылок. Таким образом, один объект класса Class_A будет связан с несколькими объектами класса Class_B. Ссылки на эти объекты будут храниться в массиве object_B[]. Современные Case-средства позволяют вместо массива указывать другие варианты хранения набора объектов, такие как множества, списки, хешированные таблицы и т.д.
+
+Явное указание отсутствия ссылок на объекты другого класса может задаваться значком "х".
+
+**Отношения агрегации и композиции** являются частными случаями ассоциации. В связи с этим интерпретация этих отношений с точки зрения текста программы совпадает с рассмотренной выше. В "объекте–целом", даже при отсутствии стрелки на стороне "объекта–части", будет храниться ссылка на него.
+
+![Интерпретация композиции (агрегации)](../img/uml_class_05.png)
+
+Отношение обобщения в тексте программы на языке Java показывается ключевым словом "extends" (англ. – расширяет) в дочернем классе.
+
+![Интерпретация обобщения](../img/uml_class_06.png)
+
+**Отношение зависимости** не приводит к автоматической генерации кода программы, но свидетельствует об обращении из объекта зависимого класса к атрибутам, методам или непосредственно к объектам независимого класса. Данное отношение в Case-средстве может автоматически отображаться на диаграмме при обратном проектировании или при синхронизации диаграммы и текста программы.
+
+На следующем рисунке показан условный пример, свидетельствующий о наличии зависимости класса Class_B от класса Class_A. В строке "public obrabotka(Class_A object_A)" используется ссылка на объект класса Class_A. В строке "String name = object_A.name;" выполняется обращение к атрибуту объекта класса Class_A. В строке "int age = object_A.getAge();" выполняется обращение к методу объекта класса Class_A.
+
+
+![Интерпретация зависимости](../img/uml_class_07.png)
+
+При одновременном наличии между классами отношений ассоциации и зависимости на диаграмме отображается ассоциация как более сильная связь.
+
+**Отношение реализации** - дополнительное отношение на диаграмме классов по сравнению с диаграммой классов анализа, которое отображается только между классами и интерфейсами. В тексте на языке Java данное отношение обозначается ключевым словом "implements" (англ. – реализует).
+
+
+![Интерпретация реализации](../img/uml_class_08.png)
+
+Внешний вид отношения подчеркивает тот факт, что оно сочетает в себе особенности обобщения (наследования) и зависимости.
+
+Для отображения интерфейса в UML имеется также другой способ отображения - в виде кружка, который связывается ассоциацией с реализующим его классом. Класс, который использует (англ. use) интерфейс, связывается с ним или ассоциацией с полукругом на конце или зависимостью с соответствующим стереотипом (В Visio такой способ не реализован, поэтому его использовать не будем).
+
+![Связь классов через интерфейс](../img/uml_class_09.png)
+
+На диаграммах разного типа, в том числе и на диаграмме классов, для показа специфики связей, поведения или взаимодействия могут отображаться объекты. Вид объекта аналогичен классу, но при этом его имя должно быть подчеркнуто и, как правило, приведены атрибуты и их значения, вызвавшие необходимость отображения объекта на диаграмме.
+
+
+![Пример объекта](../img/uml_class_10.png)
+
+ 
+
+## Правила и рекомендации по разработке диаграмм классов
+
+При разработке диаграммы следует придерживаться следующих правил и рекомендаций.
+
+1. За основу диаграммы классов при ее разработке берется диаграмма классов анализа.
+
+2. Для классов должны быть определены и специфицированы все атрибуты и методы. Их спецификация, как правило, выполняется с учетом выбранного языка программирования.
+
+3. При определении методов рекомендуется использовать сообщения с ранее разработанных диаграмм последовательности и коммуникации.
+
+4. Детальное проектирование граничных классов, как правило, не требуется. Большинство современных средств разработки поддерживает визуальную разработку интерфейса системы – меню, диалоговых форм, элементов диалоговых окон, панелей инструментов и т. д. В качестве исходных данных для их проектирования служат прототипы пользовательских интерфейсов. В связи с этим при проектировании таких классов основное внимание следует уделять особенностям отображения информации и специфичным операциям, которые возникают при диалоге пользователя с системой. Граничные классы, определяющие интерфейс взаимодействия с другими системами, требуют детального проектирования.
+
+5. Для проектирования классов-сущностей можно применять подходы, используемые при проектировании БД, особенно в том случае, если данные будут храниться в таблицах БД. Если представление данных в БД и классах отличается друг от друга и в качестве хранилища информации будет применяться реляционная база данных, то рекомендуется разработать отдельную диаграмму классов, описывающую состав и структуру БД. Современные Case-средства позволяют разрабатывать такие диаграммы и синхронизировать их с БД.
+
+6. Несмотря на то, что каждому объекту при выполнении программы автоматически назначается уникальный идентификатор, рекомендуется для классов-сущностей явно определять атрибуты, хранящие значения первичного ключа.
+
+7. В отличие от реляционных БД поощряется использование в классах многозначных атрибутов в виде массивов, множеств, списков и т. д.
+
+8. Управляющие классы следует проектировать только в случаях крайней необходимости – управления сложным взаимодействием объектов, реализации сложной бизнес-логики и вычислений, контроля целостности объектов и т. п. В противном случае функциональность этого класса лучше распределить между соответствующими граничными классами и классами-сущностями.
+
+9. Для атрибутов рекомендуется назначать видимость private (закрытый) или protected (защищенный). Если требуется чтение значения такого атрибута из объектов других классов, то следует предусмотреть для него get-метод, а если возможность установки нового значения – set-метод.
+
+![Пример спецификации закрытого атрибута и методов для работы с ним](../img/uml_class_11.png)
+
+10. Для методов видимость public (общедоступный) следует устанавливать только в случае крайней необходимости.
+
+11. Ввиду большого количества классов в системе рекомендуется диаграммы классов разрабатывать отдельно для каждого пакета. По умолчанию Case-средства поддерживают именно такой подход проектирования, хотя и допускают разработку диаграмм, на которых присутствуют классы из разных пакетов.
+
+12. При проектировании диаграммы и отдельных классов рекомендуется пользоваться шаблонами проектирования.
+
+ 
+
+## Пример построения диаграммы классов
+
+На следующем рисунке показан фрагмент диаграммы классов.
+
+![Фрагмент диаграммы классов](../img/uml_class_12.png)
+
+Данная диаграмма отражает структуру классов и связи между ними для пакета ru.iskraPUT.window системы ИСКРА-ПУТЬ. В диаграмму также включен класс InternalWindow из пакета ru.library.window, на базе которого определена половина классов пакета ru.iskraPUT.window. В правом верхнем углу части классов показаны стандартные классы языка Java, на основе которых они определены путем наследования.
+
+Класс PutFame представляет собой главное окно программы, из которого вызываются внутренние диалоговые окна (классы, имя которых начинается на "Window"). Объект данного класса содержит ссылки на объекты, представляющие соответствующие окна, в связи с чем между ними на диаграмме показаны ассоциации.
+
+В Together Architect при выборе класса на диаграмме отображается заголовок каждой секции. Так, для класса WindowSetting показаны:
+
+- Attributes (англ. – атрибуты) – секция атрибутов;
+
+- Operations (англ. – операции) – секция операций;
+
+- Properties (англ. – свойства) – секция свойств. Под свойствами понимаются атрибуты, для которых возможно чтение с помощью общедоступного (public) get-метода. Например, значение закрытого атрибута checkBoxVisibleWord можно считать с помощью открытого метода getCheckBoxVisibleWord();
+
+- Classes (англ. – классы) – секция внутренних классов, т. е. классов, определенных внутри рассматриваемого.
+
+Статичные атрибуты (static) на диаграмме подчеркнуты.

+ 1 - 0
articles/uml_communication.md

@@ -0,0 +1 @@
+# Диаграмма коммуникации (взаимодействия)

+ 2 - 0
articles/uml_sequence.md

@@ -0,0 +1,2 @@
+# Диаграмма последовательности
+

BIN
img/10007.png


BIN
img/10010.png


BIN
img/10011.png


BIN
img/uml_class.png


BIN
img/uml_class_01.gif


BIN
img/uml_class_02.gif


BIN
img/uml_class_02.png


BIN
img/uml_class_03.gif


BIN
img/uml_class_03.png


BIN
img/uml_class_04.gif


BIN
img/uml_class_04.png


BIN
img/uml_class_05.gif


BIN
img/uml_class_05.png


BIN
img/uml_class_06.gif


BIN
img/uml_class_06.png


BIN
img/uml_class_07.gif


BIN
img/uml_class_07.png


BIN
img/uml_class_08.gif


BIN
img/uml_class_08.png


BIN
img/uml_class_09.gif


BIN
img/uml_class_09.png


BIN
img/uml_class_10.png


BIN
img/uml_class_11.png


BIN
img/uml_class_12.png


+ 6 - 8
readme.md

@@ -75,19 +75,17 @@ http://sergeyteplyakov.blogspot.com/2014/01/microsoft-fakes-state-verification.h
 
 1. [Основные понятия и определения ИС.](articles/5_1_1_1_intro2.md)
     
-2. [Анализ предметной области. Основные понятия системного и структурного анализа.](articles/5_1_1_4_analiz.md)
+1. [Анализ предметной области. Основные понятия системного и структурного анализа.](articles/5_1_1_4_analiz.md)
 
-3. [Диаграмма вариантов использования (прецедентов, use case)](articles/5_1_1_10_uml_use_case.md)
+1. [UML](articles/uml.md)
 
-4. [Спецификация вариантов использования (прецедентов)](articles/5_1_1_10_uml_uc_spec.md)
+1. [Диаграмма вариантов использования (прецедентов, use case)](articles/5_1_1_10_uml_use_case.md)
 
-5. [НЕ ДОПИСАНО! Модель проектирования (диаграммы классов, диаграммы деятельности)](articles/uml_mp_dc_dd.md)
+1. [Спецификация вариантов использования (прецедентов)](articles/5_1_1_10_uml_uc_spec.md)
 
-<!-- диаграммы последовательностей,  -->
+1. [Диаграмма классов](./articles/uml_class_alt.md)
 
-<!-- диаграммы взаимодействия,  -->
-
-<!-- диаграммы состояний,  -->
+1. [НЕ ДОПИСАНО! Модель проектирования (диаграммы классов, диаграммы деятельности)](articles/uml_mp_dc_dd.md)
 
 
 ### Контрольные вопросы