电子商务信息系统分析与设计徐天宇第10章节面向对象的系统设计2章节

《电子商务信息系统分析与设计徐天宇第10章节面向对象的系统设计2章节》由会员分享，可在线阅读，更多相关《电子商务信息系统分析与设计徐天宇第10章节面向对象的系统设计2章节（74页珍藏版）》请在金锄头文库上搜索。

1、第10章 面向对象的系统设计,徐 天 宇,10.1.2详细设计,系统详细设计阶段的主要任务是确保设计方案能够为后续实施活动提供详细明确的依据。 对类和类的相互关系进行详细的定义、以及如何用具体的算法和数据结构来表示和实现是此阶段的具体内容。,1.设计模式的使用,设计模式是进行应用系统设计时可复用的惯用模式，设计模式总结了常用问题的解决方法，它使设计人员可以共享已有的设计经验，提高设计效率和质量。 对于面向对象的Web应用系统设计，目前主要使用的设计模式是MVC,MVC设计模式,模型-视图-控制(model-view-control，简称MVC)结构是目前最常见的J2EE应用所基于的体系结构，M

2、VC主要适用于交互式的Web应用，,MVC结构,视图(View)显示Model的数据，提交由Controller提供的数据。 模型(Model)维护应用程序的状态和数据，可以接受来自View的查询并做出响应。同时当Model的数据发生变化时，它把变化通知给View ， View根据Model的数据发生来更新自己。 控制器(Controller)定义了抽象的业务逻辑，用于控制业务流程。 用于描述Model如何对用户的动作做出反应，即处理事件。,MVC关系图,MVC在 Web系统中的应用,电子商务系统，适合采用MVC体系结构。 可以将一个应用的对象分为三类。 一类就是负责显示的对象， 一类对象包含

3、商业规则和数据， 一类就是接收请求，控制商业对象去完成请求。,MVC的优点,1)松散的耦合； 2)并行的开发； 3)可扩展性； 4)可重用性; 5)模块的有效性； 6)模型的可移植性:,MVC 体系结构的不足,1)理解困难，耗费时间； 2)增加了系统结构和实现的复杂性； 3)视图与控制器间过于紧密的连接。,设计模式的选择与应用,分析类+设计模式设计类 定义设计类的第一步就是根据项目特点选择将要采用的设计模式。设计模式的选择要考虑到该模式对应的语言和环境，以及模式的适用范围。 基于JSP 开发网站时，通常有两种设计模式，称为Model1 和Model2 。,Model1和Model2,Model

4、1：通过一组JSP的结合制作出来的，是以JSP为中心的设计模式。 Model2：是采用MVC架构的设计模式。,Model1,Model1模式其实还可以再分为两种， 一种是完全使用JSP来开发， 另外一种则是使用JSPJavaBean的设计，,Model1-完全使用JSP开发系统,（1）完全使用JSP开发系统。 优点是： l）开发时程缩短;。 2）小幅度修改非常容易;,Model1-完全使用JSP开发系统,缺点： l）程序可读性降低; 2）程序重复利用性降低;,2）JSPJavaBean架构的Model1,进行快速及小型的项目开发具有非常大的优势， 将部分可以重复利用的程序代码抽出来写成Java

5、Bean，当用户送来一个需求时，通过JSP调用JavaBean负责相关数据存取、逻辑运算等的处理，最后将结果回传到JSP显示结果。 这样，不同的JSP可以调用许多共享性的程序代码，减少编写重复程序代码的工作，增加开发效率。,JSPJavaBean架构,JSPJavaBean架构的Model1,但是这种方式缺乏流程控制，缺少了MVC中的Controller去控制相关的流程，,Model2,Model2就是采用MVC架构的开发模式。 Model代表的是应用程序的应用逻辑； View是系统的显示接口； Controller是提供应用程序的处理过程控制,MVC设计模式,基于Bean的MVC模型 可以利

6、用JavaBean实现，也可以利用EJB实现,分别构成的系统是 JavaBean(M)+ JSP(V)+Servlet(C) EJB(M)+ JSP(V)+Servlet(C),MVC设计模式 JavaBean(M)+ JSP(V)+Servlet(C),Struts框架,Struts是较好的JSP Framework,Struts框架,2.设计设计类,在设计阶段定义的类，称它们为设计类。 识别设计类可以从分析阶段定义的分析类入手 要具体设计每个类的内容，包括为每个类设计操作、属性、关系、状态和设计类的特殊需求。,定义类的属性,设计类的属性时有些内容是必须要定义的，有些内容是可选的。 必须定义

