1 для чего используется язык uml

3.1. Назначение языка UML

3.1. Назначение языка UML

Язык UML предназначен для решения следующих задач:

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

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

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

Отсюда вытекает важное следствие – для адекватного понимания базовых конструкций языка UML важно не только владеть некоторыми навыками объектно-ориентированного программирования, но и хорошо представлять себе общую проблематику процесса разработки моделей систем. Именно интеграция этих представлений образует новую парадигму ООАП, практическим следствием и центральным стержнем которой является язык UML.

2. Снабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей систем в конкретной предметной области.

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

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

Язык UML допускает также специализацию базовых понятий. Речь идет о том, что в конкретных7 приложениях пользователи должны уметь дополнять имеющиеся базовые понятия новыми характеристиками или свойствами, которые не противоречат семантике этих понятий в языке UML.

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

Речь идет о том, что ни одна из конструкций языка UML не должна зависеть от особенностей ее реализации в известных языках программирования. То есть, хотя отдельные понятия языка UML и связаны с последними очень тесно, их жесткая интерпретация в форме каких бы то ни было конструкций программирования не может быть признана корректной. Другими словами, разработчики из OMG считают необходимым свойством языка UML его контекстно-программную независимость.

С другой стороны, язык UML должен обладать потенциальной возможностью реализации своих конструкций на том или ином языке программирования. Конечно, в первую очередь имеются в виду языки, поддерживающие концепцию ООП, такие как C++, Java, Object Pascal. Именно это свойство языка UML делает его современным средством решения задач моделирования сложных систем. В то же время, предполагается, что для программной поддержки конструкций языка UML могут быть разработаны специальные инструментальные CASE-средства. Наличие последних имеет принципиальное значение для широкого распространения и использования языка UML.

4. Описание языка UML должно включать в себя семантический базис для понимания общих особенностей ООАП.

Говоря об этой особенности, имеют в виду самодостаточность языка UML для понимания не только его базовых конструкций, но что не менее важно – понимания общих принципов ООАП. В этой связи необходимо отметить, что поскольку язык UML не является языком программирования, а служит средством для решения задач объектно-ориентированного моделирования систем, описание языка UML должно по возможности включать в себя все необходимые понятия для ООАП. Без этого свойства язык UML может оказаться бесполезным и невостребованным большинством пользователей, которые не знакомы с проблематикой ООАП сложных систем.

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

Читайте также:  Дню русского языка и пушкинскому дню россии

5. Поощрять развитие рынка объектных инструментальных средств.

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

6. Способствовать распространению объектных технологий и соответствующих понятий ООАП.

Эта задача тесно связана с предыдущей и имеет с ней много общего. Если исключить из рассмотрения рекламные заявления разработчиков об исключительной гибкости и мощности языка UML, а попытаться составить объективную картину возможностей этого языка, то можно прийти к следующему заключению. Следует признать, что усилия.достаточно большой группы разработчиков были направлены на интеграцию в рамках языка UML многих известных техник визуального моделирования, которые успешно зарекомендовали себя на практике (см. главу 2). Хотя это привело к усложнению языка UML по сравнению с известными нотациями структурного системного анализа, платой за сложность являются действительно высокая гибкость и изобразительные возможности уже первых версий языка UML. В свою очередь, использование языка UML для решения всевозможных практических задач будет только способствовать его дальнейшему совершенствованию, а значит и дальнейшему развитию объектных технологий и практики ООАП.

7. Интегрировать в себя новейшие и наилучшие достижения практики ООАП.

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

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

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

Данный текст является ознакомительным фрагментом.

Продолжение на ЛитРес

Читайте также

Назначение книги

Назначение книги Данная книга не является заменой справочников и различных руководств по операционной системе UNIX. Более того, сведения, представленные в книге, подчас трудно найти в документации, поставляемой с операционной системой. Эти издания насыщены практическими

12.2 Назначение DNS

12.2 Назначение DNS Система имен доменов (Domain Name System — DNS) обеспечивает более эффективный способ согласования имен и адресов Интернета. База данных DNS обеспечивает автоматизированную службу преобразования имен в адреса. Эта система успешно работает, и многие организации,

15.1.1 Назначение NFS

15.1.1 Назначение NFS Компания Sun разработала сетевую файловую систему (Network File System — NFS) для поддержки разделения ресурсов служб рабочих станций Unix в локальных сетях. NFS делает удаленный каталог с файлами частью локальной структуры каталогов — конечные пользователи и

15.6.1 Назначение Portmapper

15.6.1 Назначение Portmapper Архитектура RPC предоставляет метод для динамического обнаружения присвоенного службе порта. На каждом серверном хосте специальная программа RPC работает как хранилище данных о других программах RPC этого сервера. Такая программа называется portmapper

15.7.1 Назначение rpcbind

