Слайд 1Анализ и моделирование на UML
Максим Валерьевич Хлопотов,
старший преподаватель кафедры ИС
Слайд 2Темы лекционных занятий
Введение в UML
Моделирование использования
Моделирование структуры
Моделирование поведения
Дисциплина моделирования
Слайд 4Моделирование структуры
Моделируя структуру, мы описываем составные части системы и отношения
между ними.
UML является объектно-ориентированным языком моделирования, поэтому основным видом
составных частей системы являются объекты.
Слайд 5Назначение структурного моделирования
На UML нужно моделировать следующие основные структуры:
структура связей
между объектами во время выполнения программы;
структура хранения данных;
структура программного кода;
структура
компонентов в приложении;
структура используемых вычислительных ресурсов.
Слайд 6Диаграмма классов
Диаграмма классов является основным средством моделирования структуры UML.
Класс в
UML является основной структурной единицей.
Диаграммы классов наиболее информационно насыщены
по сравнению с другими типами канонических диаграмм UML, инструменты генерируют код в основном по описанию классов, структура классов точнее всего соответствует окончательной структуре кода приложения.
Слайд 7Диаграмма классов
На диаграммах классов в качестве сущностей применяются прежде всего
классы, как в своей наиболее общей форме, так и в
форме многочисленных стереотипов и частных случаев: интерфейсы, типы данных, процессы и др.
Кроме того, в диаграмме классов могут использоваться (как и везде) пакеты и примечания.
Сущности на диаграммах классов связываются главным образом отношениями ассоциации (в том числе агрегирования и композиции) и обобщения. Отношения зависимости и реализации на диаграммах классов применяются реже.
Слайд 8Идентификация классов
Нет универсального и применимого во всех случаях способа для
выделения классов, подлежащих описанию
Три приема выделения классов, самых простых,
а потому самых действенных и широко применимых:
словарь предметной области (набор основных понятий данной предметной области);
реализация вариантов использования;
образцы проектирования (стандартное решение типичной задачи в конкретном контексте).
Слайд 9Идентификация классов
Словарь предметной области — это набор основных понятий (сущностей)
данной предметной области.
Рассмотрите внимательно текст технического задания (или иного документа,
лежащего в основе проекта) и выделите в содержательной части имена существительные — все они являются кандидатами на то, чтобы быть названиями классов (или атрибутов классов) проектируемой системы. Разумеется, после этой простой операции к полученному списку нужно применить фильтр здравого смысла и опыта, отсекая ненужное.
Слайд 10Идентификация классов
Рассмотрим пример. Типа ТЗ:
Информационная система «Отдел кадров» (сокращенно ОК)
предназначена для ввода, хранения и обработки информации о сотрудниках и
движении кадров. Система должна обеспечивать выполнение следующих основных функций:
Прием, перевод и увольнение сотрудников.
Создание и ликвидация подразделений.
Создание вакансий и сокращение должностей.
Слайд 11Идентификация классов
Выпишем существительные в том порядке, как они встречаются, но
без повторений: прием; перевод; увольнение; сотрудник; создание; ликвидация; подразделение; вакансия;
сокращение; должность.
Заметим, что некоторые их этих слов по сути являются названиями действий (и по форме являются отглагольными существительными).
Отбросим замаскированные глаголы. Таким образом, остается список из четырех элементов: сотрудник; подразделение; вакансия; должность.
При этом вакансия — это должность в особом состоянии.
Таким образом, это слово в списке лишнее и у нас остались три кандидата, которые мы оставляем в словаре (и заодно присваиваем им английские идентификаторы).
Сотрудник (Person);
Подразделение (Department);
Должность (Position).
Слайд 12Идентификация классов
Образец проектирования — это стандартное решение типичной задачи в
конкретном контексте.
Синтаксически образец в UML является кооперацией, роли объектов в
которой рассматриваются как параметры, а аргументами являются конкретные классы модели.
Слайд 13Ассоциация на диаграмме классов
Отношение ассоциации является самым важным на диаграмме
классов.
В общем случае ассоциация, которая обозначается сплошной линией, соединяющей
классы, означает, что экземпляры одного класса связаны с экземплярами другого класса. Поскольку экземпляров может быть много, и каждый может быть связан с несколькими, ясно, что ассоциация является дескриптором, который описывает множество связанных объектов.
В UML ассоциация является классификатором, экземпляры которого называются связями.
Слайд 14Ассоциация на диаграмме классов
Связь между объектами в программе может быть
организована самыми разными способами. Например, в объекте одного класса может
хранится указатель на объект другого класса. Другой вариант: объект одного класса является контейнером для объектов другого класса.
Связь не обязательно является непосредственно хранимым физическим адресом. Этот адрес может динамически вычисляться во время выполнения программы на основании другой информации. Например, если объекты представлены как записи в таблице базы данных, то связь означает, в записи одного объекта имеется поле, значением которого является первичный ключ записи другого объекта (из другой таблицы).
Слайд 15Ассоциация на диаграмме классов
При моделировании на UML техника реализации связи
между объектами не имеет значения. Ассоциация в UML подразумевает лишь
то, что связанные объекты обладают достаточной информацией для организации взаимодействия. Возможность взаимодействия означает, что объект одного класса может послать сообщение объекту другого класса, в частности, вызвать операцию или же прочитать или изменить значение открытого атрибута.
Поскольку в объектно-ориентированной программе такого рода действия и составляют суть выполнения программы, моделирование структуры взаимосвязей объектов (т. е. выявление ассоциаций) является одной из ключевых задач при разработке.
Слайд 16Ассоциация на диаграмме классов
Базовая нотация ассоциации (сплошная линия) позволяет указать,
что объекты ассоциированных классов могут взаимодействовать во время выполнения. Но
это только малая часть того, что можно моделировать с помощью отношения ассоциации. Для ассоциации в UML предусмотрено наибольшее количество различных дополнений, которые мы сначала перечислим, а потом рассмотрим по порядку.
Дополнения, как обычно, не являются обязательными: их используют при необходимости, в различных ситуациях по разному. Если использовать все дополнения сразу, то диаграмма становится настолько перегруженной, что ее трудно читать.
Слайд 17Ассоциация на диаграмме классов
Для ассоциации определены следующие дополнения:
имя ассоциации (возможно,
вместе с направлением чтения);
кратность полюса ассоциации (полюсом называется конец линии
ассоциации. Обычно используются двухполюсные ассоциации, но могут быть и многополюсные);
вид агрегации полюса ассоциации;
роль полюса ассоциации;
направление навигации полюса ассоциации;
упорядоченность объектов на полюсе ассоциации;
изменяемость множества объектов на полюсе ассоциации;
квалификатор полюса ассоциации;
класс ассоциации;
видимость полюса ассоциации;
многополюсные ассоциации.
Слайд 18Ассоциация на диаграмме классов
Имя ассоциации указывается в виде строки текста
над (или под, или рядом с) линией ассоциации. Имя не
несет дополнительной семантической нагрузки, а просто позволяет различать ассоциации в модели.
Обычно имя не указывают, за исключением многополюсных ассоциаций или случая, когда одна и та же группа классов связана несколькими различными ассоциациями.
Например, в информационной системе отдела кадров, если сотрудник занимает должность, то соответствующие объектов классов Person и Position должны быть связаны.
Дополнительно можно указать направление чтения имени ассоциации.
Слайд 19Ассоциация на диаграмме классов
Фрагмент графической модели фактически можно прочитать вслух:
Person occupies position
Слайд 20Ассоциация на диаграмме классов
Кратность полюса ассоциации указывает, сколько объектов данного
класса (со стороны данного полюса) участвуют в связи. Кратность может
быть задана как конкретное число, и тогда в каждой связи со стороны данного полюса участвуют ровно столько объектов, сколько указано. Более распространен случай, когда кратность указывается как диапазон возможных значений, и тогда число объектов, участвующих в связи должно находится в пределах указанного диапазона. При указании кратности можно использовать символ *, который обозначает неопределенное число.
Слайд 21Ассоциация на диаграмме классов
Например, если в информационной системе отдела кадров
не предусматривается дробление ставок и совмещение должностей, то (работающему) сотруднику
соответствует одна должность, а должности соответствует один сотрудник или ни одного (должность вакантна).
Слайд 22Ассоциация на диаграмме классов
Более сложные случаи также легко моделируются с
помощью кратности полюсов.
Например, если мы хотим предусмотреть совмещение должностей и
хранить информацию даже о неработающих сотрудниках, то диаграмма примет следующий вид (запись * эквивалентна записи 0..*).
Слайд 23Ассоциация на диаграмме классов
Агрегация и композиция. В UML используются два
частных, но очень важных случая отношения ассоциации, которые называются агрегацией
и композицией. В обоих случаях речь идет о моделировании отношения типа «часть – целое». Ясно, что отношения такого типа следует отнести к отношениям ассоциации, поскольку части и целое обычно взаимодействуют.
Агрегация от класса A к классу B означает, что объекты (один или несколько) класса A входят в состав объекта класса B.
Слайд 24Ассоциация на диаграмме классов
Это отмечается с помощью специального графического дополнения:
на полюсе ассоциации, присоединенному к «целому», т. е., в данном
случае, к классу B, изображается ромб.
Слайд 25Ассоциация на диаграмме классов
При этом никаких дополнительных ограничений не накладывается:
объект класса A (часть) может быть связан отношениями агрегации с
другими объектами (т. Е. участвовать в нескольких агрегациях), создаваться и уничтожаться независимо от объекта класса B (целого).
Композиция накладывает более сильные ограничения: композиционно часть может входить только в одно целое, часть существует только пока существует целое и прекращает свое существование вместе с целым.
Графически отношение композиции отображается закрашенным ромбом.
Слайд 26Ассоциация на диаграмме классов
В первом случае (вверху), мы считаем, что
в организации принята жесткая структура: каждая должность входит ровно в
одно подразделение, в каждом подразделении есть по меньшей мере одна должность (начальник). Во втором случае (внизу) структура организации более аморфна: возможны «висящие в воздухе» должности, бывают «пустые» подразделения и т. д.
Слайд 27Ассоциация на диаграмме классов
В комбинации с указанием кратности, отношения ассоциации,
агрегации и композиции позволяют лаконично и полно отобразить структуру связей
объектов: что из чего состоит и как связано.
Слайд 28Ассоциация на диаграмме классов
Роль полюса ассоциации, называемая также спецификатором интерфейса
— это способ указать, как именно участвует классификатор (присоединенный к
данному полюсу ассоциации) в ассоциации. В общем случае данное дополнение имеет следующий синтаксис:
видимость ИМЯ : тип
Имя является обязательным, оно называется именем роли и фактически является собственным именем полюса ассоциации, позволяющим различать полюса.
Слайд 29Ассоциация на диаграмме классов
Если рассматривается одна ассоциация, соединяющая два различных
класса, то в именах ролей нет нужды: полюса ассоциации легко
можно различить по именам классов, к которым они присоединены. Однако, если это не так, т. е. если два класса соединены несколькими ассоциациями, или же если ассоциация соединяет класс с самим собой, то указание роли полюса ассоциации является необходимым.
Слайд 30Ассоциация на диаграмме классов
На этом рисунке изображена ассоциация класса Position
с самим собой. Эта ассоциация призвана отразить наличие иерархии подчиненности
должностей в организации.
Видно только, что объекты класса Person образуют некоторую иерархию, но не более того. Используя спецификацию интерфейсов и, заодно, отношения реализации и интерфейсы можно описать субординацию в информационной системе отдела кадров достаточно лаконично и точно.
Слайд 31Ассоциация на диаграмме классов
На рисунке указано, что в иерархии субординации
каждая должность может играть две роли. С одной стороны, должность
может рассматриваться как начальственная (chief), и в этом случае она предоставляет интерфейс IChief, имеющий операцию petition (начальнику можно подать служебную записку). С другой стороны, должность может рассматриваться как подчиненная (subordinate), и в этом случае она предоставляет интерфейс Isubordinate, имеющий операцию report (от подчиненного можно потребовать отчет).
У начальника может быть произвольное количество подчиненных, в том числе и 0, у подчиненного может быть не более одного начальника.
Слайд 32Ассоциация на диаграмме классов
Имея в виду ту же самую цель,
можно поступить и по-другому: непосредственно включить в описание класса составляющие,
ответственные за обеспечение нужной функциональности. Однако такое решение "не в духе" UML: во-первых, оно слишком привязано к реализации, разработчику не оставлено никакой свободы для творческих поисков эффективного решения; во-вторых оно менее наглядно — неудачный выбор имен атрибутов способен замаскировать семантику отношения для читателя модели, потеряны информативные имена ролей и ассоциации; в-третьих, оно менее надежно (в предыдущей диаграмме модели подчиненный синтаксически не может потребовать отчета от начальника, а в этой модели — может, и нужно предусматривать дополнительные средства для обработки этой ошибки.
Слайд 33Ассоциация на диаграмме классов
Направление навигации полюса ассоциации — это свойство
полюса, имеющее значение типа Boolean, и определяющее, можно ли получить
с помощью данной ассоциации доступ к объектам класса, присоединенному к данному полюсу ассоциации.
По умолчанию это свойство имеет значение true, т. е. доступ возможен. Если все полюса ассоциации (обычно их два) обеспечивают доступ, то это никак не отражается на диаграмме (потому, что данный случай наиболее распространенный и предполагается по умолчанию). Если же навигация через некоторые полюса возможна, а через другие нет, то те полюса, через которые навигация возможна, отмечаются стрелками на концах линии ассоциации.
Слайд 34Ассоциация на диаграмме классов
Таким образом, если никаких стрелок не изображается,
то это означает, что подразумеваются стрелки во всех возможных направлениях.
Если же некоторые стрелки присутствуют, то это означает, что доступ возможен только в направлениях, указанных стрелками.
Отсюда следует, что в UML невозможно изобразить случай, когда навигация вдоль ассоциации невозможна ни в каком направлении — но это и не нужно, т. к. такая ассоциация не имеет смысла.
Слайд 35Ассоциация на диаграмме классов
Допустим, имеются два класса: User (содержит информацию
о пользователе) и Password (содержит пароль — информацию, необходимую для
аутентификации пользователя). Мы хотим отразить в модели следующую ситуацию: имеется взаимно однозначное соответствие между пользователями и паролями, зная пользователя можно получить доступ к его паролю, но обратное неверно: по имеющемуся паролю нельзя определить, кому он принадлежит.
Слайд 36Ассоциация на диаграмме классов
Видимость полюса ассоциации — это указание того,
является ли классификатор присоединенный к данному полюсу ассоциации, видимым для
других классификаторов вдоль данной ассоциации, помимо тех классификаторов, которые присоединены к другим полюсам ассоциации.
Слайд 37Ассоциация на диаграмме классов
Допустим, у нас есть третий класс —
Workgroup — ответственный за хранение информации о группах пользователей. Тогда
очевидно, что зная группу, мы должны иметь возможность узнать, какие пользователи входят в группу, и обратно, для каждого пользователя можно определить в какую группу (или в какие группы) он включен. Но не менее очевидно, что доступ к группе не должен позволять узнать пароли пользователей этой группы. Другими словами, мы хотим ограничить доступ к объектам через полюс ассоциации. В UML для этого нужно явно указать имя роли полюса ассоциации, и перед именем роли поставить соответствующий символ видимости «-».
Слайд 38Ассоциация на диаграмме классов
Обратите внимание, что, согласно семантическим правилам UML,
ограничение видимости полюса pwd распространяется на объекты класса Workgroup, но
не на объекты класса User — непосредственно связанные объекты всегда видят друг друга. Объект класса User может использовать интерфейс pwd, предоставляемый классом Password — стрелка навигации разрешает ему это, но объект класса Workgroup не может использовать интерфейс pwd — значение видимости private (знак –) запрещает ему это.
Слайд 39Обобщение на диаграмме классов
Отношение обобщения часто применяется на диаграмме классов.
Действительно,
трудно представить себе ситуацию, когда между объектами в одной системе
нет ничего общего. Как правило, общее есть и это общее целесообразно выделить в отдельный класс.
При этом общие составляющие, собранные в суперклассе, автоматически наследуются подклассами. Таким образом, сокращается общее количество описаний, а значит, уменьшается вероятность допустить ошибку.
Слайд 40Обобщение на диаграмме классов
Использование обобщений не ограничивает свободу проектировщика системы,
поскольку унаследованные составляющие можно переопределить в подклассе, если нужно. При
обобщении выполняется принцип подстановочности. Фактически это означает увеличение гибкости и универсальности программного кода при одновременном сохранении надежности, обеспечиваемой контролем типов.
Действительно, если, например, в качестве типа параметра некоторой процедуры указать суперкласс, то процедура будет с равным успехом работать в случае, когда в качестве аргумента ей передан объект любого подкласса данного суперкласса.
Суперкласс может быть конкретным, идентифицированным одним из методов, а может быть абстрактным, введенным именно для построения отношений обобщения.
Слайд 41Обобщение на диаграмме классов
Рассмотрим пример. В информационной системе отдела кадров
мы выделили классы Position, Department и Person.
Резонно предположить, что все
эти классы имеют атрибут, содержащий собственное имя объекта, выделяющее его в ряду однородных. Для простоты положим, что такой атрибут имеет тип String. В таком случае можно определить суперкласс, ответственный за хранение данного атрибута и работу с ним, а прочие классы связать с суперклассом отношением обобщения.
Однако более пристальный анализ предметной области наводит на мысль, что работа с собственным именем для выделенных классов производится не совсем одинаково.
Слайд 42Обобщение на диаграмме классов
Назначение и изменение собственных имен подразделениям и
должностям находится в пределах ответственности информационной системы отдела кадров, но
назначение собственного имени сотрудника явно выходит за эти пределы.
Исходя из этих соображений, мы приходим к следующей структуре обобщений.
Обратите внимание, что суперкласс Unit мы определили как абстрактный, т. е. не могущий иметь непосредственных экземпляров, поскольку не предполагаем иметь в системе объекты данного класса. Класс Unit в данном нужен только для того, чтобы свести описания одного атрибута и двух операций в одно место и не повторять их дважды.
Слайд 44Обобщение на диаграмме классов
В UML допускается, чтобы класс был подклассом
нескольких суперклассов (множественное наследование), не требуется, чтобы у базовых классов
был общий суперкласс (несколько иерархий обобщения) и вообще не накладывается никаких ограничений, кроме частичной упорядоченности (т. е. отсутствия циклов в цепочках обобщений). Нарушение данного условия является синтаксической ошибкой. При множественном обобщении возможны конфликты: суперклассы содержат составляющие, которые невозможно включить в один подкласс, например, атрибуты с одинаковыми именами, но разными типами.
В UML конфликты при множественном обобщении считаются нарушением правил непротиворечивости модели