7、的内容有： (1) 属性的数据类型。 (2）属性的可见性,属性命名,属性名的一般形式: attributeName 首先应命名属性。 属性应该以一致的风格命名 属性命名与类命名的原则相似，使用2-3个英文单词，首单词的首字母小写,其他大写，意义要明确。,属性名称,属性名称,设计属性的数据类型,设计属性时必须要根据使用的开发语言确定每个属性的数据类型， 如果数据类型不够，设计人员可以利用已有的数据类型定义新的数据类型。,设计属性的可见性,一般的经验是： 把private可见性赋予所有属性。 始终调用属性的set操作对其进行更新，即使在该属性定义的类中也应该如此； 仅通过get操作直接访问属性；

8、在属性的set操作中，实现简单的验证有效性的逻辑。,可选的属性设计,属性的初始值。,在设计属性时要注意下面几点：,如果一个设计类因为其属性的原因变得复杂而难于理解，那么就将一些属性分离出来形成一个新的类。 类的属性数据结构要坚持简单的原则，尽可能不使用复杂的数据结构。,定义类的操作,通常，定义一个设计类的操作的方法之一是跟踪对应的”分析类”职责，详细分析每个职责的具体含义，从中找出设计类应该具备的操作。 一个分析类的职责有可能需要设计类的一个或多个操作才能完成。,职责分配原则,在类间分配职责时，应考虑下面的原则。 单一职责原则 一个类主要围绕一个职责设计。如果承担的职责过多，可考虑将它分成多个

9、类。如果没有明确的职责，则可考虑取消该类。 依赖抽象而非具体原则 尽量在接口间建立联系，而不是在具体类间,职责分配原则,惰性原则 不要主动为类添加功能，除非为了满足测试的需要或实现必须承担的职责 内聚外松原则 保证类内的操作、特性具有最大的聚合度，而同时将类间的耦合度降到最低。,定义类的操作,通常，一个设计类不只参与一个用例。所以应检查，这样的设计类是否满足了所有有关用例的要求。 另外，系统的效率、可用性、安全性等非功能性需求，常常要落实到一些操作上来，因此还需要增加某些操作来实现这些需求。,对设计类操作的常见设计：,操作的名称； 操作的参数； 操作返回类型； 操作的可见性； 操作的并发性；

10、操作的前提条件和事后条件。,操作命名,操作名的一般形式: methodName() 操作名由23个单词构成，第一个单词的首字母小写,其他单词首字母大写: 例: studentName() getAverageMark() 命名原则: 用完整的单词,不用缩写；动词开头,以主动态表示；语义尽可能明确。,操作名称应统一,如 “getFirstName()”和“ fetchFirstName()” 的操作名称就不统一，如果两个名字都以“get”开头，就可以让它们统一起来。,参数名称应统一,参数名称也应当彼此统一。例如，“ theFirstName”、 “ firstName” “ firstNm” 这

11、样的参数名称就彼此不统一。,参数的顺序应统一,参数的顺序也应当统一。例如，操作 “dOSomething（securityToken，StartDate）” “doSomethingElse（studentNumber，securityToken”， 可以通过都把“securityToken”作为第一个（或最后一个）参数传递，使其更加统一。,操作的可见性,让操作按需提供可见性，不要超过限度。 为了减少系统的耦合，通用的操作是：在设置某个操作的可见性时，尽量地限制其可见性。,方法设计,方法设计描述的是操作的具体实现，所以与选用的编程语言密切相关。 方法设计包括数据结构设计、算法设计和流程设计。,

12、活动图描述算法,细化设计类的操作与属性,细化设计类的操作与属性，依靠顺序图是一个有效的方法。,用例图、顺序图、类图之间关系,顺序图、类图之间关系,分析顺序图资金转账,在Servlet和控制之间划分职责,设计阶段的顺序图（细化操作与属性）,控制类与边界类的属性,控制类与边界类的属性通常无属性 控制类有时需要属性描述对象的状态 控制类有时需要属性描述类本身的一些性质,描述设计类的状态,并不需要对每个设计类都描述其状态。 如果某个类比较复杂，有多种状态，当接收到一个消息时，要根据所处的状态来选择相应的操作行为，对于这样的类需要描述其状态。,由状态图获取更多操作分析类Claim_report,由状态图

13、获取更多操作初步精华后的设计类Claim_report,由状态图获取更多操作类Claim_report的状态图,由状态图获取更多属性,由状态图获取更多操作,由状态图获取更多属性和操作精化后的类Claim_report,定义设计类的关系,为了确定设计类之间的关系，首先应该跟踪对应的分析类之间的关系。,设计类之间的关系,在设计类之间的关系时还有一些细节需要考虑，下面列出这些细节： 确定关联的方向和多重性。 关系构造型。 使用关联类。 设置限定。,1）识别类之间的关联,如果两个对象之间需要进行协作,则要建立关联关系。如果协作只在一个方向进行，则建立单向关联。 顺序图也描述了设计对象间的相互作用。研究

14、顺序图的消息有助于发现类之间的关联,顺序图与关联关系,根据顺序图或协作图确定关联关系,根据顺序图或协作图确定关联关系,2）识别类的泛化关系,在几个类中，如果有分解出的公共部分 可以把分解出的公共部分放在父层。,识别类的泛化关系,3）识别类的聚合和组合关系,如果两个对象存在部分与整体的关系，并且整体由部分组成,整体消失时,部分仍存在，则应建立聚集关系。 如果两个对象存在部分与整体的关系，但是整体消失时,部分也消失，则应建立组合关系。,识别类的组合关系,4）设计角色,两个类扮演的角色如果根据上下文可以理解，一般情况下角色设计可省略。 但在下列情况应给出角色名: 当两个类之间有多个关联时 当一个类存在反身关联时,设计角色,5）设计角色多重性,对于每一个关联，都要有两个角色多重性设计。 关联的两端的角色多重性设计是要决策：对于关联一端的类的一个对象，关联另一端的类中有多少个对象与其相关。,多重性,最终设计类图,如何绘制好类图,焦点放在系统静态设计视图的一个方面。 只包含为了理解该方面而应该存在的元素。 提供足够的信息来理解该图。 不让读者产生错误的信息。 当你画类图的时候：给它起一个名字，这个名字能表达类图的用途。 用最少的交叉线来组织它的元素。,END,