第7章(1)详细设计与PSM建模技术-OO设计技术概论

1、软件工程宁夏医科大学 理学院 杨德仁第7章(1) PSM建模与设计技术OO设计技术概论大纲 PSM建模概述：目的与技术 Technique: Seeing at different abstract levels 从鲁棒分析到详细设计 设计目的：序列图、类图、数据库表模式 设计原理设计原理 目标：应对变化目标：应对变化 软件质量与问题 良好软件的内、外部质量特征良好软件的内、外部质量特征 Symptoms (Design Smell) of Poor Design Some Common Design Flaws On Successful Design 责任驱动的设计方法责任驱动的设计方法R

2、DD 基本思想、原理 Some Works with RDD Open IssuesWarm up: Software specification design Realization of a concept or idea into a configuration, drawing, model, mould, pattern, plan or specification (on which the actual or commercial production of an is based) and which helps achieve the items designated obj

3、ective(s). Software specification A detailed software description which can serve as a basis for a design or implementation. 规范的用途有歧义！ Written for designers or coders?Technique: Seeing at different abstract levels We can see objects and behavior at different levels: At the conceptual level, a set of

4、 responsibilities At the specification level, a set of methods that can be invoked At the implementation level, code and data From Use Cases to Classes Gathering Responsibilities from Use Cases Descriptions Showing Responsibilities among Robustness diagrams +Assigning Responsibilities to objects in

5、Sequence diagrams: Guidelines with GRASP and SOLIDTechnique: Seeing at different abstract levels 设计的两阶段方法： 第一阶段 (分析或初步设计)及其目标 确定事件流及其责任（behavior） ，进而 致力于发现新对象， 确定对象的属性：利用GUI和业务规则 而忽视 “whos doing that.” Thats because during preliminary design, the information just wasnt there to allocate operations w

6、ithout guessing. 第二阶段（详细设计）及其目标 However, now that youre at the detailed design stage, you should have everything in place to correctly allocate the behavior among your classes. 致力于 “whos doing what to whom.” “信息”处理：确定类的方法从鲁棒分析到详细设计 完成鲁棒分析及其审核后，完成鲁棒分析及其审核后， 用例规约应处于这种状态： 用例规约应是完整的、正确的、详尽的和明确的 对用例规约的优化

7、是为详细设计准备的 鲁棒图是清晰的，能从它开始进行详细设计。 类图已经有了属性，但缺乏方法！方法从何而来？ 序列图中的消息及其接收。 *明确了technical architecture (TA)及其描述 软件布局的角度 包图Detailed OOD and Sequence Diagrams PIM鲁棒鲁棒（初步设计）在于（初步设计）在于 完善和优化用例规约 发现 类 (对象)：界面对象，控制对象，以及其它实体对象 属性（GUI和业务规则） PSM详细设计在于详细设计在于 通过责任驱动的设计（RDD），利用序列图，分配责任，以对象/类的方法的形式 原理？ *调整类图，体现重用和灵活性 原理？

8、 *涉及数据库表模式Primary Goals of Drawing Sequence Diagram 序列图直接来源于鲁棒图 画序列图时，要转化鲁棒图的 部分（理想化的）控制对象，旨在为类增加方法 探索在用例生命周期内对象如何相互 通过探索对象在运行时的交互机制。 确定为类分配方法，如何识别？原理是什么？ 控制对象的转化 作为通用经验规则，80%的控制器被转化为方法，归属于实体类或边界类，注意： 控制器和操作不必是1:1，控制器可转换成两个或多个方法 为提高软件性能，部分要转换为控制对象（虚拟软件类） controller classes，诸如“manager”或 “dispatcher”

9、class, 一些框架也有许多微小的“controller classes” DAO.Primary Goals of Drawing Class Diagram 在类图中 类直接来源于鲁棒图 界面对象、实体对象、部分控制对象 *软件体系结构 根据设计模式和原理，增加的虚拟软件类 方法来源于部分控制对象 目的 重用，灵活性 相关资料 Deren Yang, Min Liu and Zhaohua Gu; Modeling Principles of the Sequence Diagram and its Application in MDA Software Paradigm. Advanc