15.7.1 Назначение rpcbind Программа rpcbind основана на тех же принципах, что и portmapper. При инициализации программы RPC ей выделяется один или несколько динамически назначенных адресов для транспорта. Программа регистрирует полученные адреса в rpcbind, через которую они становятся

22.8.1 Назначение маршрутизаторов

22.8.1 Назначение маршрутизаторов Каждый маршрутизатор предоставляет хостам следующие сведения:? Свой адрес? Список всех адресных префиксов, используемых связью? Конкретный префикс, который должен использоваться хостом для создания своего адреса? Предполагаемое

Драйвера и их назначение

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

Назначение

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

Назначение

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

Назначение материалов

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

Читайте также:  Как можно на клавиатуре менять язык

Назначение материалов

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

Назначение программы

Назначение программы Основное назначение Sound Forge 9.0 – редактирование цифрового звука. С помощью этой программы можно обрабатывать фонограммы или звуковые дорожки фильмов практически всеми существующими способами.• Первоначальная запись и оцифровка звука с различных

Назначение материалов

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

Источник

1 для чего используется язык uml

11. ОСНОВЫ УНИФИЦИРОВАННОГО ЯЗЫКА МОДЕЛИРОВАНИЯ

11.1. Структура Унифицированного языка моделирования

Унифицированный язык моделирования (UML) в настоящий момент является стандартом де-факто при описании (документирования) результатов проектирования и разработки объектно-ориентированных систем. Начало разработки UML было положено в 1994 г. Гради Бучем и Джеймсом Рамбо, работавшим в компании Rational Software. Осенью 1995 г. к ним присоединился Ивар Якобсон и в октябре того же года была выпущена предварительная версия 0.8 унифицированного метода (англ. Unified Method). С этого времени было выпущено несколько версий спецификации UML, две из которых носят статус международного стандарта:

— UML 1.4.2 – ISO/IEC 19501:2005. «Информационные технологии. Открытая распределительная обработка. Унифицированный язык моделирования (UML). Версия 1.4.2» (англ. «Information technology. Open distributed processing. Unified modeling language (UML). Version 1.4.2»);

Последнюю официальную спецификацию языка можно найти на сайте www.omg.org.

Общая структура UML показана на следующем рисунке [25].

Рис. 11.1. Структура UML

11.2. Семантика и синтаксис UML

Семантика – раздел языкознания, изучающий значение единиц языка, прежде всего его слов и словосочетаний [35].

Синтаксис – способы соединения слов и их форм в словосочетания и предложения, соединения предложений в сложные предложения, способы создания высказываний как части текста [35].

Таким образом, применительно к UML, семантика и синтаксис определяют стиль изложения (построения моделей), который объединяет естественный и формальный языки для представления базовых понятий (элементов модели) и механизмов их расширения.

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

В UML определено три типа сущностей:

— структурная – абстракция, являющаяся отражением концептуального или физического объекта;

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

— поясняющая (аннотационная) – комментарий к элементу диаграммы.

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

Таблица 11.1. Сущности

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

Инженер
службы пути
Внешняя по отношению к системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач. Таким образом актер – это внешний источник или приемник информации
Вариант использования
(use case)
Описание выполняемых системой действий, которая приводит к значимому для актера результату
Состояние
(state)
Описание момента в ходе жизни сущности, когда она удовлетворяет некоторому условию, выполняет некоторую деятельность или ждет наступления некоторого события
Кооперация
(collaboration)
Описание совокупности экземпляров актеров, объектов и их взаимодействия в процессе решения некоторой задачи
Компонент
(component)
Физическая часть системы (файл), в том числе модули системы, обеспечивающие реализацию согласованного набора интерфейсов
Интерфейс
(interface)

iРасчет
Совокупность операций, определяющая сервис (набор услуг), предоставляемый классом или компонентом
Узел
(node)
Физическая часть системы (компьютер, принтер и т. д.), предоставляющая ресурсы для решения задачи
Группирующая Пакет
(package)
Общий механизм группировки элементов.
В отличие от компонента, пакет – чисто концептуальное (абстрактное) понятие. Частными случаями пакета являются система и модель
Фрагмент
(fragment)
Область специфического взаимодействия экземпляров актеров и объектов.
Любая диаграмма в UML также является фрагментом – фрагментом (частью) проекта.
Раздел деятельности
(activity partition)
Группа операций (зона ответственности), выполняемых одной сущностью (актером, объектом, компонентом, узлом и т.д.)
Прерываемый регион
(interruptible activity region)
Группа операций, обычная последовательность выполнения которых может прервана в результате наступления нестандартной ситуации
Поясняющая Примечание
(comment)
Комментарий к элементу. Присоединяется к комментируемому элементу штриховой линией

В некоторых источниках, в частности [24, 29], выделяют также поведенческие сущности взаимодействия и конечные автоматы, но с логической точки зрения их следует отнести к диаграммам.

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

