Анализ и моделирование на UML Направление подготовки Информационные системы и

Валерьевич Хлопотов,
старший преподаватель кафедры ИС

между ними.
UML является объектно-ориентированным языком моделирования, поэтому основным видом

составных частей системы являются объекты.

между объектами во время выполнения программы;
структура хранения данных;
структура программного кода;
структура

компонентов в приложении;
структура используемых вычислительных ресурсов.

UML является основной структурной единицей.
Диаграммы классов наиболее информационно насыщены

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

классы, как в своей наиболее общей форме, так и в

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

выделения классов, подлежащих описанию
Три приема выделения классов, самых простых,

а потому самых действенных и широко применимых:
словарь предметной области (набор основных понятий данной предметной области);
реализация вариантов использования;
образцы проектирования (стандартное решение типичной задачи в конкретном контексте).

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

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

предназначена для ввода, хранения и обработки информации о сотрудниках и

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

без повторений: прием; перевод; увольнение; сотрудник; создание; ликвидация; подразделение; вакансия;

сокращение; должность.
Заметим, что некоторые их этих слов по сути являются названиями действий (и по форме являются отглагольными существительными).
Отбросим замаскированные глаголы. Таким образом, остается список из четырех элементов: сотрудник; подразделение; вакансия; должность.
При этом вакансия — это должность в особом состоянии.
Таким образом, это слово в списке лишнее и у нас остались три кандидата, которые мы оставляем в словаре (и заодно присваиваем им английские идентификаторы).
Сотрудник (Person);
Подразделение (Department);
Должность (Position).

конкретном контексте.
Синтаксически образец в UML является кооперацией, роли объектов в

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

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

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

организована самыми разными способами. Например, в объекте одного класса может

хранится указатель на объект другого класса. Другой вариант: объект одного класса является контейнером для объектов другого класса.
Связь не обязательно является непосредственно хранимым физическим адресом. Этот адрес может динамически вычисляться во время выполнения программы на основании другой информации. Например, если объекты представлены как записи в таблице базы данных, то связь означает, в записи одного объекта имеется поле, значением которого является первичный ключ записи другого объекта (из другой таблицы).

между объектами не имеет значения. Ассоциация в UML подразумевает лишь

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

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

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

вместе с направлением чтения);
кратность полюса ассоциации (полюсом называется конец линии

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

над (или под, или рядом с) линией ассоциации. Имя не

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

Person occupies position

класса (со стороны данного полюса) участвуют в связи. Кратность может

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

не предусматривается дробление ставок и совмещение должностей, то (работающему) сотруднику

соответствует одна должность, а должности соответствует один сотрудник или ни одного (должность вакантна).

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

хранить информацию даже о неработающих сотрудниках, то диаграмма примет следующий вид (запись * эквивалентна записи 0..*).

частных, но очень важных случая отношения ассоциации, которые называются агрегацией

и композицией. В обоих случаях речь идет о моделировании отношения типа «часть – целое». Ясно, что отношения такого типа следует отнести к отношениям ассоциации, поскольку части и целое обычно взаимодействуют.
Агрегация от класса A к классу B означает, что объекты (один или несколько) класса A входят в состав объекта класса B.

на полюсе ассоциации, присоединенному к «целому», т. е., в данном

случае, к классу B, изображается ромб.

объект класса A (часть) может быть связан отношениями агрегации с

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

в организации принята жесткая структура: каждая должность входит ровно в

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

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

объектов: что из чего состоит и как связано.

— это способ указать, как именно участвует классификатор (присоединенный к

данному полюсу ассоциации) в ассоциации. В общем случае данное дополнение имеет следующий синтаксис:
видимость ИМЯ : тип
Имя является обязательным, оно называется именем роли и фактически является собственным именем полюса ассоциации, позволяющим различать полюса.

класса, то в именах ролей нет нужды: полюса ассоциации легко

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

с самим собой. Эта ассоциация призвана отразить наличие иерархии подчиненности

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

каждая должность может играть две роли. С одной стороны, должность

может рассматриваться как начальственная (chief), и в этом случае она предоставляет интерфейс IChief, имеющий операцию petition (начальнику можно подать служебную записку). С другой стороны, должность может рассматриваться как подчиненная (subordinate), и в этом случае она предоставляет интерфейс Isubordinate, имеющий операцию report (от подчиненного можно потребовать отчет).
У начальника может быть произвольное количество подчиненных, в том числе и 0, у подчиненного может быть не более одного начальника.

можно поступить и по-другому: непосредственно включить в описание класса составляющие,

ответственные за обеспечение нужной функциональности. Однако такое решение "не в духе" UML: во-первых, оно слишком привязано к реализации, разработчику не оставлено никакой свободы для творческих поисков эффективного решения; во-вторых оно менее наглядно — неудачный выбор имен атрибутов способен замаскировать семантику отношения для читателя модели, потеряны информативные имена ролей и ассоциации; в-третьих, оно менее надежно (в предыдущей диаграмме модели подчиненный синтаксически не может потребовать отчета от начальника, а в этой модели — может, и нужно предусматривать дополнительные средства для обработки этой ошибки.

полюса, имеющее значение типа Boolean, и определяющее, можно ли получить

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

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

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

о пользователе) и Password (содержит пароль — информацию, необходимую для

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

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

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

Workgroup — ответственный за хранение информации о группах пользователей. Тогда

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

ограничение видимости полюса pwd распространяется на объекты класса Workgroup, но

не на объекты класса User — непосредственно связанные объекты всегда видят друг друга. Объект класса User может использовать интерфейс pwd, предоставляемый классом Password — стрелка навигации разрешает ему это, но объект класса Workgroup не может использовать интерфейс pwd — значение видимости private (знак –) запрещает ему это.

трудно представить себе ситуацию, когда между объектами в одной системе

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

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

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

мы выделили классы Position, Department и Person.
Резонно предположить, что все

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

должностям находится в пределах ответственности информационной системы отдела кадров, но

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

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

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

образцов проектирования
3. Используя методы идентификации классов, выделить классы.
4. Указать

связи между классами.
5. Указать атрибуты классов.
6*. Указать операции классов.
7. Создать диаграммы реализации. (Рассмотрим на следующей лекции).

области
2. Перечень классов (с указанием атрибутов и операций)
3. Диаграммы классов

(3 штуки)*
4. Диаграмма компонентов (Рассмотрим на следующей лекции)
5. Диаграмма развертывания (Рассмотрим на следующей лекции)