UML地址簿

UML地址簿,uml,addressbook,Uml,Addressbook,大约10天前,我开始学习UML语言,在所有的课程中都迷失了很多,我试着自己练习,而不是阅读“理论”。我发现有人建议调查一个旧的已完成的地址簿项目,该项目缺少1张CRC卡 和1类设计 他也缺少“另存为…”图,但我自己做的 有谁能帮我做CRC卡和班级设计或者建议我怎么做。 谢谢 CRC卡不属于UML。如果你想了解UML,你应该练习UML 在创建类图之前定义类是非常糟糕的。在UML中称为类的东西称为组件。不要把它们混在一起 对于一个简单的学校项目,通常的UML过程是用例(可能有状态图元素)->组件图

大约10天前,我开始学习UML语言,在所有的课程中都迷失了很多,我试着自己练习,而不是阅读“理论”。我发现有人建议调查一个旧的已完成的地址簿项目,该项目缺少1张CRC卡 和1类设计

他也缺少“另存为…”图,但我自己做的

有谁能帮我做CRC卡和班级设计或者建议我怎么做。 谢谢

  • CRC卡不属于UML。如果你想了解UML,你应该练习UML
  • 在创建类图之前定义类是非常糟糕的。在UML中称为类的东西称为组件。不要把它们混在一起
  • 对于一个简单的学校项目,通常的UML过程是用例(可能有状态图元素)->组件图(可能通过部署和/或通信图开发)->活动/序列图(如果你有一些非平凡的算法)->类图。对于Android来说,对象或复合结构图也很有用
  • 这些图表几乎没有自然的层次结构。您可以在用例图上使用类,也可以在复合结构图中使用状态。但不要从那开始,要等上两年。开始时,试着学习使用纯图表,以便知道如何正确使用它们,如何按照它们的方式思考。UML用户的主要、最重要和广泛传播的错误是图混合的混乱
    不幸的是,这不是在线课程。“我确实遇到了这个问题,需要一个解决方案”。@ThomasKillian是对的,这不是在Stackoverflow上要问的问题。对不起,我把它标为“太宽了”。但不要放弃使用Stackoverflow。为了帮助您,第一个练习很简单,CRC卡是定义类的一种非常“非正式”的方式。例如,“将责任分配给各个类”意味着向类添加方法。对于“AddressBookController”类的“允许用户执行添加人员用例”职责,这意味着向该类添加“addUser()”方法。要了解更多信息,你应该阅读维基百科的文章。但是无论如何,你用简单的方法处理UML是正确的。CRC卡是序列图的可行替代品,因为它们不涉及对象交互。它侧重于分析和责任识别,不直接涉及对象模型。放弃理论方面:方法是类或接口承担责任的一种方式。