10、ed Engineering Forum Vols. 6-7(2012),pp15-19. 李金娟,杨德仁,顾召华;序列图建模机理与应用研究;新乡学院学报（自然科学版），2012,Vol(29),No(5), pp413-415。Primary Goals of Drawing Data Schema 数据库表模式直接来源于类图中的实体对象 逻辑层面：3NF 防止数据冗余 实施层面，要分割库表 纵向分割和横向分割 提高查询和处理速度 目的 重用，灵活性 文献杨德仁，大型数据库优化设计方案.计算机系统应用,2001, 10(5): 16-18. John Garmany; Jeff Walker

11、; Terry Clark. Logical Database Design Principles. ISBN: 978-0-8493-1853-5 (hardback) 978-0-203-50516-8 (electronic). pages: 180OO详细设计原理 OOD的核心概念是对象 LRG：从现实对象到软件对象 OOD充分重视人工系统的作用 现实世界问题的解早已存在于人工系统中，人工处理的经验：人工系统模型。 其基础是抽象性与信息隐蔽性 类是体现信息隐蔽（封装）和抽象的典型。OO详细设计原理 详细OO设计原理要 支持OO语言的基本特征 支持良好OO软件的特征 防止OO软件变味 详

12、细OO设计原理包括： 为类分配行为（RDD驱动的） GRASP设计模式 优化设计 SOLID等基本原理 GoF设计模式（支持重构）（“软件新技术”一章）良好软件的特征外部特征（功能与性能）外部特征（功能与性能） 正确性正确性。整个系统受说明、设计和实现的错误影响程度。 可用性可用性 Availability：Percentage of time a computer system is available for use. Formula: Uptime x 100 (Uptime + Downtime). 效率效率。对系统资源的最小利用，包括存储和执行时间。 可靠性可靠性。系统在一定条件下执

13、行特定功能的能力在每次失效之间有较长的平均时间。 完整性完整性。防止非法或不适当访问。完整性思想包括：限制非法用户访问，同时保证数据恰当访问；并行数据表进行并行修改；数据段仅含有效数据等。 适应性适应性。系统在应用或其它环境下不作修改就能使用的能力。 精确性精确性。系统不受错误影响的程度，尤其数据输出方面。精确性和正确性不同。精确性对系统完成其工作性能的衡量，而不是它设计得是否正确。 健壮性。健壮性。系统针对无效输入或在压力环境中继续执行其功能的能力。13良好软件的特征内部特征内部特征 可维护性可维护性。修改软件系统，以提高其性能或修正其错误的能力。 灵活性灵活性。修改系统，使其能适应于不同的

14、用途或环境的能力。 可移植性可移植性。能修改设计的某一系统，使其能在其它环境下运行的能力。 可重用性可重用性。能将系统的部分用于其它系统的难易程度。 可读性可读性。能读懂或理解系统源代码的能力，尤其是在细节说明级别上。 可测试性可测试性。对整个系统进行单元或系统测试。以证实其满足所有需求性能的测试难易程度。 可理解性可理解性。在整个系统水平或细节级别上理解整个系统的难易程度。14良好软件的特征 Software Quality Factors Object-oriented techniques enhance key external and internal software qualit

15、y factors, e.g., 1. External (visible to end-users) (a) Correctness (b) Robustness and reliability (c) Performance 2. Internal (visible to developers) (a) Modularity (b) Flexibility/Extensibility (c) Reusability (d) Compatibility (via standard/uniform interfaces)Symptoms (Design Smell) of Poor Desig

16、nSome of the principles that do lead to better designs. Before we delve into the “what to do” rules lets take a quick look at the 7 deadly sins of design and the design problems we all want to avoid. Circumventing 规避 the principles that will be discussed later will, more often than not, result in co

17、mmitting one or more of these following sins.Rigidity. Make it hard to change, especially if changes might result in ripple effects or when you dont know what will happen when you make changes. Fragility. Make it easy to break. Whenever you change something, something breaks. Immobility. Make it har

18、d to reuse.When something is coupled to everything it uses. When you try to take a piece of code (class etc.) it takes all of its dependencies with it. Symptoms (Design Smell) of Poor DesignViscosity粘性，靠谱性. Make it hard to do the right thing. There are usually several ways to work with a design. Vis

