第四、五单元 类图对象图和包图.ppt

* * 4.2 类图 关联关系的不同重数与代码的映射 （1）单向关联（0..1） public class Account { private DebitCard theCard; public DebitCard getCard( ) { return theCard; } public void setCard ( DebitCard card ) { theCard = card; } public void removeCard ( ){ theCard = null; } } 4.2 类图 关联关系的不同重数与代码的映射 （2）单向关联（1） public class Account { private Guarantor theGuarantor; public Account (Guarantor g) { if (g = = null) { }; theGuarantor = g ; } public Guarantor getGuarantor ( ) { return theGuarantor ; } } 4.2 类图 关联关系的不同重数与代码的映射 （3）单向关联（0..*） public class Manager { private Vector theAccounts; public void addAccount (Account acc) {theAccount.addElement ( acc ) ;} public void removeAccount (Account acc){theAccount.removeElement(acc); } } 4.2 类图 关联关系的不同重数与代码的映射 （4）双向关联（1，0..1） public class Account { private DebitCard theCard; public DebitCard getCard( ) {return theCard;} public void addCard ( ) { theCard = new DebitCard ( this ) ; } } public class DebitCard { private Account theAccount ; DebitCard (Account a) {theAccount = a ;} public Account getAccunt ( ) {return theAccount} } 4.2 类图 关系 泛化关系：一个类（子类）继承另外的一个类（超类）的同一功能，并增加它自己的新功能。 泛化关系就是用来表示类与类、接口与接口之间的继承关系的。关系中的实线空心封闭箭头由子类指向父类 例如，个人客户和团体客户都是客户，可以把他们的相似之处放到客户类(超类型)中，用个人客户和团体客户作为它的子类型。 4.2 类图 使用类图的几点建议 1. 在项目初始阶段，不要使用所有的符号，应从简单的概念开始。 2. 不同的开发阶段应用不同的观点画类图：分析阶段用概念层类图；设计阶段用说明层类图；实现阶段用实现层类图。 3. 使用类图的最大危险是过早地陷入实现的细节，应将重点放在概念层和说明层。 4.2 类图 类图的建模分析步骤 （1）寻找出需求中的名词(候选对象)。 （2）合并含义相同的名词，排除范围以外的名词，并寻找隐含的名词。 （3）去掉只能作为类属性的名词。 （4）剩下的名词就是要找的分析类（候选类)。 （5）根据常识、问题域、系统责任确定该类有那些属性。 （6）补充该类动态属性，如状态、对象间联系（如聚合、关联）等属性。 （7）从需求中的动词、功能或系统责任中寻找类的操作（候选操作）。 4.2 类图 类图的建模分析步骤 （8）从状态转换，流程跟踪、系统管理等方面补充类的操作 （9）对所寻找的操作进行合并、筛选。 （10）对所寻找的操作在类间进行合理分配（职责分配），形成每个类候选操作。 （11）补充每个类的的分析文档，为类的进一步设计打下基础。 4.2 类图 会议管理系统类图中的分析过程－（1）主要分析类 （1）主要分析类 每一系统都有一个或几个主要分析类，并且有一些其他类围绕在这个类的周围，辅助主要分析类完成它的生命周期。 例如，对于会议管理子系统来讲，显然会议是主要的分析类，主要分析类是在需求采集阶段就要确定的类。 4.2 类图 会议管理系统类图中的分析过程—（2）辅助类 首先从原始需求文档中找到名词和隐含的名词 在软件开发以后，这些名词可以演化为类或类的属性，对于会议管理系统来讲，前半部分