Управление моделями в UML

преподаватель кафедры ИС

значение при определении как структуры модели, так и структуры моделируемого

приложения: модели,
системы и подсистемы,
а также синтаксические средства их выражения в UML.

реального мира. Например, при моделировании приложения рассматривается его программная реализация,

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

Все это вместе называется физической системой.

с различных точек зрения. Описание физической системы называется моделью. Каждая

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

обычно и бывает), то ее целесообразно мысленно разбить на части,

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

система, состоит из некоторого количества компьютеров, программных компонентов, составляющих приложение

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

Если модель достаточно велика, ее нужно разделить на части обозримого

размера и рассматривать их по отдельности. Для этой цели в UML используется одно универсальное средство — пакет.

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

объявленными в нем элементами модели, а элементы принадлежат владеющему ими

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

образует пространство имен, т. е. область определения и использования имен.

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

помещать любые элементы модели — тем самым моделируется отношение владения:

пакет владеет элементом, помещенным внутрь его фигуры.

отвечают своему основному назначению — служить средством визуализации, спецификации, проектирования

и документирования.

чтобы тексты и значки оставались читаемыми, от модели мало проку.

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

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

примерно одинаково и равно 7±3.
Если сущностей на диаграмме три или меньше, то диаграмма недостаточно информативна, чтобы включать ее в модель отдельно. Такую диаграмму либо не стоит включать в модель, либо можно объединить с другой однородной диаграммой.
Если на диаграмме больше десяти сущностей, то она, как правило, слишком трудна для понимания с одного взгляда. Такую диаграмму целесообразно разбить на несколько диаграмм.

диаграмм примерно постоянна и равна 7±3.
Другими словами, пакету должны

принадлежать от трех до десяти пакетов или диаграмм. Если их меньше, то не понятно, нужен ли такой малосодержательный пакет как отдельная сущность. Если больше, то в деталях пакета можно "утонуть".

сверху значением 7±3, при этом больше половины элементов модели должно

присутствовать на диаграммах.
Любой данный элемент модели может присутствовать на некотором количестве диаграмм: 0, 1 или больше. Если на диаграммах нарисовано меньше половины существующих в модели элементов, то это не модель, а "вещь в себе", о назначении которой трудно догадаться.
Если один и тот же элемент повторяется в разных местах больше десяти раз, то это "масло масляное".

ее содержание.
Способы структурирования модели по содержанию:
- По структуре приложения.

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

ними разработчики большинства инструментов пытаются навязать пользователю структуру модели.
Только

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

находиться в следующих отношениях:
• отношения владения (вложенности);
• индуцированные отношения;
• стереотипные

зависимости;
• обобщение.

определенный в данном пространстве имен, видит все элементы, определенные в

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

отражает наличие такого же отношения между некоторыми элементами данных пакетов.
Например,

если указано, что пакет X зависит от пакета Y, то это означает, что один или несколько элементов модели, которыми владеет пакет X, зависят от одного или нескольких элементов модели, которыми владеет пакет Y. При этом вовсе не подразумевается, что все элементы пакетов находятся в данном отношении — достаточно наличия одной пары.

и «import», которые имеют сходное назначение, но различаются в некоторых

деталях.

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

Различие между ними в том, что использование зависимости «access» не влияет на пространство имен зависимого пакета — для доступа к элементу независимого пакета нужно указывать составное имя, а при использовании зависимости «import» происходит расширение пространства имен зависимого пакета пространством имен независимого пакета.

них можно указать отношение обобщения.
Обычно отношение обобщения для пакетов

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

информационной системы отдела кадров, касающаяся управления данными.
Пакеты Personnel Management

и Staff Management зависят от абстрактного пакета Data Management, который является обобщением пакетов Database Management и Files Management.

пакетов,
«facade»
Пакет, который содержит только ссылки на элементы, определенные в

других пакетах. Используется для описания "внешнего вида" других пакетов.
«framework»
Пакет, содержащий образцы и шаблоны. Используется для описания повторно используемых архитектурных решений.
«metamodel»
Модель, которая описывает другую модель. Например, метамодель UML.
«modelLibrary»
Пакет, содержащий определения элементов моделирования, предназначенных для использования в других пакетах.
«profile»
Пакет, содержащий определения элементов моделирования, предназначенных для моделирования в определенной предметной области.
«systemModel»
Модель, содержащая несколько моделей одной физической системы.
«topLevel»
Пакет, который является конем иерархии вложенности пакетов.

субъект должен приложить определенные мыслительные усилия, чтобы выбрать хорошую структуру,

подходящую для данного случая.

субъект должен приложить определенные мыслительные усилия, чтобы выбрать хорошую структуру,

подходящую для данного случая.

т. е. порядок проведения типового проекта по разработке программного обеспечения.

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

процессе разработки. Сюда относятся определение обязанностей работников — участников процесса,

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

входящих в состав программного обеспечения. Сюда относятся описание и применение

образцов проектирования, стандарты кодирования, методы тестирования и отладки и т. д. Характерным для данного аспекта является рассмотрение на уровне отдельного работника.

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

улучшать процесс в различных направлениях.

Повышение надежности программного обеспечения.
• Снижение совокупной стоимости владения программным

обеспечением.
• Повышение продуктивности программирования.

программного обеспечения. Причина влияния заключается в том, что применение UML

унифицирует представления информации в циклах повышения продуктивности. Унификация обеспечивает ускорение прохождения циклов, повышение сохранности, облегчение восприятия и повышение надежности принимаемых решений.

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

приступая к применению UML: чего мы хотим достичь?

Концептуальное моделирование.

Спецификация требований.
Детальное проектирование.

физической системы (приложения, бизнес-процесса…), ее назначения и области применения.
Уровни

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

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

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

послужить техническим заданием на разработку.
Техническое задание должно определять требования

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

это основа для построения набора тестов приемо-сдаточных испытаний.
На диаграммы

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

обязательна — техническое задание должно определять, хотя бы на уровне

названий, что именно должно быть разработано. Между концептуальной моделью и спецификацией требований нет непроходимой границы — довольно часто концептуальная модель за несколько итераций перерастает в спецификацию требований. По нашим наблюдениям, удовлетворительная спецификация требований оказывается в 3–5 раз объемнее концептуальной модели.

два внешних цикла движения определенных артефактов.
Цикл, в который вовлечен

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

обеспечивает ускорение прохождения циклов, повышение сохранности, облегчение восприятия и повышение

надежности принимаемых решений.

программного обеспечения.
Причина влияния заключается в том, что применение UML

унифицирует представления информации в циклах повышения продуктивности.

Унификация обеспечивает ускорение прохождения
циклов, повышение сохранности, облегчение восприятия и повышение надежности
принимаемых решений.

программирование — это искусство, то что говорить об архитектурном проектировании

и концептуальном моделировании? Это, видимо, элитарное искусство.

Не переоценивайте возможности инструмента.
Не пренебрегайте возможностями инструмента.
Не переоценивайте собственные возможности
Не пренебрегайте собственными возможностями

взглядом».
Управление моделями – для того, кто моделирует, а не для

компьютера.
Нет наилучшего процесса для всех типов проектов и всех типов организаций, но для каждого типа проектов и для каждого типа организаций в отдельности — есть.

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

с примечаниями,
диаграмма деятельности с дорожками,
диаграмма классов полная (с интерфейсами),
диаграмма состояний,
диаграммы взаимодействия (минимум 2) с указанием состояний объектов,
7 ± 3 сущности на одной диаграмме.
Приветствуется применение паттернов проектирования

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

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