19、cosity happens when it is hard to work with the design the way the designer intended to. The results are tricks and workarounds that, many times, have unexpected outcomes (esp. if the design is also fragile). Needless Complexity/Over design/the Swiss-Army knife/anti-pattern. When you overdo itA clas

20、s that tries to anticipate every possible need. Another example is applying too many patterns to a simple problem etc. Needless Repetition. The same code is scattered about which makes it error prone. DRY！Not doing any design.另一个版本：Opacity透明度Disorganized expressionSome Common Design Flaws Classes th

21、at make direct modification to other classes Classes with too much responsibility unused responsibility no responsibility Misleading names Unconnected responsibilities Inappropriate use of inheritance Repeated functionalityOn Successful Design 若只利用OO语言基本特征，很难设计出健壮程序 不良软件有其症状，如继承不利于实现系统的低耦合性要求 因此，软件设

22、计还应遵循设计OO设计原则 好软件需要遵循面向对象的设计原则来保证 不必严格遵守设计原则，违背也不会被处以宗教刑罚。 应当把这些原则看成警铃，若违背其中一条，警铃就会响起：怪味出现，隐患难免；要加以防范。 原理的应用原则 原理只是原理而已，不是命令 遵循原理可避免设计问题 有些原理不能一起使用，需要折中考虑Use priorities and objectives to decide among alternativesOn Successful Design:目的 Design for portability Design for Flexibility Orthogonal evoluti

23、on in many dimensions Anticipate 防止 obsolescence 过时 Design for testabilityOO Design: responsibilities What is Design? Developing a blueprint (plan) for a mechanism that performs the required task, taking into account all the constraints, & making trade-offs between constraints when they are in c

24、onflict. OOD is sometimes taught as some variation of the following: * Identifying requirements and creating a domain model, Adding methods to the appropriate classes, And defining the messaging between the objects to fulfill the requirements 将责任分配给对象，即责任主体是单个对象或一组协作的对象 Too Simple! Such vague advice

25、 doesnt help, because It is difficult to decide How do we assign responsibilities to classes? And how objects should interact in order to realize consequencesOn Successful Design:责任again! But there are problems here! Does each new design start from first principles? Abstraction has been our friend I

26、t can help again How to Design? Detailed object design is usually done from the point of view of the metaphor (比喻) of Objects have responsibilities：Knowing,Collaborate & Do Responsibilities are an abstraction. 具有不同层次性和粒度： The responsibility for persistence. Large-grained responsibility. The resp

27、onsibility for the sales tax calculation. More fine-grained responsibility. How do you decide on the class do and collaborations? Simple: Follow principles of design责任驱动的设计方法责任驱动的设计方法RDD Responsibilities at different levels Responsibility implies a degree of independence or noninterference. We can s

28、ee objects and behavior at different levels: At the conceptual level, a set of responsibilities At the specification level, a set of methods that can be invoked At the implementation level, code and data Responsibilities are defined in conceptual level: a contract or obligation and is related to beh

29、avior(s)(高度相关的行为集合) of a type or class eventually.责任驱动的设计方法责任驱动的设计方法RDDClassification of Responsibilities Three types of responsibilities for objects: Doing, Knowing and Deciding.Knowing responsibilities are often easily inspired by software domain objects E.g., domain class for a Sale has a time at

30、tribute Sale class in OO design knows its time as well Result of meeting the domain model aim to have a Low Representational Gap (LRG)Doing responsibilities often come from early modeling E.g., each message in a UML interaction diagram is suggestive of something that must be doneDeciding responsibil

31、ities selecting a course of action among several alternative scenarios. Every decision making process produces a final choice. The output can be an action or an opinion of choice. 责任驱动的设计方法责任驱动的设计方法RDDClassification of Responsibilities 责任的分类 行为 自身执行的行为，如创建对象或计算， 初始化其它对象的动作， 控制和协调控制和协调其它对象的活动 认知 对私有封

