Диаграмма классов ремонт техники

Автоматизация учёта технического обслуживания техники сервисного центра , страница 6

5) класс «Форма__описание_ремонта» характеризует программное окно, в котором инженер описывает произведённый ремонт.

6) класс «Форма_список_инженеров» характеризует программное окно, в котором отображается все сервисные инженеры, которые работают в настоящий момент.

7) класс «Форма_добавления_инженера» характеризует программное окно, в котором реализуется возможность добавления нового инженера в систему.

3.2 Определение методов объектов.

Диаграмма последовательностей для сценария «Создание квитанции»:

Выявленные методы классов:

— «Открыть форму». Реализуется посредством взаимодействия диспетчера с управляющими элементами формы программы.

— «Заполнение формы». Ввод данных в поля формы будущей квитанции.

— «Подтверждение ввода». Реализуется нажатием кнопки, подтверждая правильность процедуры, и достоверность введённой в форму информации.

— «Добавить квитанцию». При получении подтверждения создаётся новая квитанция, в которой записаны данные из новой формы.

Диаграмма последовательностей для сценария » Завершение ремонта «:

Выявленные методы классов:

— «Открыть форму». Реализуется посредством взаимодействия инженера с управляющими элементами формы программы.

— «Выбор квитанции». Обращение к списку с просмотра текущих квитанций.

— «Открыть форму описания ремонта». Обращение к форме описания ремонта, формируется форма данной квитанции.

— «Ввод данных» Процесс заполнение инженером полей формы описания ремонта, данных о произведённом техническом обслуживании.

— «Изменение статуса». Инженер после ввода данных, изменяет статус текущей отображаемой и редактируемой им квитанции.

— «Подтвердить ввод». Реализация, посредством нажатия кнопки, подтверждения правильности процедуры, и достоверность изменённых данных в квитанции.

— «Изменение квитанции». Процесс сохранения добавленной или изменённой инженером информации в вызванной им квитанции.

Диаграмма последовательностей для сценария » Назначение инженера «:

Выявленные методы классов:

— «Открыть форму». Реализуется посредством взаимодействия инженера с управляющими элементами других форм программы.

— «Ввод параметров сортировки». Указывает критерии, по которому будет происходить сортировка и поиск квитанций в списке.

— «Выбор по критерию». После указания критериев поиска, происходит выборка и отображения всех найдённых и отсортированных квитанций.

— «Выбор квитанции». Инженер выбирает свободную квитанцию, обратившись к ней.

— «Присвоение квитанции». Инженер в выбранной свободной квитанции, присваивает её себе.

— «Назначение инженера на квитанцию». Сохранение указанных изменений в списке квитанций.

Диаграмма последовательностей для сценария » Учёт проделанной работы «:

Выявленные методы классов:

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

— «Ввод параметров выборки». Указывает критерии, по которому будет происходить сортировка и поиск квитанций в списке.

— «Выборка по критерию» процесс поиска квитанций по указанному критерию.

— «Возвращение отсортированного списка» отображение в главной форме диспетчера отсортированного по критериям, списка квитанций.

— «Сортировка данных» процесс поиска квитанций по определённым параметрам.

Итоговая диаграмма классов представлена на рисунке:

3.3 Выбор технологий реализации.

— языки программирования и среда разработки:

— C#. Динамично развивающийся язык. Позволяет решать все задачи, стоящие перед разрабатываемой системой. Программы на этом языке будут функционировать на стороне клиента. Мощное средство для написания windows-приложений.

— Visual Studio 2005. Удобная среда разработки программ, и соответственно хорошее решение для написания приложений на C#.

— методы доступа к данным.

Осуществляются по средством технологии Ado.net.

Для работы системы необходимо постоянное функционирование сервера СУБД MsSQL.

Система может работать на операционных системах семейства Windows начиная с версии Windows 98. Для работы клиентских приложений необходимо наличие .Net Framework 2.0. Серверной компоненте нужен установленный MsSQL.

— параметры среды развёртывания.

Процессор: 3Ггц, оперативная память: 2Гб, жесткий диск: 300Гб.

Процессор: 1Ггц, оперативная память: 512МБ, жесткий диск: 40Гб.

3.4 Проектирование хранилища данных.

Состав предполагаемых объектов базы данных:

— Id_client – индекс клиента,

