Oop 在绘制UML类图时,将行为放在正确的类中

Oop 在绘制UML类图时,将行为放在正确的类中,oop,behavior,operation,Oop,Behavior,Operation,这是一个小型办公室的场景。 有软件项目,也有管理者。 经理负责管理这些项目 经理可以执行以下操作 创建项目//createProject() 删除所选项目//deleteProjectById() 编辑所选项目的详细信息//updateProjectById() 更新他的信息//updateManagerInfo() 添加资格//addQualificationToManager() 为s项目分配员工//assignemployees() 检查项目截止日期//isProjectDeadlinE

这是一个小型办公室的场景。 有软件项目,也有管理者。 经理负责管理这些项目

经理可以执行以下操作

  • 创建项目
    //createProject()
  • 删除所选项目
    //deleteProjectById()
  • 编辑所选项目的详细信息
    //updateProjectById()
  • 更新他的信息
    //updateManagerInfo()
  • 添加资格
    //addQualificationToManager()

  • 为s项目分配员工
    //assignemployees()

  • 检查项目截止日期
    //isProjectDeadlinExceed()
我想在uml类图中对这个场景建模 下面是manager、project类及其属性

管理器类属性

name
genaralInformation
educationalQualifications
salary
projectid
projectname
deadline
budget
assignedEmployeeList
项目类属性

name
genaralInformation
educationalQualifications
salary
projectid
projectname
deadline
budget
assignedEmployeeList


为了完整地绘制uml类图,我需要在manager类和project类之间放置上述方法(manager可以执行的操作)

i、 我确信以下方法属于manager类 因为经理只能执行这些操作,而且这些方法不涉及更改项目类属性的状态

createProject()
deleteProjectById()
updateProjectById()
updateManagerInfo()
addQualificationToManager()
但我不确定下面的方法放在哪里

assignemployees()
isProjectDeadlinExceed()
因为上面的操作可以执行manager,而且上面的方法也可以处理项目类的属性(状态)
将这些方法放在哪里?

我认为您至少缺少一个抽象,即所有项目的集合。让我们把它称为
项目组合
。然后我可能会采用这种设计(java语法):

公共界面项目组合{
项目创建项目(…);
findById项目(…);
}
公共接口项目{
作废删除();
无效更新(…);
使雇员无效(……);
布尔值IsDeadLineExcepended();
}
公共接口管理器{
void updateInfo(…);
无效资格(…);
}
在我看来,您正在尝试将方法放入
管理器中,因为管理器就是执行这些方法的人。通常,方法应该针对正在被操作的对象(操作的“主体”)

因此,例如,如果您想要
delete()
一个项目,则该方法应该(除非有其他要求)在
project
对象上

因此,当您想要
createProject()
时,您必须找到一个合适的“主题”,该操作在这里是有意义的

这样想:你在应用程序内部,被对象包围着,对象是你的朋友,你正试图让应用程序工作。所以你应该问问自己:我能请谁来帮我?。例如,对于
createProject()
我可以问一下我的
经理
对象朋友吗?不,因为这些人只是代表一些真实世界的人,他们不知道如何创建一个项目。和
Project
对象表示已创建的单个项目。因此,你必须写一个名为
ProjectPortfolio
的新朋友,他了解所有项目:

用例图以用户目标的角度显示了您的场景,帮助您设计类系统。这并不意味着每一个用例都必须映射为实现动作的参与者的方法(即使参与者不应该拥有一个类!)
在我看来,在您的场景中,经理调用项目类中的方法来满足他的功能需求。参考下面的类图


您可以看到功能需求得到了满足。例如,在该类系统中,要将员工添加到项目中,经理只需调用project中的方法,并在其拥有的项目列表中进行选择。

[[因为经理就是执行这些操作的人。通常方法应位于正在执行操作的对象(操作的“主题”)上。]]==>但类根据oop的定义,类中的方法是类可以执行的操作-是。。。??如果没有,请提供定义及其来源是的,方法是类可以执行的操作。但是,类可以执行的操作不一定是类所代表的实体可以执行的操作。因此,“经理可以删除项目”并不意味着
manager
应该有
deleteProject()
方法。这意味着
项目
应该有一个
delete()
方法,因为
项目
是操作的主题。不幸的是,对于“oop的定义”没有一个公认的“权威”来源,因此引用其他人的话就没有什么意义了。是的,你是对的。。。。但是为什么当我们绘制uml类图时,所有类可以执行的操作都被归类为方法。互联网上有很多这样的类图。我不确定你在问什么,你能重新格式化吗?thx寻求帮助。。。。我找到了一个解决之前在这个线程中提出的问题的方法