32、装数据的认知，对相关对象的认知，对其它能导出或计算的事物的认知 There are 2 types of responsibilities knowing responsibility includes Knowing about private encapsulated data-member data Knowing about related objects Knowing about things it can derive or calculate doing responsibility includes Doing something itself-assigning, calc

33、ulating, creating Initiating action in other objects Controlling and coordinating actions in other objects责任驱动的设计方法责任驱动的设计方法RDD Responsibility and Method RDD includes the idea of collaboration. Responsibilities are implemented by means of methods that either act alone or collaborate with other metho

34、ds and objects. Dont confuse the responsibility as a method in a class even though they are implemented using methods which either act alone or collaborate with other methods and objects. A responsibility is not the same thing as a method its an abstraction but methods fulfill responsibilities. Alon

35、e Or through collaboration with other objects 责任与对象的义务和行为相关，责任是类元(类、接口)要实现的契约或义务责任驱动的设计方法责任驱动的设计方法RDD Adds responsibility concepts and thinking to any process or objects A way using informal tools and techniques to design software that Distributes (data and) behavior among classes emphasizes modelin

36、g of objects responsibilities and collaborations RDD is a general metaphor for thinking about OO software design. Think of software objects as similar to people with responsibilities who collaborate with other people to get work done. RDD includes the idea of collaboration. View an OO design as a co

37、mmunity of collaborating responsible objects. Responsibilities are implemented by means of methods that either act alone or collaborate with other methods and objects.责任驱动的设计方法责任驱动的设计方法RDD As such, their use results in a Responsibility Driven Design (RDD) for Object Orientation (OO) RDD, developed b

38、y Rebecca Wirfs-Brock, is an object-oriented design technique that is driven by an emphasis on behavior at all levels of development. Contrast to (more traditional) Data Driven Design A responsibility is an obligation of an object in terms of its behavior. With this point of view, assigning responsi

39、bilities to objects is a large part of basic object design, of object design in designing software. Specifically its always a challenge to decide which object carry out what job (responsibilities) and quality of software design largely depended upon such responsibilities assignment.责任驱动的设计方法责任驱动的设计方

40、法RDD Related concepts a responsibility = an obligation to perform a task or know information a collaboration = an interaction of objects RDD is a design technique in object-oriented design. Responsibility-driven design (RDD) is inspired by the C/S model. proposed by Rebecca Wirfs-Brock and Brian Wil

41、kerson Responsibilities are assigned to classes during design. drawing interaction diagrams becomes the occasion 时机 for considering these responsibilities RDD focuses on the contract by asking: What information does this object share? What actions is this object responsible for? 29责任驱动的设计方法责任驱动的设计方法

42、RDD Responsibility-Driven Design Principles Maximize Abstraction Initially hide the distinction between data and behavior. Think of objects responsibilities for “knowing”, “doing” and “deciding” Distribute Behavior Promote a delegated control architecture Make objects smart have them behave intellig

43、ently, not just hold bundles of data Preserve Flexibility Design objects so interior details can be readily changed 不全面，也抽象，难以理解 相关性？与那个模型？在哪个层次？Some Works with RDD Some techniques emphasizing the assignment of responsibilities in classes are: Class responsibility Collaboration (CRC) cards 没有界面对象、控制

44、对象 Robustness Analysis（模糊） General Responsibility Assignment Patterns (GRASP) 下节内容 Two process using these techniques: Rational Unified Process (RUP) using GRASP patterns and ICONIX using Robustness Analysis, CRC?Some Works with RDD：CRCClass Responsibility Collaboration (CRC) cards are a brainstormi

45、ng tool used in the design of object-oriented software. They were originally proposed by Ward Cunningham and Kent Beck as a teaching tool, but are also popular among expert designers and recommended by extreme programming supporters.Scott W. Ambler. CRC Modeling: Bridging the Communication Gap Betwe

46、en Developers and Users, 1999Martin Fowler has described CRC cards as a viable alternative to UML sequence diagram to design the dynamics of object interaction and collaboration.CRC cards are usually created from index cards. Members of a brainstorming session will write up one CRC card for each relevant class/object of their design. The card is partitioned into three areas:on top of the card, the class nameon the left, the responsibilities of the classon the right, the classes with which this class interacts to fulfill its responsibilities.Using a small