UML-схему классов можно использовать в разных целях.

Схема позволяет сконцентрироваться на логических аспектах классов, а не их реализации.

UML-схему классов можно использовать в разных целях.

· Для предоставления описания типов (понятие типа!!??), используемых в системе и передаваемых между компонентами (понятие компонента !!!???), независимо от реализации.

Например, тип "Заказ еды" может реализовываться:

в бизнес-слое в коде .NET,

в интерфейсах между компонентами в XML,

в базе данных в SQL и

в пользовательском интерфейсе в HTML.

Несмотря на то что подробности этих реализаций различаются, отношение между типом "Заказ еды" и другими типами, такими как "Меню" и "Оплата", сохраняется. UML-схема классов позволяет обсуждать эти отношения отдельно от реализаций.

· Для более точного определения набора терминов, используемых для обмена сведениями между приложением и его пользователями, а также в описаниях потребностей пользователей. См. раздел Моделирование требований пользователей.

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

Реальная сущность связывается со многими терминами (именами подпроцессов), и, следовательно, определяться через их реализацию.

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

В этом описании можно найти такие термины как "Меню", "Заказ", "Еда", "Цена", "Оплата" и т. д.

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

http://e-educ.ru/bd15.html

UML — это язык визуализации. Написание моделей на UML преследует одну простую цель — облегчение процесса передачи информации о системе. За каждым символом UML стоит строго определенная семантика, что позволяет избегать ошибок интерпретации (ответы на вопросы типа «а что имел в виду разработчик Х, когда он описал иерархию классов Y…» и т.п. будут достаточно прозрачны).

http://ooad.asf.ru/students/lectures_risp/lec021.aspx

В UML имеется четыре типа сущностей:

• структурные;
• поведенческие;
• группирующие;
• аннотационные.

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

Класс (class) - это описание совокупности объектов с общими атрибутами, операциями отношениями и семантикой. Графически класс изображается в виде прямоугольника, в котором записаны его имя, атрибуты и операции, например как это показано на рисунке:

ClassName

-PrivateAttribute : char #ProtectedAttribute +PublicAttribute

+Operation1(in S : String) +Operation2()

Рис. Пиктограмма класса

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

Рис. Пиктограмма интерфейса

Диаграммы объектов (object diagram), на которых представляются объекты и отношения между ними. Это статические снимки экземпляров сущностей, показанных на диаграммах классов. Диаграммы объектов, как и диаграммы классов, относятся к статическому виду системы сточки зрения проектирования или процессов, но с расчетом на настоящую или макетную реализацию.

http://www.e-reading.club/book.php?book=33640

1. 5.2. Отношения между классами

2. Отношение зависимости

3. Отношение ассоциации

4. Отношение агрегации

5. Отношение композиции

6. Отношение обобщения

Ещё раз об интерфейсах:

5.3. Интерфейсы .

Интерфейсы являются элементами диаграммы вариантов использования и были рассмотрены в главе 4. Однако при построении диаграммы классов отдельные интерфейсы могут уточняться и в этом случае для их изображения используется специальный графический символ – прямоугольник класса с ключевым словом или стереотипом «interface» (рис. 5.17). При этом секция атрибутов у прямоугольника отсутствует, а указывается только секция операций.

Интерфейсы

Интерфейс (interface) служит для спецификации параметров модели, которые видимы извне без указания их внутренней структуры.

В языке UML интерфейс является классификатором и характеризует только ограниченную часть поведения моделируемой сущности.

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

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

На диаграмме вариантов использования интерфейс изображается в виде маленького круга, рядом с которым записывается его имя . В качестве имени может быть существительное, которое характеризует соответствующую информацию или сервис (например, «датчик», «сирена», «видеокамера»), но чаще строка текста (например, «запрос к базе данных», «форма ввода», «устройство подачи звукового сигнала»). Если имя записывается на английском, то оно должно начинаться с заглавной буквы I, например, ISecurelnformation, ISensor (рис. 4.3, б).

Рис. Интерфейсы. Графическое изображение интерфейсов на диаграммах вариантов использования

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

Рис. 4.4. Графическое изображение взаимосвязей интерфейсов с вариантами использования

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

В этом случае он изображается в форме прямоугольника класса с ключевым словом «interface» в секции имени, с пустой секцией атрибутов и с непустой секцией операций.

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

Важность интерфейсов заключается в том, что они определяют стыковочные узлы в проектируемой системе, что совершенно необходимо для организации коллективной работы над проектом. Более того, спецификация интерфейсов способствует «безболезненной» модификации уже существующей системы при переходе на новые технологические решения. В этом случае изменению подвергается только реализация операций, но никак не функциональность самой системы. А это обеспечивает совместимость последующих версий программ с первоначальными при спиральной технологии разработки программных систем.

http://book.uml3.ru/sec_3_2 Прекрасное пособие!!!