Как придумать классы по описанию проекта

Здравствуйте, мне нужно построить UML диаграмму классов, но не могу правильно их подобрать.
Суть: мой проект моделирует сервисы образовательной навигации, будет реализовано в виде сайта на asp.net mvc. Человек сможет воспользоваться образовательным навигатором который на основе цели пользователя и его текущих знаний, предоставит ему рекомендованный путь обучения, со ссылками на различные образовательные материалы.

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

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

0

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

Для начала, добавьте класс для каждой сущности, которая встречается в описании проекта.

0

Вот я подумал так: Профессия(аргументы: название, описание, массив/список путей достижения-(?)), Путь(аргументы:название, описание, массив/список глав-(?), финальный тест), Глава(аргументы: название, описание, тест, массив/список материалов), Материал(аргументы: название(например, книги), ссылка на источник, описание (возможно, при наведении)), Тест (аргументы: название, описание, ссылка на тест).
Хотя у теста и материала получается одинаковая структура
Из методов ничего пока кроме геттеров и сеттеров не придумал
Насчет (?) - не уверен, так ли надо сделать.
Уверен, что нужно еще додумывать что-то, но пока в голову не лезет

Добавлено через 6 минут
(тест не тот, что определяет начало, а тот, что для самопроверки во время изучения уже)
Пытаюсь вот еще какие-то придумать(кроме вопросов с собеседований и вакансий).

Добавлено через 1 минуту
И насчет класса пользователя тоже думаю, ведь при создании проекта на асп.нете мвс уже создается какая-то система авторизации и пользователей, наверное прийдется брать оттуда пользователя за основу, боюсь чтобы не пришлось писать собственную

0

Shamil1, что-то такое пока сделал, не уверен как соединять админа,юзера с остальными, ведь у меня не консольное приложение, чтобы, например, сделать метод юзера showProfessions(), поэтому пока так оставил
И админ же изменяет базы данных, а не классы, поэтому не знаю как и нужно ли соединять его с ними

Миниатюры

 

0

Theme и Route - неудачные названия. Первое ассоциируется со стилями (внешним видом сайта), а второе - с маршрутизацией (в ASP.NET MVC есть такой класс).

Не понятно, зачем нужен класс Administrator. Идея о том, что есть особая порода пользователей - администраторы - особенностью которой является врождённая способность добавлять/удалять пользователей, лично для меня выглядит очень странной.
Есть пользователи. Есть действия. Некоторые пользователи имеют разрешения на некоторые действия.

Во всех классах не хватает самого главного свойства - уникального идентификатора (обычно тип Guid).
А методы в этих классах вообще не нужны. Есть сущности. У них есть свойства. Действия в общем случае не зависят от сущностей (в разных системах над одними и теми же сущностями выполняются разные действия), поэтому пусть за них отвечают другие классы. Я бы добавил один обобщённый класс Репозиторий, отвечающий за CRUD и несколько классов Служба, отвечающих за действия с сущностями и использующие класс Репозиторий для взаимодействия с БД.

Вы начинайте писать код. По ходу дела добавите то, чего будет не хватать. С технологией CodeFirst это не проблема.
Для начала можно сделать:
интерфейс IGuidId, обещающий наличие у сущности поля Id типа Guid
класс User, реализующий этот интерфейс
класс GuidIdRepository<TEntity>, умеющий выполнять GRUD операции над сущностями, реализующий этот интерфейс
класс UserService, с методами для действий над пользователями - получения списка, добавление, поиск и т.п.

Можно пронаследовать UserService от обобщённого EntityService<TEntity>, содержащего одинаковые действия над разными сущностями - создание и т.п.). Сразу все методы для UserService писать не надо. Оставьте его пустым и переходите к написанию первой страницы (например, для вывода списка пользователей или для добавления пользователя). Когда в процессе написания контроллеру понадобится что-то сделать с пользователями, добавляйте соответствующий метод в UserService (или в EntityService<TEntity>).

1

Shamil1, Спасибо, если еще будут вопросы, обращусь

0

Shamil1, Еще раз здравствуйте! Вот я опять с этой темой, но всё изменилось: в универе изучаем ООП проектирование, мне выпала эта тема "Моделирование сервисов образовательной навигации".
Суть нашего проектирования в том, чтобы не сделать потом все функциональным (например, если тема "умный дом", мы не будем на втором курсе обучения создавать реальные системы для управления домом), нам нужно правильно спроектировать всё в общих чертах. К примеру, у темы "smart медицина" будет простая структура: есть общий класс смарт больница ( со своими атрибутами и методами), есть классы докторов, пациентов, смарт кроватей, смарт туалетов и тд. (звучит конечно, так себе, но так и нужно).

Как понятно, это всё функционировать будет как модель, реально программировать какие-то кровати не нужно. И вот я подошел к своей теме.

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

Вот так, мне казалось просто, но преподаватель посмотрев на мою UML диаграмму сказала, что классов без атрибутов или методов быть не может, тогда это интерфейсы и структуры, а их изучать у нас нет времени, сайт делать нельзя, так как нужно программировать это все параллельно на C++ и C#, а на плюсах я бекенд не напишу. Так что пришлось все переделывать под консоль.
Что подскажите делать, как правильно спроектировать? Может какую-то другую идею? Свои диаграммы для консольной версии программы прилагаю:

Миниатюры

   

0

Сообщение от alexboliam преподаватель посмотрев на мою UML диаграмму сказала, что классов без атрибутов или методов быть не может

Сложность задачи нелинейно зависит от размера. Чтобы уменьшить сложность больших задач, их делят на задачи меньшего размера. (Та же идея используется в методе "Разделяй и властвуй", например, сортировка слиянием). В этом заключается суть всех парадигм программирования, включая ООП.
Для кого-то ООП - это инструмент, способ делить задачу на более простые. Для кого-то ООП - это заповеди, которые нельзя нарушать. По моему опыту преподавать программирование идут те, у кого не получается писать программы.

Ваш преподаватель предлагает Вам устаревший подход проектирования бизнес-логики (называется "активная запись" active record). Этот подход возник как следствие механического переноса идей из "ООП для проектирования пользовательского интерфейса" на проектирование бизнес-логики. Но довольно быстро выяснилось, что подход, хорошо зарекомендовавший себя для решения первого класса задач (собственно, для их решения он и был придуман), плохо подходит для других задач. В частности, плохо поддаётся масштабированию (те есть, годится только для очень простых задач).

Сообщение от alexboliam Что подскажите делать, как правильно спроектировать?

Я могу подсказать, как неправильно спроектировать - чтобы удовлетворить Вашего преподавателя.
Надеюсь, она не возражает против использования обобщённых (generic) классов. Если возражает, то замените их копированием соответствующей функциональности во все соответствующие классы.

Как переделать описанную ранее структуру:
Создаём базовый класс для всех сущностей "Document<TEntity> where TEntity : Document<TEntity>, new()". Помещаем в него свойство Id типа Guid и все методы из GuidIdRepository<TEntity>. От него наследуем классы для отдельных сущностей. Например, "User : Document<User>".
Методы из классов служб распихиваем по классам сущностей.

Добавлено через 3 минуты
з.ы. В NavigationSystem добавьте свойство (только для чтения) CurrentUser, чтобы преподаватель на сказала, что "это интерфейс, так как нет свойств".

0