Требуется критика для UML-обзора структуры проекта
Примечание: я не смог заставить форматирование работать внутри блока кода для курсива и прочего, поэтому есть некоторая временная разметка, чтобы попытаться передать смысл. Также не будет работать экранирующий символ html для заполненного ромба. Надеюсь, это все еще имеет смысл
У меня есть проект в моем классе Java, где мне нужно создать программу с графическим интерфейсом, которая в основном моделирует небольшую базу данных инвентаризации. Основная задача - создать его объектно-ориентированным способом. Поэтому, прежде чем приступить к работе, я наметил упрощенный UML, который просто определяет классы, состав и наследование без определения переменных или методов - их реализация будет простой, но я хочу убедиться, что у меня есть надежная иерархическая структура хорошего объектно-ориентированного проектирования. прежде чем я начну добавлять в деталях.
Так что, если вы могли бы, пожалуйста, потратить время на просмотр структуры моего проекта и дать мне знать, есть ли что-то, что я должен изменить, опустить или добавить.
Проект будет в основном временным приложением для магазина видеоигр, которое просто читает и записывает записи в текстовый файл, а администратор, управляющий базой данных, должен иметь графический интерфейс для навигации, добавления, удаления и редактирования записей. Я улучшу его с помощью некоторого отличного функционала, но сейчас я сосредоточен только на том, чтобы убедиться, что моя структура хороша.
**list of classes**
DatabaseRecord <abstract>
VideoGameDatabaseRecord
DatabaseNavigator
Database <abstract>
VideoGameDatabase
Game <abstract>
VideoGame <abstract> (superclass for platform-specific video games)
XBoxGame
PlaystationGame
NintendoGame
etc for all subclasses that would pertain to the needs of the inventory
Я все еще немного новичок в UML-моделировании, поэтому я надеюсь, что правильно использовал условные обозначения, и там, где текстовый UML приводил к невозможности следовать соглашениям, я надеюсь, что значение по-прежнему ясно с "a" и "c" внутри алмазов для обозначения агрегации или состава, и заглавной буквы "А" для обозначения абстрактного класса (курсив не будет отображаться внутри уценки кода)
------A----- 0..* ----------A-------- ----A---
| Database | <c>------------- | DatabaseRecord | | Game |
------------ ------------------- --------
^ ^ ^
| | |
| | |
--------------------- 0..* ----------------------------- 1 ------A------
| VideoGameDatabase | <c>------- | VideoGameDataBaseRecord | <a>-------- | VideoGame |
--------------------- ----------------------------- -------------
<a> ^ ^ ^
| | | |
1 | | | |
----------------------- -------------| | |
| DatabaseNavigator | | XBoxGame | | |
----------------------- -------------- | |
-------------| |
| PS2Game | |
-------------- |
|
--------|
| etc. |
---------
Опять же, я ищу только руководство по иерархии, дизайну ООП, составу и т. Д. Структуры моей программы. то есть должен ли он быть абстрактным, должен ли это быть интерфейсом, должен ли я добавить больше / меньше уровней подклассов и т. д. Я уверен в надежном создании кода, но мое понимание и знание принципов разработки ООП все еще недостаточно хороши.
Заранее спасибо за помощь!
2 ответа
- "Я улучшу его с помощью великолепной функциональности, но сейчас я сосредоточен только на том, чтобы убедиться, что моя структура хороша". Это означает, что вы должны быть уверены, что она легко справится с вашими замечательными функциями.:-)
Aggregationможет быть трех видов - ни одного, общего или составного. поговоркаaggregationвместоsharedили жеshared aggregationплохая ошибка Увы, широко распространен из VP-UML инструмент.- Для Абстрактного обычно курсив используется для написания имени.
- Это гораздо более серьезная проблема: у вас нет разных линий для
associationsа такжеgeneralizations, Поэтому практически невозможно понять вашу схему. Но если я возьму, что все стрелкиgeneralizations,... это имеет смысл! Но на самом деле лучше использовать какой-нибудь бесплатный инструмент для рисования. Общественная версия VP-UMP, например. Или бесплатный папирус на Затмении. - оба ваши
shared aggregations(позвольте мне назвать их правильно, пожалуйста) странно:- Левый просто не понятен - разрешается писать ромб на одном конце и разрешать кратность 1 на другом (общие агрегации не определены строго в стандарте UML), но такое необычное использование должно быть объяснено. Если ваш навигатор БД работает со многими базами данных, ромб должен быть на своем конце нормально.
- Правильный написан обычным способом, но я не могу понять смысл под ним - как может быть, что один VideoGameDataBaseRecord имеет много игр? Я не ловлю логику. Не могли бы вы починить или объяснить? Я думаю, что должна быть нормальная связь с
noneaggregation, односторонний или двусторонний, с 0..1 на концах.
- Мне очень жаль, но я не понимаю, что в
etc.Если в нем есть что-то неизвестное, как вы можете быть уверены, что оно получено из класса Game? Обычно вещи, которые вы еще недостаточно формализовали, просто выводятся из диаграммы.
Я думаю, что вы смешали логику и модельные представления только на одной диаграмме. Говоря о терминах ядра / бизнес-логики, ваша диаграмма должна содержать только сущности Store, VideoGame... В более глубоком слое вы бы смоделировали, как сохранить это, вы бы говорили о базе данных, записях...
Итак, сначала ваша бизнес-модель может быть такой простой:
Когда у вас есть понятия "магазин", общий тип для продажи и видеоигра, которая является конкретным предметом для продажи. В общем, сочинение предпочтительнее наследования, поэтому вместо NintendoGame, PS2Game... в качестве подтипа я смоделировал его с помощью console имущество.
Тогда это когда вы сохраняете модель (в файл, дБ и т. Д.). Дело в том, что для этого у вас есть отдельный слой в приложении. Этот слой будет отвечать за сериализацию VideoGame в реестр и наоборот. Вы также можете иметь другую диаграмму классов или просто пару классов, отвечающих за IO.
PS: я не знаю, какова цель DatabaseNavigator поэтому я проигнорировал в своем ответе.