поместить поведение в правильный класс при рисовании диаграммы класса UML

Question

это сценарий небольшого офиса. есть программные проекты и есть менеджер. менеджер отвечает за управление этими проектами

менеджер может выполнять следующие действия

• создание проектов //createProject()
• удалить выбранные проекты //deleteProjectById()
• редактировать детали выбранного проекта //updateProjectById()
• обновить свою информацию //updateManagerInfo()

• добавить квалификации //addQualificationToManager()

• назначить сотрудников для проекта //assignemployees()

• проверить срок выполнения проекта //isProjectDeadlinExceed()

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

атрибуты класса менеджера

name
genaralInformation
educationalQualifications
salary

атрибуты класса проекта

projectid
projectname
deadline
budget
assignedEmployeeList

чтобы полностью нарисовать диаграмму классов uml, мне нужно разместить методы выше (действия, которые может выполнять менеджер) среди класса менеджера и класса проекта

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

createProject()
deleteProjectById()
updateProjectById()
updateManagerInfo()
addQualificationToManager()

но я не уверен, где поставить ниже методы?

assignemployees()
isProjectDeadlinExceed()

потому что вышеуказанные действия могут выполнять менеджер, а также вышеуказанные методы работают с атрибутами (состоянием) класса проекта куда эти методы ставить ???

Answer 1

Диаграмма вариантов использования показывает ваш сценарий с точки зрения целей пользователя, помогая вам спроектировать вашу систему классов. Это не означает, что каждый сценарий использования должен отображаться как метод актера, выполняющего действие (даже актер не заслуживает класса!).
На мой взгляд, в вашем сценарии Manager вызывает методы класса Project для выполнения своих функциональных требований. Делая ссылку на следующую диаграмму классов

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

Answer 2

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

public interface ProjectPortfolio {
    Project createProject(...);
    Project findById(...);
}

public interface Project {
    void delete();
    void update(...);
    void assignEmployees(...);
    boolean isDeadlineExceeded();
}

public interface Manager {
    void updateInfo(...);
    void addQualification(...);
}

Мне кажется, вы пытаетесь поместить методы в Manager, потому что менеджер - это тот, кто их делает. Обычно методы должны быть на объекте, на который воздействуют («субъект» действия).

Так, например, если вы хотите delete() проект, этот метод должен быть (исключая другие требования) для объекта Project.

Поэтому, когда вы хотите createProject(), вы должны найти подходящий «предмет», где эта операция имеет смысл.

Думайте об этом так: вы находитесь внутри приложения, вы окружены объектами, которые являются вашими друзьями, с которыми вы пытаетесь заставить приложение работать. Поэтому вы должны спросить себя: К кому я могу обратиться, чтобы помочь мне? . Например, для createProject() я могу попросить одного из моих Manager друзей по объекту? Нет , потому что эти ребята просто представляют некоторых реальных людей, они не знают, как создать проект. И Project объекты представляют один уже созданный проект. Поэтому вы должны написать нового друга по имени ProjectPortfolio, который знает обо всех проектах. :)