— Имя – имя клиента,

— Организация – название организации (в том случае, если юр. лицо),

— Фамилия – фамилия клиента,

— Отчество – отчество клиента.

— Инженеры, работающие в сервисном центре:

— Id_ingener – уникальный индекс инженера,

— Имя – имя инженера,

— Отчество – отчество инженера,

— Отдел – отдел в котором работает данный инженер,

— Фамилия – фамилия инженера,

— Разряд – уровень квалификации инженера.

— Техника, находящаяся в ремонте:

— Id_technika уникальный индекс техники,

— Производитель – производитель данной техники,

— Модель – конкретная модель,

— Серийный номер — уникальный заводской номер техники,

— Гарантийный срок – срок службы установленный производителем,

• АлтГТУ 419
• АлтГУ 113
• АмПГУ 296
• АГТУ 267
• БИТТУ 794
• БГТУ «Военмех» 1191
• БГМУ 172
• БГТУ 603
• БГУ 155
• БГУИР 391
• БелГУТ 4908
• БГЭУ 963
• БНТУ 1070
• БТЭУ ПК 689
• БрГУ 179
• ВНТУ 120
• ВГУЭС 426
• ВлГУ 645
• ВМедА 611
• ВолгГТУ 235
• ВНУ им. Даля 166
• ВЗФЭИ 245
• ВятГСХА 101
• ВятГГУ 139
• ВятГУ 559
• ГГДСК 171
• ГомГМК 501
• ГГМУ 1966
• ГГТУ им. Сухого 4467
• ГГУ им. Скорины 1590
• ГМА им. Макарова 299
• ДГПУ 159
• ДальГАУ 279
• ДВГГУ 134
• ДВГМУ 408
• ДВГТУ 936
• ДВГУПС 305
• ДВФУ 949
• ДонГТУ 498
• ДИТМ МНТУ 109
• ИвГМА 488
• ИГХТУ 131
• ИжГТУ 145
• КемГППК 171
• КемГУ 508
• КГМТУ 270
• КировАТ 147
• КГКСЭП 407
• КГТА им. Дегтярева 174
• КнАГТУ 2910
• КрасГАУ 345
• КрасГМУ 629
• КГПУ им. Астафьева 133
• КГТУ (СФУ) 567
• КГТЭИ (СФУ) 112
• КПК №2 177
• КубГТУ 138
• КубГУ 109
• КузГПА 182
• КузГТУ 789
• МГТУ им. Носова 369
• МГЭУ им. Сахарова 232
• МГЭК 249
• МГПУ 165
• МАИ 144
• МАДИ 151
• МГИУ 1179
• МГОУ 121
• МГСУ 331
• МГУ 273
• МГУКИ 101
• МГУПИ 225
• МГУПС (МИИТ) 637
• МГУТУ 122
• МТУСИ 179
• ХАИ 656
• ТПУ 455
• НИУ МЭИ 640
• НМСУ «Горный» 1701
• ХПИ 1534
• НТУУ «КПИ» 213
• НУК им. Макарова 543
• НВ 1001
• НГАВТ 362
• НГАУ 411
• НГАСУ 817
• НГМУ 665
• НГПУ 214
• НГТУ 4610
• НГУ 1993
• НГУЭУ 499
• НИИ 201
• ОмГТУ 302
• ОмГУПС 230
• СПбПК №4 115
• ПГУПС 2489
• ПГПУ им. Короленко 296
• ПНТУ им. Кондратюка 120
• РАНХиГС 190
• РОАТ МИИТ 608
• РТА 245
• РГГМУ 117
• РГПУ им. Герцена 123
• РГППУ 142
• РГСУ 162
• «МАТИ» — РГТУ 121
• РГУНиГ 260
• РЭУ им. Плеханова 123
• РГАТУ им. Соловьёва 219
• РязГМУ 125
• РГРТУ 666
• СамГТУ 131
• СПбГАСУ 315
• ИНЖЭКОН 328
• СПбГИПСР 136
• СПбГЛТУ им. Кирова 227
• СПбГМТУ 143
• СПбГПМУ 146
• СПбГПУ 1599
• СПбГТИ (ТУ) 293
• СПбГТУРП 236
• СПбГУ 578
• ГУАП 524
• СПбГУНиПТ 291
• СПбГУПТД 438
• СПбГУСЭ 226
• СПбГУТ 194
• СПГУТД 151
• СПбГУЭФ 145
• СПбГЭТУ «ЛЭТИ» 379
• ПИМаш 247
• НИУ ИТМО 531
• СГТУ им. Гагарина 114
• СахГУ 278
• СЗТУ 484
• СибАГС 249
• СибГАУ 462
• СибГИУ 1654
• СибГТУ 946
• СГУПС 1473
• СибГУТИ 2083
• СибУПК 377
• СФУ 2424
• СНАУ 567
• СумГУ 768
• ТРТУ 149
• ТОГУ 551
• ТГЭУ 325
• ТГУ (Томск) 276
• ТГПУ 181
• ТулГУ 553
• УкрГАЖТ 234
• УлГТУ 536
• УИПКПРО 123
• УрГПУ 195
• УГТУ-УПИ 758
• УГНТУ 570
• УГТУ 134
• ХГАЭП 138
• ХГАФК 110
• ХНАГХ 407
• ХНУВД 512
• ХНУ им. Каразина 305
• ХНУРЭ 325
• ХНЭУ 495
• ЦПУ 157
• ЧитГУ 220
• ЮУрГУ 309

