Диаграмма классов UML и диаграмма базы данных ER

Question

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

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

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

Извините за мой плохой английский.

Спасибо.

Answer 1

Я уже несколько раз решал эту проблему и решил ее следующим образом:

1.) Выберите (унаследовано от Vector, в нем хранятся все строки со стандартными классами, в зависимости от языка, на котором вы работаете) Структура:

ID (и ID, полезный для идентификации вашего выбора) (все элементы Select, являющиеся дочерними элементами вашего класса Vector, являются строками)

rowNumber: int

columnNumber: int

usedFilter: String

usedGroupBy: String

usedHavingCaluse: String

usedOrderBy: String

tableName: String

GetId () * * один тысяча двадцать-одна

getRowNumber (): int

getColumnNumber (): int

getUsedFilter (): String

getUsedGroupBy (): String

getUsedHavingClause (): String

getUsedOrderBy (): String

getTableName (): String

Выбрать (tableName: String, фильтр: String, groupBy: String, withCaluse: String, orderBy: String, столбцы: Vector)

2.) У меня был класс для прямого взаимодействия с базой данных, назовем его DataAccessLayer. Давайте посмотрим на структуру этого класса:

DataAccessLayer

connect (...): логическое значение

отключить (...): логическое

use (databaseName: String): логическое

selectedData: Vector (фактически это набор из Select)

createSelect (tableName: String, filter: String, groupBy: String, withCaluse: String, orderBy: String, columns: Vector): логический (для определения его успешности)

deleteSelect (ID): логическое значение

insert (tableName: строка, столбцы: вектор, значения: вектор): логическое значение

update (tableName: String, columnsToSet: Vector, значения: Vector, filter: String): логическое значение

delete (tableName: String, filter: String): int (сколько строк было удалено, -1, если Возникло исключение, или просто выбросьте исключение на более высокий уровень)

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

DataAccessLayer ()

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

Выберите 1 <-> n DataAccessLayer

ClassInheritedFromDataAccessLayer расширяет DataAccessLayer

Интерфейс использует ClassInheritedFromDataAccessLayer1, ..., ClassInheritedFromDataAccessLayern, DataAccessLayer.

Таким образом, ваш проект будет: - управляемый - приказал - легко планировать - легко реализовать - легко модифицировать - легко понятны другим людям

Надеюсь, это поможет,

Привет.