UML建模教育课件.ppt

*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,UML建模PPT讲座,UML建模,一种系统开发方法应由建模语言和开发过程组成。,建模语言是设计的表示符号,而过程则是描述如何进行开发所需的步骤。,UML的开发过程包括需求获取、系统分析、系统设计、实现和测试5个步骤。,第一阶段,需求获取,需求获取,1.需求获取,系统开发的第一步工作就是进行需求收集。,需求收集从调查开始。,调查是为了发现了系统中的参与者和高层用例。,2.建立用例图,为了能够准确的描述用户的需求，就要使用用例。,首先需识别用例，然后才能建立用例。,确定系统边界,在确定参与者和用例的过程中也就确定的了系统的边界，,用例是系统之中的，,参与者是系统外部的。,（1）识别参与者,一般地，可以通过以下问题去寻找用例图中的参与者：,谁,是系统的主要使用者？,谁从系统获取信息？,谁向系统输入信息？,谁从系统中删除信息？,谁需要系统支持他们的日常工作？,谁来维护、管理系统使其能正常工作？,系统需要控制哪些硬件？,系统需要与其他哪些系统交互？,对系统产生的结果感兴趣的是哪些人或哪些事物？,（1）识别参与者,除把直接使用系统的人员确认为参与者外。,凡是与系统进行信息交换（包括数据信息和控制信息交换）的外部事物均可被确认为参与者。,外部事物指的是：人员、设备、外部系统、事件。,识别用例,基于参与者识别用例,l）识别出与系统有关的参与者。,2）对每个参与者，识别出他们发起或参加的过程。,3）对每个参与者，识别出向他们传递信息的过程。,可列一个表,为编制用例准备一个表,参与者,向,参与者,传递信息的,服务或事件,用例名,简短的描述,业务目标,参与者职责用例,参与者名：,customer（客户）,参与者职责：,定货、退还定货、查询定单。,参与者检查问题：,使用系统主要功能；,对系统运行结果感兴趣。,参与者职责用例,从发货者（Shipper）识别,发货者要求系统提供什么功能？,仓库存储物品的管理；,发货处理。,发货者需要做什么？,从所有的定单中按顺序挑选出优先级较高的定单来发货；,在发货单上签上发货的品名、数量。,发货者需要阅读、创建、销毁、更新或存储系统的某些信息吗？,是，发货者需要阅读、更新仓库存储物品信息和顾客信息。,系统中的事件一定要告知发货者吗？,仓库有关物品短缺（发货者报告）,识别用例,通常，在确定用例前应考虑以下问题：,参与者需要使用系统吗？,对于各个参与者，哪些任务会涉及到系统？,系统与参与者之间有哪些交互？,系统需要何种输入输出？输入从何处来？输出到何处去？,识别用例,用例将支持和维护的系统功能是什么？,必须提醒参与者的系统事件有哪些？,参与者必须提醒系统事件有哪些？怎样把这些事件表示成用例中的功能？,用例的粒度,不要把用例划分的过大，也不要把用例划分得过于琐碎细小。,通常,用例的行为都是用事件流描述，并且会产生显著的目标。这是用例粒度的底线。,即每个用例都应当是一个完成有意义的业务目标的事件流集合。,用例过细,一般认为合适的把握,确定关系,确定,用例的最后一个步骤就是描述关系。,关系包括：,参与者与用例之间的关系,用例之间的关系,参与者之间的关系。,关系类型包括：,关联关系、包含关系、扩展关系和泛化关系。,库存管理用例图,发现,包含关系,系统分析员应该检查模型中的每个用例，提炼出公共的部分，创建单独的用例，并用,包含,关系与基本用例连接。,这样会降低原来的用例复杂性，增加用例的复用性。,发现,扩展关系,系统分析员检查每个用例，如果发现一个用例比较大，并且其中既包含了一般处理又包含了特殊处理，那么就应该将特殊处理的部分提取出来，创建单独的用例，并且用扩展关系连接这个用例与相关的用例。,这样会降低原来的用例复杂性，处理更简单。,参与者泛化关系,有时参与者之间存在一些共性，为了便于描述参与者之间的区别，使用参与者泛化关系来描述参与者之间的关系。,用来判断应使用哪种关系的规则：,当处理一般与特殊的关系时，采用泛化关系。,当避免两个或多个例出现重复描述时，采用包含关系,当描述用例的,某种异常,动作。,采用,扩展,关系,用例的优化,用例是否有重复的功能出现（合并）,是否有功能上的包含（合并）,优化原则：,独立,集中,用例的优化,合并,同类或相似的用例合并,例：电子邮件撰写、邮件查看、合同录入、合同修改、合同删除、合同查看,功能性合并,文档录入（电子邮件撰写、合同录入）,文档查看（邮件查看、合同查看）,业务性合并,邮件管理、合同管理,用例的优化,拆分,对较大的或复杂的用例,用例描述，描述到了第四级，仍无法描述清楚，需用例拆分,主流子流分支流子分支流,用例的优化,拆分例子,管理用户包括处理：添加用户、修改用户信息、删除用户、查找用户、修改用户口令、变更用户级别,拆分为：维护用户信息、管理用户权限两个用例（按业务相关性）,3.,定义用例的优先级,定义用例的优先级是为了区分需求的优先级。,区分用例的优先级是为了确定哪些用例要先行开发，哪些用例要放在随后的迭代工作中开发。,区分的依据是前面活动生成的概要用例模型、补充需求说明和术语表。,4.,用例描述,详细具体的描述一个用例还要使用用例描述。,用例描述是采用自然语言描述一个用例的功能。,通过用例的事件流完全可以描述系统的功能性需求。,结构化的用例描述文本,描述一个用例，应说明以下细节：,用例名,前置条件（PreConditions）,后置条件（Post-Conditions）,扩充点（Extension Points）,事件流,基流（Basic Flow）,分支流（Subfl,ows）（可选）,替代流（Alternative Flows）,5.确定用户界面,确定参与者如何启动用例，以及用例以什么形式向参与者提供信息，,是在构造用户界面的原型。,这项活动的输入是：用例模型、详细描述的用例描述。,活动的结果是用户界面的简图。,目的是为参与者确定用户界面的外观和感觉。,逻辑用户界面设计,用户界面设计人员逐一检查用例，,为需要构造用户界面的用例确定适当的界面元素。,如菜单、工具栏、对话框等。,界面设计人员通过访谈参与者,，,请他们回答下面的问题：,需要哪些界面元素来启动用例？,用户界面元素之间如何相关？,用户界面看起来应该是什么样的？,应该如何处理这些用户界面元素？,针对所涉及的业务领域，用户对用户界面元素有何特殊要求？,参与者喜欢用哪些用户界面元素完成工作？,界面设计人员通过访谈参与者，,参与者可以激发哪些动作？,在激发用例的动作前需要哪些指南？,参与者向系统提供什么信息？,系统向参与者提供什么信息？,每项输入输出的长度和类型是什么？,用户界面设计人员要确保每个用例都可以通过其用户界面元素进行访问。,建立用例模型时应注意的问题,在大型的软件开发过程中，用例图可以分层建立。,在建模的开始阶段，注意保持用例图是对系统功能需求的高层次刻画，不要对它进行过细的分解。,7.用例的组织,较大的系统往往包含许多用例，为了更好的理解和管理它们，我们可以通过两种方式进行组织：,用“包（Package）”来组织：,用用例的级别层次关系来组织。,产品分销系统用例图总体图,产品分销系统用例图销售中心子系统,第二阶段,系统分析,系统分析,面向对象系统分析的基本任务是：运用面向对象方法，对问题域和系统责任进行分析和理解，对其中的事物和它们之间的关系产生正确的认识，找出描述问题域以及系统责任所需的类及对象，定义这些对象的属性和操作，以及它们之间的静态和动态关系。,最终产生一个符合用户需求，并能够直接反应问题域和系统责任的问题域模型及其详细说明。,系统分析,具体来说，分析阶段的活动主要是：,识别对象；,为对象分类；,确定类的属性和操作；,确定类之间的关系：,确定对象之间的交互：,确定对象的状态变化等。,1.识别对象,识别对象并不是从零开始的工作，应该最大限度地利用已有的劳动成果。比较典型的可利用的资料有。,用例模型和用例描述。,术语表。权威的术语定义集合。,课程注册系统的术语表,课程 课程目录,职员 财务系统,年级 教授,学期成绩单 名册,学生 教学日历,发现对象,从用例模型和用例描述中找出名词来。,但名词可能是参与者、对象和对象属性，所以还要区别它们。,参与者通常比较容易区别，区别对象和对象属性可以通过分析是否有行为，,对象是有行为的，而属性只是单纯的信息。,三种对象类型,分析模型中最常用的,三种对象类型，它们是：,实体（Entity）,边界（Bountary）,控制（Control）,实体对象,实体对象主要的任务是装载信息，同时也具有相关的行为，但是这部分行为主要包括那些和实体对象自身信息直接相关的操作。,可以找到实体对象的几个办法,考虑解决问题所需要的全部数据和行为，然后将数据按相关性分组。,识别出重要的名词，并将它们作为实体对象，然后确定每一个实体对象包含的数据和行为。,列出所有的数据、行为以及听起来很重要的名词，然后将数据和行为分配到不同类型的实体对象中。,识别实体对象可参考下列问题：,识别实体对象可参考下列问题：,该对象是否是某个问题中的重要的名词？,该对象是否包含用来解决系统问题的重要的信息？,该对象是否包含可以解决系统问题的计算或者验证逻辑？,边界对象,边界对象用于描述拟建系统内部运作与外部环境之间的交互。,边界对象主要用于描述三种类型的内容：,拟建系统和用户的界面，,拟建系统和外部系统的接口,拟建系统与设备的接口。,边界对象,通过检查在用例图中的参与者与用例之间的关系，我们可以识别出边界对象。,通常，在分析模型中，每一对参与者用例都构成了一个边界对象。,识别边界对象的可参考下列问题：,识别边界对象的可参考下列问题：,该对象是否描述了必须显示的信息以及必须提供的服务？,该对象是否包含所有的接口设计细节？,该对象是否描述了与外部系统的交互？,控制对象,控制对象用于描述对一个用例所特有的事件流的控制行为。,控制对象相当于协调人,它自己通常不处理具体的任务，但它知道那些类有能力完成具体的任务。,通常一个用例对应一个控制类。,识别控制对象可参考下列问题：,是否对业务逻辑进行控制？,是否将业务逻辑提交给实体对象？,顺序图中的边界对象,控制对象和实体对象,2.描述对象的协作关系,我们还需要详细了解对象在系统中的行为和责任。,责任是响应消息的能力。消息被要求者提出，责任由响应者承担。,确定责任主要根据责任和消息的简明对应关系，所谓找出责任是根据消息的要求定义责任，即用责任满足消息所提出的要求。,对象的行为,对象的行为是通过系统中对象之间的交互以及对象内部状态的转化来表现的。,对象间通过发送消息而产生交互。,同时在一个对象的生命周期内也存在状态的转移以及对事件的响应。,系统动态分析,动态分析的主要任务包括,分析用例的实现过程(要求有详细的用例描述)，从而更好地理解业务流程以及为发现类打好基础；,用于进行动态分析的,UML图包括顺序图、协作图、活动图和状态图。,系统动态分析,建立交互图,交互图表现的是参与者与系统以及系统内部对象之间的交互，,将消息加进交互图时，是在向接收消息的对象指定职责。,顺序图与事件流,用例的事件流中通常有一个基本事件流和多个分支事件流、替代事件流。,每个事件流应用一个顺序图描述。,场景和用例,用例中的场景描述可以是形成系统对象图的一个出发点。它对于系统中对象的发现有极大的帮助。,每个场景代表了用例的一个实例。,对象状态分析,状态图针对单个对象建模，通过分析单个对象的内部状态转换来了解一个对象的行为。,对于有多种内部状态的对象，状态图可以显示对象如何从一种状态过渡到另外一种状态，以及对象在不同状态中的不同行为。,通过分析某一对象的状态变化，为设计此对象的操作提供依据。,步骤,分析一个对象的状态可采用下列：,首先要确定该对象有那些状态是问题域所关心的。当对象处于这些状态中时会有哪些动作。当然，我们只识别哪些问题域所关心的对象的状态。,分析对象生命周期，确定对象活动“历程”；,确定对象生命周期划分策略；,按策略划分阶段描述对象的生命周期；,获取一系列候选状态；,针对每一个候选状态，分析出对象在此状态下的动作。,确定状态图的两种方法：,检查类的属性：考虑一个类的实例在属性值不同时如何表现，因为如果对象的行为表现不同，则其状态也不同。,例：某培训班的人数属性,人,人,某培训班状态图,检查类的关联,检查类的关联：看看关联多重性中带0的关联，0表示这个关联是可选的。,关联存在和不存在时类的实例是否表现相同？如果不同，则可能有多种状态,雇员和公司,雇员（多重性：0）失业（状态）,雇员（多重性：1）有工作（状态）,状态与属性,最后应对得到的对象进行核查,可从对象的状态确定性和状态间的互斥性两个方面进行核查。,所谓对象的状态确定性是指每个状态都可以由对象某些数据属性的组合来唯一确定。,状态间的互斥性是指对象的不同状态间必须是互斥的，这样对象的状态才具有确定性。,原则,原则上一般只对复杂的类创建状态图。,如果类对象有多种状态，每种状态中的表现又大不相同，则可能要对其创建状态图。,实际情况是，许多类根本就不需要状态图。,状态图仅用于文档，而不用于生成代码。从ROSE模型产生代码时，没有任何代码是从状态图的信息中产生的。,3.创建类图,创建类图的工作主要包括：,创建类,标识类之间的关系,分析类的概念,分析模型中的所有类都是”分析类”。,从设计视角看待，“分析类”忽略实现细节，相当粗略。,“分析类”是为定义设计类做准备的。,确定“分析类”,这个步骤就是确定一组备选的、能够执行用例中行为的“分析类”。,在确定“分析类”时，使用三种不同的构造型识别和提取潜在的“分析类”，它们是：,实体类、控制类、边界类。,确定“分析类”,边界类：每个参与者和用例的交互存在一个对应的边界类。,控制类：一般一个用例对应一个控制类。,实体类：这个主要看用例里面用到的持久的数据对象。用到数据库对象时，可能就使用了实体类。,类的获取,类的获取有两种办法：,从用例模型和用例描述中找出名词，有4种名词：参与者、类、类的属性、其他描述性名词。,能够找出实体类,类的获取,另一种是检查交互图中的对象，研究对象具有的共同属性和操作来发现类。,如果采用第二种方法创建类图，需要先创建交互图。,获取边界类,分析参与者与用例对，找出边界类,边界类的复用,控制类的考虑,如果不同用例包含的任务之间有比较紧密的联系，某些控制类可以参与多个用例实现。,当用例事件流非常简单的情况下，控制类的必要性明显降低。,实体类的考虑,实体类的适用范围和生命周期可能超越特定的用例事件流。,实体类通常不是某一特定用例所专有的。,如果实体类B仅仅被另一个类A，并且实体类B不具有明显的行为特征，那么，可以考虑将实体类B作为类A的属性。,无类间关系的分析类图,.识别分析类操作,分析类在顺序图里要承担一定的“职责”,“职责”是对其他对象发送来的消息的响应。也可能是对外部的响应，也可能是维护自身信息所必要的“职责”。,这种行为在分析类演化成设计类时，它可能对应一个或多个具体的类的“操作”。,找出分析类的“操作”,通常有两种方法为类识别,操作,：,第一是责任驱动法,第二是通过交互图,责任驱动法识别类“操作”,责任驱动主要基于两个概念：,第一，一个对象在系统中负有一定的责任，例如它要获得特定的信息（了解的责任）和为其他对象提供特定的信息（做的责任）；,第二，一个对象与其他对象合作来提供所要求的服务。,责任驱动法识别类“操作”,1）责任驱动法为类识别“,操作,”,责任分析的一种有用技术CRC（ClassResponsibilityCollaboration）卡技术。,为类分配操作CRC卡,类的名称,类的名称,责任1,责任1的协作者,对该类的描述,责任2,责任2的协作者,责任3,责任3的协作者,CRC卡,用交互图描述用例来为类识别“操作”,面向对象系统是通过对象间相互发送消息来完成系统功能的。,这些对象间传递的消息就可以映射为对象的操作。,消息和操作,消息和,操作,的概念不同,操作,”对发送过来的“消息”的响应，也就是说它要满足“消息”的具体要求。,“消息”和“,操作,”并不存在一一对应的关系，已有的“职责”就可能满足新的“消息”的要求。,下面几个问题有助于寻找类的操作：,有哪些类会与该类交互，包括该类本身？,该类接收哪些类（包括自己）发送的消息，收到消息之后进行什么处理？,该类向哪些类发送消息，消息的内容是什么，在发送之前该类需要做什么处理？,该类中需要哪些操作来维持自身属性的一致性、完整性，以及自身属性的更新？,简要标识分析类的“操作”,同样要给“,操作,”起一个易于理解的名字，通常要比较简短，,分析类操作的设计,一个类的操作太多或太少都是不合适的，太多说明这个类过于复杂，这时要特别分析一下这个类是否有很高的内聚，通常情况下应该将过于复杂的类拆成多个较小的类。,如果类中的操作太少，有时甚至没有操作，全部都是属性，这时应该分析这个类，判断其是否能够合并到其他类中。,.识别分析类属性,“分析类”要能执行相应的操作，它要依赖于两方面的内容：,一方面是利用它自己保存的信息；,另一方面是利用其他的类。,类自己所能够保存的信息就是它的属性。,获得属性的渠道,属性的来源有许多。获得属性的渠道有几个：,通过查看用例文档，寻找名词。,通常，在用例文档中用名词表示属性，如,“图书的出版社、价格等”。,这些名词中有些是对象；有些是参与者；有些是属性。确定是对象还是属性，答案在于要实现的功能。,获得属性的渠道,通过查看文档，发现系统要收集的信息，这些信息就是类的属性。,如为了下订单而搜集的供货商的姓名、电话及银行帐号等。,如果已经定义了数据库结构，则数据库表中的字段就是属性。,认定一个属性的策略,认定一个属性的策略有：,按一般常识这个类应该具有哪些属性？,在当前的问题域中类应该具有什么属性？,根据系统责任的要求，这个类应该具有哪些属性？,建立这个类是为了保存和管理哪些信息？,类为了在服务中实现其功能，需要增设哪些属性？,有哪些需要区别的状态，是否需要增加一个属性来区别这些状态？,认定一个属性的基本原则。,要确认它相对于相应对象或类的每一个实例都是适用的。,认定的属性应当是一种相对的原子概念，也就是说，不依赖于并列的其他属性就可以被理解。,属性的特点,类的属性不宜太多，如果某个类的属性太多，最好将其分解成更小的类。,同样，属性也不要太少，太少的情况下应进行类的合并。,属性的类型,属性的类型指属性值的类型。,可以是基本数据类型，例如整数、实数、布尔型、字符串型等，也可以是用户自定义的类型。,分析阶段一般不需要确定属性的类型,6.描述类之间的关系,类之间的关系有关联关系、聚合关系、组合关系、泛化关系、依赖关系。,通常按照以下步骤对类之间的关联建模：,1）找出关系。有的类只和其他一个类有关系，而有些类同时和其他多个类存在关系。,在一个面向对象系统中，不存在完全独立的类。,类之间的关系,2）命名关系。最好给每个关系取一个名字以标识出类之间的关系。,通常可以使用动词和动词短语来标识关系。,类之间的关系,3）设置关联重数。关联的重数（MulhpliCity）依赖于系统的具体需求，要根据需求文档的上下文进行分析。,在系统分析阶段，不必特别地考虑重数。,类之间的关系,）设置关联的其他特性。如果需要的话，可以为每个关联设置关联角色名、构造型、限定符等细节。,在上述步骤中，最关键的是第一步找出类之间的关联关系。,寻找关系的具体方法如下：,要寻找关系，可以检查交互图，大多数关系信息已经在交互图中列出。,(1)如果一个类向另一个类发出消息，则它们必有关系，并且通常是关联或依赖关系。,（2）检查类的整体和部分关系。,任何由其他类组成的类都参与聚合.,（3）检查类的泛化关系，寻找相似对象的不同点，将不同的部分下降为特殊的类，将共性的部分上升为基础类，两者之间的关系确定为泛化关系。,发现类关系,报账系统顺序图,借以确定类图关联关系的协作图,确定类图的关联,发现类之间的关系,除了上述方法外，,判断两个类之间到底有没有关联关系，要看它们之间是否存在下表中的关系：,判断两个类之间到底有无关联关系,分 类,举 例,A在物理上是B的一部分,主板主机,A在逻辑上是B的一部分,销售项条目销售项,A在物理上包含在B中依赖于B,商品项商品架,A在逻辑上包含于B中,车次火车时刻表,A是对B的描述,天气预报天气,A是事务B或报告B的一个记录项,项目考试,A为B所知为B所记录录入B中为B所捕获,订票单一一航班旅客名单,A是B的一个成员,教师教研室,A是B的一个组织单元,系大学,A使用或管理B,汽车驾驶员汽车,A与B相互通信,顾客售货员,A与一个事务B有关联,顾客支付项,A是一个事务，B也是一个事务，两者之间有关联,支付项销售项,A是B的一个实例,北京城市,A被B所拥有,公共汽车公共汽车公司,关系查找策略,关系查找的一种策略是从一个用例，找出与这几个类存在的关系，然后再寻找另外一个用例中的关系，直到穷尽了所有的用例为止。,注意,还有一点需要注意的是，两个类之间可能同时存在多种不同的关系。不能因为已经找到了两个类之间的一种关系而忽略了它们存在的其他关系。,关联关系,对于关联关系太多的类要特别注意。,设计良好的应用系统的目标之一是减少系统中的关联。,关联关系太多的类很难复用，维护工作量也会很大。,如果相关联的其他某个类改变，则这个类就可能会受到影响。,两个类的关联关系,两个类的关联关系可以是单向的，也可以是双向的。,相对而言，单向的关联更容易建立和维护，同时也更有利于类的复用。,表现类之间关系的手段,表现类之间关系的手段是绘制类图。,逻辑上每个用例对应一张完整的类图。类图有两种，,简略的类图突出了类之间的关系,详细的类图用标准方式描述了类，在描述类之间的关系的同时，还展示了每个类的属性和职责。,某银行系统类图,类的构造型,类的构造型可以将类进行分类，并且有助于理解每个类的职责，,不同构造型的类具有不同的职责。,类的构造型写在括号 之中。,第三阶段,类的设计与实现,系统设计及实现,面向对象的分析是确定了某个特定问题域中的对象，以及各种各样的关系。,面向对象的设计是将分析阶段获得的模型变成抽象的系统实现方案的过程。,系统设计及实现,在设计阶段对分析模型进行扩展并将模型进一步细化，同时还要考虑技术细节和各种限制条件。,设计的目的是开发出一个基于面向对象的可行的系统逻辑解决方案，以便编程人员能够很方便地将其转变成为程序代码。,系统的设计可以分为两个阶段,：,系统总体设计阶段：,主要包括如何把整个系统划分为多个包（子系统）的策略，以及描述多个包之间的依赖性和通信机制等。,详细设计阶段：,主要是决定在实现过程中使用的类和关系的全部定义，以及用于实现操作的各种方法的算法和接口。,1.系统总体设计,对于一个复杂的软件系统，常需要进行体系结构的设计，系统总体设计就是这样一种高层的结构设计。,定义并且设计子系统,在进行系统总体设计时，通常的做法是将一个软件系统组织成若干个子系统，子系统内还可以继续划分子系统或包。,一个子系统是包含多个类、关系、操作、事件和约束的一个包。,子系统与其他子系统之间还应该确定关系。,划分各个子系统,这一步的主要任务是划分各个子系统、说明子系统之间的关系。具体如下：,(1)划分各个子系统。,划分子系统的方式有：,可以按照功能划分,可以按照系统的物理布局划分,可以按照软件层次划分子系统,按照功能划分,三层体系结构,定义各子系统之间的关系,当划分了各子系统后，还要确定子系统之间的关系，,子系统之间的关系可以是“请求一服务”关系，也可以是平等的关系。,定义各子系统之间的关系,如果子系统的内容相互有联系，说明子系统之间的有依赖关系,在设计时，相关的子系统之间应该定义接口，依赖关系应该指向接口，,定义各子系统之间的关系,如果两个子系统之间的关系过于密切，也就是说一个子系统的变化会导致另一个子系统的变化，这种子系统的理解和维护会比较困难。,解决子系统之间关系过于密切的办法：,重新划分子系统，将相互依赖的元素划归到同一个子系统之中。,定义子系统的接口,每个子系统提供的接口定义了一些对外部子系统提供的操作，体现了子系统的功能。,一个子系统可能与多个子系统发生依赖关系，依赖关系越多，接口就越复杂。,远程教育题库系统系统体系结构模型,对外接口,系统资源接口,对外接口,题资源接口,对外接口,图片管理,属性管理,编码管理,资源管理,题目编辑,日志维护,题目维护,题资源管理,数据库,导出试卷,导出题集,题集,试卷,定义子系统的接口,定义子系统接口，首先应命名子系统接口。,将类的构造型标记为。,接着，描述拟建子系统的行为，即是定义操作集合。,子系统接口,子系统接口至少应当说明以下内容：,操作的名称。,操作使用的参数名称及类型。,操作的返回值含义及类型。,操作应该做什么（文字描述，包括关键的算法）。,“售书处理子系统包”的接口描述,/接口名：inceptBF 收款接口,Package 售书处理,Public interface incentBF,Public String getBookBillNo()/读书单号,Public Void setPayFlag(Boolean payFlag)/写交款标记,Public Boolean getPayFlag()/读交款标记,划分包,根据实际情况，还可以划分更细的组织单元。,具体的作法是将模型元素分组放入特定的包中。,作为经验法则，每个包通常具有510 个类。,包内高内聚，包间低耦合,良好包结构的关键是包内高内聚，包间低耦合。,包应该包含一组紧密相关的类。,类通过继承最紧密相关，组合次之，然后是聚合，最后是依赖。,描述包之间的依赖关系,根据描述系统分析阶段获得的类图，可以获得分处于不同包的类之间关系，进而推断出相应包之间的依赖关系。,包之间的依赖关系,2.详细设计,系统详细设计阶段的主要任务是确保设计方案能够为后续实施活动提供详细明确的依据。,对类和类的相互关系进行详细的定义、以及如何用具体的算法和数据结构来表示和实现是此阶段的具体内容。,定义设计类,在设计阶段定义的类，称它们为设计类。,识别设计类可以从分析阶段定义的分析类入手，将它们初步定义为设计类。,从分析类到设计类,在设计阶段，要根据实现所采用的技术规范对系统分析类重新识别。,分析类+设计模式设计类,设计模式的选择与应用,设计模型开发的第一步就是根据项目特点选择将要采用的设计模式。,设计模式的选择要考虑到该模式对应的语言和环境，以及模式的适用范围。,Model1和Model2,使用Java开发网站时，通常有两种设计模式，称为Model1和Model2。,Model1：通过一组JSP的结合制作出来的，是以JSP为中心的设计模式。,Model2：是采用MVC架构的设计模式。,Model1,Model1模式其实还可以再分为两种，,一种是完全使用JSP来开发，,另外一种则是使用JSPJavaBean的设计，,Model1-完全使用JSP开发系统,（,1）完全使用JSP开发系统。,这种做法的优点是：,l）开发时程缩短：,2）小幅度修改非常容易：,Model1-完全使用JSP开发系统,但是该方式也有许多缺点，例如：,l）程序可读性降低：,2）程序重复利用性降低：,Model1-JSPJavaBean架构,JSPJavaBean架构 Web框架，进行快速及小型的项目开发具有非常大的优势，,提高了可重复利用性，减少编写重复程序代码的工作，增加开发效率。,JSPJavaBean架构,Model1-JSPJavaBean架构,但是这种方式缺乏流程控制，缺少了MVC中的Controller去控制相关的流程，,未来维护不易,不利于应用程序的扩展与更新，,因此大型系统的开发大多采取 Model2-MVC架构的开发模式。,Model2,Model2就是采用MVC架构的开发模式。,通过这种设计模型把应用逻辑、处理程序和显示接口分成不同的组件实现，来弥补Mode1 的不足，,Model2的原理,Model2,它的主要优点为：,1）开发流程更为明确：,2）核心的程序管控：,3）维护容易：,Model2,这种设计模式的缺点是：,l）学习时间较长：,2）开发时间较长：,MVC设计模式,基于Bean的MVC模型,可以利用JavaBean实现，也可以利用EJB实现,分别构成的系统是,JavaBean(M)+JSP(V)+Servlet(C),EJB(M)+JSP(V)+Servlet(C),MVC设计模式JavaBean(M)+JSP(V)+Servlet(C),Web,应用系统建模的重要概念,在,电子商务应用系统中起着重要作用的概念有：,Web页、超链接、表单（Form）和框架（Frame）等。,Web页又分为客户机页和服务器页。,1.服务器页,服务器页（Server Page）是能访问服务器资源的对象，如 JSP页面、ASP页面等。,服务器页类用类构造型表示。,Rose中服务器页的3种表示形式,Icon形式,Label形式,Decoration形式,2.客户机页,客户机页（Client Page）是客户机上运行的 HTML格式的页面。,客户机页类用类构造型表示。,Rose中客户机页的3种表示形式,Icon形式,Label形式,Decoration形式,3.Web页之间的关联,UML中用构造型为的单向关联表示服务器页和客户机页之间的关联。,UML用构造型为的关联来描述两个客户机页之间或一个客户机页到一个服务器页的超链接。,关联可以是双向的。,服务器页面和客户端页面,网页之间的关联关系,标记值,标记值用于定义随链接请求一起传递的参数。,标记植,4.表单（Forms）,客户端的浏览器通过表单收集用户输入的数据，并被提交给服务器页处理，从而形成一个交互式系统。,对表单建模要使用另一个类构造型：Form,表单类没有操作。,表单,表单,表单类的属性是它的输入域。,表单的输入元素都是表单类的建有构造型的属性。,表单,客户机页和表单之间的固有关系是容器关系，客户页包含表单。它们是一种聚合关系形式。,表单总是将它的信息提交给服务器页。服务器页是处理表单提交内容的页。,关联关系构造型表示了表单和处理它的Web页之间的关系。该关联是单向的,5.框架集（Frameset）,框架集可将浏览器窗口分成多个框架，每个框架都有自己的对应URL值，而且可分别独立地装入W,eb,页,框架集类是一个容器对象。其构造型是,目标（target）类是个被框架集中的其它客户机页引用的指定框架。,目标链接关联关系构造型是指向另一个页的超链接。,框架集,关联,构造型为的单向关联用来描述服务器页和客户机页或两个服务器页之间的关系。,关联,或的单向关联,或的单向关联表示重定向问题，即表示控制从一个服务器页转到另一个服务器页或客户机页,对于 JSP页面，是用构造型为,对于ASP页面，是用构造型,或的单向关联,JavaBean,建模,可以用构造型为的关联表示一个JSP页面要使用JavaBean。,JavaBean,建模,Servlet,Servlet是用Java编的服务器端小程序。是运用java语言编写的程序。,Servlet源于请求/响应模式，它可以处理Web客户传来的超文本传输协议（HTTP）请求，并发回一个合适的响应。,一般职责,Servlet负责那些更易于管理的任务：,收集和验证用户输入。,协调输出，但几乎不直接生成动态Web页面内容。,工作量比较小的业务逻辑处理。,Servlet转移,Servlet转移是一种特殊的关系。,例如，在处理逻辑流程上，它可以清楚地显示处理逻辑流。在复杂的转移链中，关系可以指示某些将被执行的算法。,在类图上，用forward关系来标识Servlet之间的关系。,在类图上对转移的Servlet建模,Servlet包含,Servlet包含关系是一种单向关联。用构造型include表示。,关联的方向从包含的Servlet指向被包含源。,Servlet包含,Servlet的职责,一般来说，Servlet的作用是作为一个边界对象和系统其余部分之间的协调器。边界对象和复合控制类之间的所有交互都属于新的Servlet。,关键的因素是记住Servlet首先是一个协调器，因此，它只承担很小的责任，可能包含启动某些业务逻辑。,在线银行业务（HomeDirect）,用于资金转账的精化顺序图,在Servlet和控制之间划分职责利用顺序图设计设计类,Java服务器页面（JSP）,JSP是Java Server Page的简称。,主要用于开发动态页面。,在处理以显示为中心的任务时使用JSP。,在必须为客户端显示动态内容时，用JSP非常合适。,服务器端关系,服务器端页面关系分成如下几类：,与其他服务器页面：服务器页面可能与其他服务器页面关联在一起。,这种关系用forward或include关系来建模。,服务器端关系,可能访问或使用JavaBeans。,在这种情形下，这种关系就作为一种用Use Bean标记的关联关系来建模的。,这在JSP中表示一个jsp：useBean标记。通过这种关系，就可以从JSP内部访问JavaBean。,服务器端关系,依赖于其他类或库：服务器页面可以导入其他需要的类或库以完成其自身功能。,这种关系是作为依赖关系来建模的,是用一条带箭头的虚线表示的。,Login登录用例设计,使用 JavaBeans,共享,信息,访问数据库,通过JSP访问数据库很简单，但可维护性和代码的重用性却不好，,所以一般都把访问数据库的代码放在JavaBean或servlet中。,持久化访问层,JavaBean或servlet被称为持久化访问层。,JavaBean或servlet为数据的存储和检索提供了一个基础支撑结构。,利用这种结构可以将应用程序和数据的存储隔离开来，任何类型的存储变化都不会影响应用程序。,分析顺序图,设计顺序图,2.详细设计,系统详细设计阶段的主要任务是确保设计方案能够为后续实施活动提供详细明确的依据。,对类和类的相互关系进行详细的定义、以及如何用具体的算法和数据结构来表示和实现是此阶段的具体内容。,定义设计类,在设计阶段定义的类，称它们为设计类。,识别设计类可以将分析类初步定义为设计类，而分析类之间的关系自动转化为设计类之间的关系。,（2）设计一个类,在已经定义了设计类的基础上。,下面要具体设计每个类的内容，包括为每个类设计操作、属性、关系、状态和设计类的特殊需求。,勾画出每个设计类的轮廓,首先规划出每个类的概要内容。,对于边界类应该设计用户的操作界面，,对于实体类应该设计数据库表或文件结构，,对于控制类应该设计概要的操作处理流程。,定义类的属性,设计类的属性时有些内容是必须要定义的，有些内容是可选的。,必须定义的内容有：,(1),属性,的数据类型,。,(2）属性的可视性,命名属性,属性应该以一致的风格命名，理想的情况是，你开发出的所有类都有一致的风格。,应该使用完整的描述为属性命名。,集合属性，如Java中的数组和向量，应该使用复数形式为其名称，以指出它表示的是多个值。,“好的”,名称与,“不好的”名称,“不好的”名称,“好的”名称,问 题,FrName,FirstName,属性名称中不要使用缩写,firstname,firstName,大写第个词会使属性名称更易阅读,personFirstName,firstName,这依赖于属性的上下文，但如果这是“Person”类的属性,那么包含“person”只会增加名称的长度而并不提供任何价值,nameLast,lastName,名称“NameLast”与“lastName”不一致（毕竟它听起来有点儿怪）,“好的”,名称与,“不好的”名称,hTTPconnection,httpconnection,缩略词应该小写,firstNamestring,firstName,指明属性的类型本例中是“string”，会把名称和类型耦合起来。如果类型发生了变化（也许你决定把这个属性作为类“Namestring”的一个实例重新实现），那么你 需要重新为属性命名,otherltem