Полный список ВУЗов

Чтобы распечатать файл, скачайте его (в формате Word).

Источник

Диаграммы классов UML

Введение и содержание

Диаграмма классов занимает центральное место в проектировании объектно-ориентированной системы. Нотация классов используется на разных этапах проектирования и строится с различной степенью детализации. Язык UML применяется не только для проектирования, но и с целью документирования, а также эскизирования проекта. Я (в отличии от Гради Буча) не являюсь сторонником разработки проекта с использованием всех видов UML диаграмм, а также детального проектирования. Чаще всего я применяю UML для эскизирования, а также для проектирования по процессу ICONIX [Rosenberg]. В статье описана часть нотации классов UML, применение которой достаточно в большинстве случаев. Тут не будет информации о кратности ассоциаций и атрибутов, особенностях изображения параллельных операций, шаблонах (параметризованных классах) и ограничениях. При необходимости всю эту информации можно посмотреть в других книгах [Buch, Leonenkov]. Мы же ограничимся базовой частью нотации и больше внимания уделим применению диаграммы классов.

1 Элементы диаграммы классов

На диаграмме классов с помощью специальных символов изображаются типы данных программы и отношения между ними, хотя в некоторых случаях могут использоваться и некоторые другие элементы — пакеты и даже экземпляры классов (объекты) [Leonenkov].

1.1 Символ класса

Символ класса на диаграмме может выглядеть различным образом в зависимости от детализации диаграммы:

Вопросы детализации будут рассмотрены в следующих разделах, а сейчас надо обратить внимание, что символ класса содержит имя ( Player ), набор операций ( move , get_gealth ) и атрибутов ( pos , state ). Для элементов класса могут задаваться тип, кратность, видимость и т.д.:

Формат спецификации атрибута:
видимость имя : тип [кратность] = значение_по_умолчанию

Формат спецификации операции:
видимость имя(аргумент: тип) = тип_возвращаемого_значения

В зависимости от параметра видимости элемент может быть:

