Вариант использования к Диаграмме классов - Как делают меня?
Я хотел бы Ваше руководство о том, как создать классы и их отношения (обобщение, ассоциация, агрегирование и состав) точно из моей схемы Варианта использования (посмотрите ниже).
Я пытаюсь создать эту диаграмму классов, таким образом, я могу использовать ее для создания простого приложения PHP онлайн, которое позволяет пользователю регистрировать учетную запись, вход в систему и выход из системы, и хранилище, искать и получать данные из базы данных MySQL.
Мои классы корректны? Или я должен создать больше классов? И если так, что пропускают классы? Какие отношения я должен использовать при соединении регистра, входа в систему, выхода из системы, search_database и add_to_database пользователям?
Я плохо знаком с шаблонами разработки и диаграммами классов UML, но от моего понимания, отношения ассоциации связывают один объект с другим объектом; отношения агрегирования являются специальным видом ассоциации, которая позволяет "части" принадлежать больше чем одному "целому" (например, кредитная карта и ее PIN - Класс контактов может также использоваться в классе дебетовой карты); и отношения состава являются специальной формой агрегирования, которое позволяет каждой части принадлежать только одному целому за один раз.
Я чувствую, что не учел некоторые классы или что-то, потому что я просто, может казаться, не нахожу отношения от своего понимания отношений.
Любая помощь будет действительно цениться.Заранее спасибо.
СХЕМА ВАРИАНТА ИСПОЛЬЗОВАНИЯ
Объяснение варианта использования:
Зарегистрируйтесь Любые пользователи могут создать учетную запись путем регистрации. Система проверит имя пользователя и пароль и отклонит их, если или они будут отсутствовать или если имя пользователя уже взято.
Войдите в систему Любые пользователи могут войти в систему, только если они уже зарегистрировались. Их имя пользователя и пароль будет проверено таким же образом, регистрируя учетную запись.
Поисковая База данных Любые пользователи будут beable для ввода searchkey строки типа данных и системы, будет открывать базу данных, искать searchkey и возвращать TRUE или FALSE в зависимости от того, был ли searchkey найден, и закройте базу данных.
Добавьте данные к базе данных, Все пользователи смогут ввести некоторые данные, система будет открывать базу данных, хранить данные, возвратить TRUE или FALSE в зависимости от того, хранились ли данные, и закройте базу данных.
Выход из системы пользователь нажмет кнопку выхода из системы и систему, выйдет из системы пользователь
Удалите из базы данных Only, администратор может удалить данные из базы данных.
Удалите обычных пользователей, Только администратор может удалить обычного пользователя
ДИАГРАММА КЛАССОВ
3 ответа
Во-первых, если вы полны решимости пойти по пути моделирования, я бы порекомендовал книгу Розенберга и Стивенса Use Case Driven Object Modeling with UML . Это проходит через процесс в точности то, что вы описываете: как писать хорошие варианты использования, строить из них диаграммы классов, строить из них диаграммы последовательности и (да-да!) Кодировать это в работающее программное обеспечение. Возможно, вы сможете узнать о процессе ICONIX в Google и найти подробную информацию в Интернете.
Некоторые случайные комментарии:
- «Диаграмма» любой диаграммы вариантов использования - это наименее полезный аспект вариантов использования. Каждый овал на схеме представляет собой параграф или два текста, рассказывающих историю происходящего. Этот текст действительно полезен.
- Обычно у вас есть классы для существительных в ваших вариантах использования и методы для глаголов. Некоторые из ваших глаголов (
Add_data_to_database,Logout, ...) являются классами, а не методами.- Иногда такие вещи возникают, если вы используете фреймворк, поощряющий использование шаблона команд. Даже в этом случае командные объекты могут / должны просто вызывать методы ваших реальных классов.
- Я бы сказал, что вам не хватает некоторых существительных (какие данные вы храните в базе данных?). Если бы у вас было это, вы бы обнаружили отношения между
Userи этими классами данных.
Почему бы не скачать EssWork. Esswork - это проект с открытым исходным кодом, основанный на гибкой практике, разработанный Иваром Якобсоном Интеллектом, парнем, создавшим варианты использования ... там есть практика, которая называется «Практика основных вариантов использования», она описывает, как вы относите требования к классам ...
Кажется, что с диаграммой UC нет никаких проблем.
Я согласен с комментарием Дэйва. Кроме того, я также хочу показать вам свою идею по созданию соответствующей диаграммы классов для такой UC-диаграммы. (Показаны только основные моменты)
