面向对象的分析与设计--分解

1 .CMPE 135: Object-Oriented Analysis and Design September 6 Class Meeting Department of Computer Engineering San Jose State University Fall 2018 Instructor: Ron Mak www.cs.sjsu.edu/~mak 1

2 .On Complexity 2 A physician, a civil engineer, and a computer scientist were arguing about what was the oldest profession in the world. The physician remarked, “Well, in the Bible, it says that God created Eve from a rib taken out of Adam. This clearly required surgery, and so I can rightly claim that mine is the oldest profession in the world.” The civil engineer interrupted, and said, “But even earlier in the book of Genesis, it states that God created the order of the heavens and the earth from out of the chaos. This was the first and certainly the most spectacular application of civil engineering. Therefore, fair doctor, you are wrong: mine is the oldest profession in the world.” The computer scientist leaned back in her chair, smiled, and then said confidently, “Ah, but who do you think created the chaos?” Object-Oriented Analysis and Design with Applications, 3 rd edition by Bobbi J. Young Ph.D., Kelli A. Houston, Jim Conallen , Michael W. Engle, Robert A. Maksimchuk , and Grady Booch Addison-Wesley Professional, 2007 ISBN 9780201895513

3 .Decomposition One way to deal with complexity is to “divide and conquer”. Decompose a complex system into smaller and smaller parts. We only need to comprehend a few small parts rather than all the parts at once. Algorithmic vs. object-oriented decomposition 3

4 .Algorithmic Decomposition Traditional top-down structured design . Each module is a step in the overall process. Show the relationships among the various functional elements of the solution. 4 Object-Oriented Analysis and Design with Applications, 3 rd edition by Bobbi J. Young Ph.D., Kelli A. Houston, Jim Conallen , Michael W. Engle, Robert A. Maksimchuk , and Grady Booch Addison-Wesley Professional, 2007 ISBN 9780201895513 Update the content of a master file.

5 .Object-Oriented Decomposition Decompose according the the key abstractions of the problem domain. View the world as a set of autonomous agents. 5 Object-Oriented Analysis and Design with Applications, 3 rd edition by Bobbi J. Young Ph.D., Kelli A. Houston, Jim Conallen , Michael W. Engle, Robert A. Maksimchuk , and Grady Booch Addison-Wesley Professional, 2007 ISBN 9780201895513

6 .Which Decomposition is Better? Algorithmic Highlight the ordering of events. Object-oriented Emphasize the agents that either cause action or are the subjects that are acted upon. These are orthogonal perspectives of a system. Choose one or the other. 6

7 .Object-Oriented Decomposition is Better Build smaller systems through the reuse of common mechanisms. Object-oriented systems are more resilient to change . Reduce the risk of building complex systems. Evolve incrementally from smaller systems in which we already have confidence. Help make intelligent decisions regarding the separation of concerns in a large system. 7

8 .Hierarchy Hierarchical structure The architecture of a complex system is a function of its components as well as the hierarchical relationships among these components. Object structure How different objects collaborate with each other. Patterns of interaction. Class structure Common structure and behavior within a system. 8

9 .What is Design? A disciplined engineering approach to invent a solution for some problem. Provide a path from requirements to implementation. 9

10 .The Purpose of Design in Software Engineering Satisfy a given (perhaps informal) Functional Specification . Conform to limitations of the target medium. Meet implicit or explicit requirements on performance and resource usage. Satisfy implicit or explicit design criteria on the form of the artifact. Satisfy restrictions on the design process itself, such as its length or cost, or the tools available for doing the design. 10 “Toward Better Models of the Design Process” by J. Mostow AI Magazine  vol. 6(1), Spring 1985, p. 44.

11 .11 Analysis Precedes Design Understand the problem. The application is no good if it doesn’t do what it’s supposed to do. Gather requirements from the client. Create use cases to make sure you and the client agree what the application is supposed to do. You must understand the application better than your client. Know exactly what the application needs to do. Be able to anticipate problems.

12 .12 The Only Thing that’s Constant ... ... in Analysis and Design is CHANGE Clients (and other stakeholders) change their minds about purpose and requirements. Market conditions change . The environment changes .

13 .13 But Avoid ... Paralysis by Analysis

14 .14 Where Do Classes Come From? Textual analysis Look for nouns and verbs in your use cases. Nouns  classes Some nouns are actors. Verbs  functions Class names should be nouns in the singular form, such as Inventory , Instrument , InstrumentSpec .

15 .15 Where Do Classes Come From? cont’d How will the classes support the behaviors that your use cases describe? Focus on concepts , not implementation.

16 .16 Categories of Classes Things Examples: Instrument , InstrumentSpec Agents Represent doers of tasks. Names often end in “ er ” or “or” Examples: Scanner , Paginator

17 .17 Categories of Classes , cont’d Events and transactions Activities that describe what happened in the past or what needs to be done later. Example: MouseEvent remembers when and where the mouse was moved or clicked. Users and roles Stand-in for the actual users of the application. Common in systems that are used by more than one person or where one person needs to perform distinct tasks. Examples: Administrator , Reviewer

18 .18 Categories of Classes , cont’d System A subsystem or the overall system being built. Typical functions: initialize, shutdown, read input System interfaces and devices Interfaces to the host operating system, file system, etc. Foundation Typically the built-in classes. Examples: string , date

19 .19 Class Responsibilities Responsibilities correspond to verbs in the use cases. Each responsibility should be owned by one and only one class . Common mistakes: Assigning a responsibility to an inappropriate class. Assigning too many responsibilities to a class. Ideally, each class should have a single primary responsibility .

20 .20 Class Responsibilities Example class Automobile start() stop() changeTires () drive() wash() displayOilLevel () checkOil () class Automobile start() stop() displayOilLevel () class Driver drive() class CarWash wash() class Mechanic changeTires () checkOil () Too many responsibilities! A cohesive class does one thing really well and does not try to be something else.

21 .21 Class Relationships: Dependency Class C depends on class D . Some function of C manipulates objects of D Example: Mailbox objects manipulate Message objects. Dependency is asymmetric . The Message class is not aware of the existence of the Mailbox class. Therefore, Message objects do not depend on Mailbox objects.

22 .22 Class Relationships: Dependency , cont’d Loose coupling Minimize the number of dependency relationships. A key way for a design to handle change .

23 .23 Class Relationships: Aggregation Class C aggregates class A . A special case of dependency. Objects of class C contain objects of class A over a period of time. The “ has-a ” relationship. Example: An Inventory object has a list of Instrument objects.

24 .24 Class Relationships: Aggregation , cont’d Multiplicity 1:1 – Example: Each Person object has a single StreetAddress object. 1:n – Example: Each Inventory object has an array of multiple Instrument objects.

25 .25 Class Relationships: Inheritance Class C inherits from class S . The “ is-a ” relationship. All class C objects are special cases of class S objects. Class S is the superclass of class C . Class C is a subclass of class S . An object of class C is an object of class S .

26 .26 Aggregation vs. Inheritance Aggregation : A Mailbox object has a Message object. Inheritance : A ForwardedMessage object is a Message object.

27 .27 A picture is worth a thousand words! It is much easier to extract information from a graphical notation than reading a textual document. Show your design in graphical UML diagrams . UML : Unified Modeling Language UML Diagrams

28 .28 There are several different types of UML diagrams. For now, we’ll mainly use: class diagrams sequence diagrams statechart diagrams UML Diagrams

29 .29 A class diagram has three compartments: UML Class Diagram Class Name Attributes : types Methods(parms : types) : return type member variables member functions