• приватным ( private , доступен только внутри класса) — задается символом «минус» ( — ), может отображаться в виде квадрата;
• защищенным ( protected , доступен внутри класса, а также внутри классов-наследников) — задается символом «решетка» ( # ), может отображаться в виде ромба;
• открытым ( public , доступен всем) — задается символом «плюс» ( + ), может отображаться в виде круга.

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

1.2 Отношения классов

Диаграмма классов допускает различные виды отношений, рассмотрим их на части диаграммы модели некоторой игры:

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

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

Отношение композиции обозначается закрашенным ромбом, который рисуется со стороны включающего класса — так, класс MovingItem включает в себя класс Position , т.к. перемещающийся объект всегда имеет позицию. Отношение агрегации изображается незакрашенным ромбом — игрок ( Player ) агрегирует состояние ( IPlayerState ).

Если вы знакомы с паттернами State, Strategy или Delegation — секцию можно пропустить.
На приведенной выше диаграмме используется шаблон проектирования Состояние (State), являющийся разновидностью шаблона Делегирование ( Delegation ) и близкой к паттерну Стратегия ( Strategy ). Суть делегирования заключается в том, что для упрощения логики работы класса, часть его работы может быть передана (делегирована) вспомогательному классу. В свою очередь, паттерн State может быть добавлен, например, на этапе рефакторинга если в нескольких функциях класса встречается разлапистая проверка состояния объекта для выполнения тех или иных действий. В нашем случае персонаж может взаимодействовать с ежом, предположим, что если персонаж движется сидя и контактирует с ежом — у него должно уменьшится здоровье, а если стоя — увеличится счет ( points ). Кроме ежа могла быть еда, противники, патроны и т.д. Для демонстрации такого паттерна создан абстрактный класс IPlayerState и два наследника StayState и SeatState . В классе Player , при нажатии кнопки Ctrl состояние могло бы меняться на SeatState , а при отпускании — на StayState . Таким образом, при выполнении state->process_hedgehog(this) наш игрок каким-то образом, определенным объектом state , проконтактирует с ежиком.

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

Наиболее общий вид отношений между классами — ассоциация, обозначается сплошной линией (иногда со стрелкой). Вообще, и композиция, и агрегация, и обобщение (наследование) — являются частными случаями ассоциации. В нашей диаграмме с помощью ассоциации показано, что класс IPlayerState изменяет stats ( health и points ) объекта Player . Ассоциация может иметь название связи, поясняющую суть отношения. В качестве названия связей композиции и агрегации часто используется имя соответствующей переменной. Кроме того, ассоциация может иметь кратность, она задается на концах линии:

• 1 — одна связь (на нашей диаграмме показано, что один игрок включает в себя один экземпляр класса IPlayerState );
• * любое число связей (если бы на диаграмме был класс игрового поля, то с помощью звездочки можно было бы показать, что оно может содержать произвольное число игровых элементов);
• [от..до] — может задаваться диапазоном. Так диапазон [0..*] эквивалентен звездочке, но если мы захотим показать, что должно присутствовать более одного объекта — можем записать [1..*]

Последний вид отношений, который мы рассмотрим — зависимость, изображается штриховой (прерывистой) линией. Если есть стрелка — то направлена от зависимого к независимому классу, если стрелки нет — то классы зависят друг от друга. Под зависимостью понимается зависимость от интерфейса, т.е. если интерфейс независимого класса изменится — то придется вносить изменения в зависимый класс. В нашей диаграмме SeatState и StayState зависят от класса Player , т.к. обращаются к его методам для изменения характеристик игрока. Для изображения отношения дружбы между классами используется отношение зависимости с подписью friend .

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

2 Использование диаграммы классов

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

Стоит отметить, что у Гради Буча советы по использованию UML даны в книге «Руководство пользователя» [Buch_Rambo], но в его «Объектно-ориементированном анализе» [Buch] можно найти хорошие примеры и критерии качества проекта. Леоненков [Leonenkov] и вовсе избегает этой темы, оставляя лишь ссылки на литературу, конкретные рекомендации я нашел у Лармана [Larman] и Розенберга [Rosenberg], часть материала основана на моем личном опыте. Фаулер рассматривает UML как средство эскизирования, поэтому у него свой (сильно отличающийся от Буча и Розенберга) взгляд на диаграмму классов [Fauler].

2.1 Диаграмма классов как словарь системы, концептуальная модель

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

Гради Буч для построения словаря системы предлагает выполнять в следующем порядке [BuchRambo]:

1. анализируя прецеденты, определить какие элементы пользователи и разработчики применяют для описания задачи или ее решения;
2. выявить для каждой абстракции соответствующее ей множество обязанностей (ответственности). Проследите правильность распределения обязанностей (в том числе, соблюдение принципа единой обязанности [solid_refactoring]);
3. разработайте процедуры и операции для выполнения классами своих обязанностей.

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

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

Ларман предлагает строить концептуальную модель системы [Larman] — это примерно то, что мы описали как словарь системы, но помимо терминов предметной области в ней фиксируются некоторые отношения, понятные заказчику. Например, заказчик понимает (и фиксирует в техническом задании), что оформляет — следовательно, между продавцом и покупкой существует отношение ассоциации «оформляет» . Я рекомендую строить концептуальную модель, дорабатывая словарь системы, хотя Ларман рекомендует сначала добавлять ассоциации, а затем — атрибуты.

2.2 Диаграмма классов уровня проектирования

В любом объектно-ориентированном процессе проектирования диаграмма классов является результатом, т.к. является моделью, наиболее близкой к реализации (коду). Существуют инструменты, способные преобразовать диаграмму классов в код — такой процесс называется кодогенерацией и поддерживается множеством IDE и средств проектирования. Например, кодогенерацию выполняет Visual Paradigm (доступно в виде плагинов для множества IDE), новые версии Microsoft Visual Studio, такие средств UML-моделирования как StarUML, ArgoUML и др. Чтобы построить по диаграмме хороший код, она должна быть достаточно подробной. Именно о такой диаграмме идет речь в этом разделе.

До Ларману [Larman] до начала построения диаграммы классов уровня проектирования должны быть построены диаграммы взаимодействия и концептуальная модель системы. При этом порядок построения диаграммы следующий:

1. перенести классы с диаграммы последовательности;
2. добавить атрибуты концептуальной модели;
3. добавить имена методов по анализу диаграмм взаимодействия (например, диаграмм последовательностей [uml_sequence_diag]);
4. добавить типы атрибутов и методов;
5. добавить ассоциации (на основании атрибутов — отношения композиции и агрегации);
6. добавить стрелки (направление ассоциаций)
7. добавить ассоциации, определяющие другие виды отношений (в первую очередь, наследование).

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

Например, при анализе задания на игру «Сапер» мы выделили классы и , но будут ли эти классы в окончательном проекте или останутся только в воображении? — решение можно принять только проанализировав диаграммы взаимодействия. Ведь возможен и такой код:

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

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

2.3 Диаграмма классов для эскизирования, документирования

Под эскизированием понимают моделирование некоторой (интересной нам в данный момент) части системы. Например, эскизирование может выполняться на маркерной доске когда в вашу компанию попадет новый сотрудник и вы будете помогать ему «влиться» в существующий проект. Очевидно, что если если дать человеку диаграмму классов уровня проектирования — разбираться он будет долго. Суть эскизирования в избирательности — вы выносите на диаграмму только те элементы, которые важны для пояснения того или иного механизма.

Сторонником применения UML для эскизирования является Фаулер [Fauler], который считает, что целостный процесс проектирования с использованием UML слишком сложен. Эскизирование применяется очень часто (не только при объяснении проекта на маркерной доске):

• в любой книге, посвященной паттернам проектирования, вы найдете массу UML диаграмм, выполненных в этом стиле;
• при моделировании прецедента выбираются классы, за счет которых этот прецедент реализуется. Моделирование прецедента выполняется при рефакторинге;
• в документацию для разработчиков нет смысла вставлять диаграмму классов уровня проектирования — гораздо полезнее описать наиболее важные (ключевые) моменты системы. Для этого строятся эскизные диаграммы классов и диаграммы взаимодействия. Также существуют специальные инструменты построения документацию по готовому коду — такие как JavaDoc или Doxygen [doxygen_codegeneration], в частности они строят диаграмму классов, но чтобы документация была понятной, в исходный код программы требуется вносить комментарии специального вида.

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

2.4 Диаграмма классов для моделирования БД

Частным случаем диаграммы классов является диаграмма «сущность-связь» (E-R диаграмма), используемая для моделирования логической схемы базы данных. В отличии от классических E-R диаграмм, диаграмма классов позволяет моделировать поведение (триггеры и хранимые процедуры).

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

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

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

Для моделирования схемы БД с помощью диаграммы классов нужно [Buch_Rambo]:

1. идентифицировать классы, данные которых должны храниться между запусками приложения (или обращениями пользователя) и нанести эти классы на отдельную диаграмму;
2. детально специфицировать атрибуты классов, ассоциации и кратности. В E-R модели кратности имеют огромное значение — так например, при наличии кратности «многие-ко-многим» придется создавать вспомогательную таблицу. Используйте специфические стереотипы классов и пометки атрибутов (для задания первичных и вторичных ключей, например) [uml_datamodeling];
3. решить проблемы использования полученной диаграммы в качестве физической модели базы данных — циклические ассоциации, n-арные ассоциации и т.д. При необходимости создать промежуточные абстракции;
4. раскрыть операции, важные для доступа к данным и поддержания целостности;

Заключение и список литературы

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

Источник