Таблица 11.2. Декомпозируемые сущности

Наименование Обозначение Диаграмма
Скрытое составное состояние Диаграмма автоматов
Скрытый фрагмент взаимодействия Диаграмма последовательности
Деятельность Диаграмма деятельности

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

Таблица 11.3. Отношения

Наименование Обозначение Определение (семантика)
Ассоциация (association) Отношение, описывающее значимую связь между двумя и более сущностями. Наиболее общий вид отношения
Агрегация (aggregation) Подвид ассоциации, описывающей связь «часть»–»целое», в котором «часть» может существовать отдельно от «целого». Ромб указывается со стороны «целого». Отношение указывается только между сущностями одного типа
Композиция (composition) Подвид агрегации, в которой «части» не могут существовать отдельно от «целого». Как правило, «части» создаются и уничтожаются одновременно с «целым»
Зависимость (dependency) Отношение между двумя сущностями, в котором изменение в одной сущности (независимой) может влиять на состояние или поведение другой сущности (зависимой). Со стороны стрелки указывается независимая сущность
Обобщение (generalization) Отношение между обобщенной сущностью (предком, родителем) и специализированной сущностью (потомком, дочкой). Треугольник указывается со стороны родителя. Отношение указывается только между сущностями одного типа
Реализация (realization) Отношение между сущностями, где одна сущность определяет действие, которое другая сущность обязуется выполнить. Отношения используются в двух случаях: между интерфейсами и классами (или компонентами), между вариантами использования и кооперациями. Со стороны стрелки указывается сущность, определяющее действие (интерфейс или вариант использования)
Читайте также:  Желтый налет на языке и жжение языка причины

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

— * – любое количество экземпляров, в том числе и ни одного;

— целое неотрицательное число – кратность строго фиксирована и равна указанному числу (например: 1, 2 или 5);

— перечисление целых неотрицательных чисел и диапазонов через запятую (например: 1, 3..5, 10, 15..*).

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

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

Таблица 11.4. Механизмы расширения

Наименование Обозначение Определение (семантика)
Стереотип
(stereotype)
« » Обозначение, уточняющее семантику элемента нотации (например: зависимость со стереотипом «include» рассматривается, как отношение включения, а класс со стереотипом «boundary» – граничный класс)
Сторожевое условие
(guard condition)
[ ] Логическое условие (например: [A > B] или [идентификация выполнена])
Ограничение
(constraint)
Правило, ограничивающее семантику элемента модели (например, <время выполнения менее 10 мс>)
Помеченное значение
(tagged value)
Новое или уточняющее свойство элемента нотации (например: )

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

a) стандартное обозначение б) стандартное обозначение
с текстовым стереотипом
в) графический стереотип

Рис. 11.2. Примеры стандартного и стереотипного отображения класса

Диаграмма представляет собой группировку элементов нотации для отображения некоторого аспекта разрабатываемой информационной системы. Диаграммы представляют собой, как правило, связный граф, в котором сущности являются вершинами, а отношения – дугами. В следующей таблице дана краткая характеристика диаграмм UML [26].

Таблица 11.5. Диаграммы

Диаграмма Назначение Тип диаграммы (модели ИС)
по учету специфики
средств итоговой реализации
моделируемой сущности
по учету фактора времени по семантике (сущности) содержания
Вариантов использования
(use case)
Отображает функции системы, взаимодействие между актерами и функциями Логическая Статическая Функциональная
Классов
(class)
Отображает набор классов, интерфейсов и отношений между ними Логическая или
физическая
Статическая Функционально-информационная
Пакетов
(package)
Отображает набор пакетов и отношений между ними Логическая или
физическая
Статическая Компонентная
Поведения
(behavior)
Автоматов
(state machine)
Отображает состояния сущности и переходы между ними в процессе ее жизненного цикла Логическая Динамическая Поведенческая
Деятельности
(activity)
Отображает бизнес-процессы в системе (описание алгоритмов поведения)
Взаимодействия
(interaction)
Последовательности
(sequence)
Отображает последовательность передачи сообщений между объектами и актерами
Коммуникации
(communication)
Аналогична диаграмме последовательности, но основной акцент делается на структуру взаимодействия между объектами
Реализации
(implementation)
Компонентов
(component)
Отображает компоненты системы (программы, библиотеки, таблицы и т.д.) и связи между ними Физическая Статическая Компонентная
Развертывания
(deployment)
Отображает размещение компонентов по узлам сети, а также ее конфигурацию

Стандарт UML 2.x определяет также дополнительные, узкоспециализированные диаграммы:

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

Таблица 11.6. Связь моделей и диаграмм

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

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

1 Класс анализа – укрупненный класс, который требует дальнейшей детализации и декомпозиции на несколько более мелких классов.

Вопросы для самопроверки

4. Дайте определение понятию «сторожевое условие».

Источник

Мастерица