7. Object-Oriented Design

Transcription

1 Computer Science and Software Engineering University of Wisconsin - Platteville 7. Object-Oriented Design Yan Shi SE 2730, Lecture Notes Summerville s textbook 8.4, 14.1

2 Analysis Phase and Design Phase Requirements and Use Case development are often referred to as the Analysis Phase. The Analysis phase addresses WHAT needs to go into a software system. The Design Phase addresses HOW the system will be implemented. It is important to verify that the design satisfies the needs specified by requirements and/or use cases.

3 Object models Object models describe the system in terms of object classes and their relationships. Natural ways of reflecting the real-world entities manipulated by the system More abstract entities are more difficult to model using this approach Objects represent tangible things in the domain (world) of the system NOUNs Object Models can be used to represent relationships among objects. We use class diagrams to represent the object model.

4 Domain, Design, Implementation Levels Domain level class diagram: Analysis level modeling is at a higher level. We only model real entities of the domain. We can identify Objects by looking for Nouns in requirements or other artifacts. Design level class diagram: Go into much more detail and add items that are not necessarily part of the domain, but will be used in the implementation, for instance different programming constructs. Implementation level class diagram: should be of sufficient detail so that someone with very little knowledge of the domain should be able to implement the framework for the modeled system.

5 Class Diagram: Class UML represents classes using boxes: Class names are at the top of box. Class names generally start with a capital letter. Operations define the functionality of a class. When an operation is implemented it is called a method. Some classes may not have operations. Attributes define the data of a class. In an implementation, the attributes become variables. Some classes may not have attributes. Attribute names generally start with lower case letters. Generally, insignificant class variables (like loop control variables, etc.) are not included in class designs.

6 Class Example Class name attributes... operations... Customer name:string address:string UpdateProfile():void

7 How to Draw a Class Diagram? If it is a domain level class diagram: Step 1: identify classes Step 2: add associations Step 3: refine relationships Step 4: add major attributes and operations

8 Step 1: Identify Classes How to find the classes in a problem? Note: classes abstract things - nouns classes do actions verbs Noun Identification method to find objects!

9 Noun Identification Method Given the requirement description (scenarios, use cases, requirement specifications): 1. Underline all nouns and noun phrases in requirements and/or use case scenarios 2. Combine redundant terms 3. Remove nouns that are out of scope of the system 4. Remove items that are programming constructs 5. Information that does not have state often are attributes of other objects 6. System rules translate to behaviors

10 Example: Ticketing System Purpose: Automate sale of rail tickets. Inputs: Credit card, Personal identification number Outputs: Rail ticket Purchasing a ticket 1. Upon startup, the system shall present the customer with a menu of potential destinations. 2. In the destination list, each destination shall include a location name, estimated arrival time, and cost. 3. After the user has selected a destination, the system shall request the user insert a credit or debit card for payment. 4. If a debit card has been inserted, the system shall prompt the user for a PIN. 5. After the card information has been collected, the system shall transmit the information to a payment processing agency for verification. 6. All information transmitted to and received from the payment processing agency shall be encrypted. 7. Upon receiving an approval from the payment processing agency, the system shall issue a ticket for the specified destination.

11 Example: Ticketing underline all nouns System Purpose: Automate sale of rail tickets. Inputs: Credit card, Personal identification number Outputs: Rail ticket Purchasing a ticket 1. Upon startup, the system shall present the customer with a menu of potential destinations. 2. In the destination list, each destination shall include a location name, estimated arrival time, and cost. 3. After the user has selected a destination, the system shall request the user insert a credit or debit card for payment. 4. If a debit card has been inserted, the system shall prompt the user for a PIN. 5. After the card information has been collected, the system shall transmit the information to a payment processing agency for verification. 6. All information transmitted to and received from the payment processing agency shall be encrypted. 7. Upon receiving an approval from the payment processing agency, the system shall issue a ticket for the specified destination.

12 Example: Ticketing combine redundant nouns system customer menu destination destination list location name estimated arrival time cost user credit card debit card PIN card information information payment processing agency approval ticket system customer menu destination destination list location name estimated arrival time cost credit card debit card PIN card information payment processing agency approval ticket In some cases, "nearly redundant" terms imply generalization: card" and credit card"

13 Example: Ticketing remove out of scope nouns system customer menu destination destination list location name estimated arrival time cost credit card debit card PIN card information payment processing agency approval ticket If we saw ticket kiosk, it would be out of scope for the ticket system. The system is the system being analyzed! payment processing agency is somebody you interface with, so should be included in the model.

14 Example: Ticketing remove program constructs customer menu destination destination list location name estimated arrival time cost credit card debit card PIN card information payment processing agency approval ticket o menu o button o screen o window o etc. Do we see any?

15 Example: Ticketing identify attributes customer destination destination list location name estimated arrival time cost credit card debit card PIN card information payment processing agency approval ticket Attributes contains simple information. Later, we can list these attributes in appropriate classes.

16 Example: Ticketing identify system rules customer destination destination list credit card debit card payment processing agency ticket Upon receiving an approval from the payment processing agency, the system shall issue a ticket for the specified destination. approval should not be identified as a class also because it describes a system rule.

17 Example: Ticketing Step 1 DestinationList Destination Customer CreditCard Ticket PaymentAuthAgency DebitCard

18 Step 2: Add Associations Classes can also have associations with other classes. There are many different relationship types. We will discuss: Association Inheritance (is-a) Aggregation (part-of) These relationships will be denoted by the line and arrow type connecting the classes that are associated.

19 Association Objects rely on each other for services and data. We identify associations with lines connecting the class boxes and labeling the line with the name of the relationship. These relationships identify public methods that are used to promote the relationship.

20 Navigation If a particular relationship only works in one direction, we use an open arrow to specialize this relationship. Otherwise we don t use an arrow. Easy test: in an association, if end1 knows end2 but end2 doesn t know end1, then put an arrow towards end2. By knowing, we mean calling a public method of that object.

21 Multiplicities Given an association between two objects, A and B, we state how many A s are associated with B s. Place the multiplicity right next to each class with the following notations: Most commonly used 0..1 No instances, or one instance (optional, may) 1 Exactly one instance * Zero or more instances 1..* One or more instances (at least one) 3 Three only 2 9 Two to nine

22 Relationship Example:

23 Example: Ticketing Step 2 DestinationList 1 searches 1 Customer 1 * contains chooses Destination uses PaymentA uthagency 1 buys use DebitCard * 1 processes 1 1 includes 1 CreditCard procees Ticket * * 1

24 Step 3: Refine Relationships Inheritance Aggregation Composition

25 Inheritance Classes support inheritance: child and parent classes. Child classes derived from a parent class will inherit all of the operations and attributes of the parent. Child classes may override or modify attributes and operations that they inherit from the parent. Child classes may also define new attributes and operations that are not part of the parent class. This is called specialization. In UML, inheritance is referred to as generalization.

26 Inheritance Example: FacePart We are doing a system for face recognition and we have a parent class FacePart. FacePart contains attributes location, name, center, length, and width. Nose, Ear and Chin children classes are derived from the parent FacePart class. This means that the Nose class also contains the attributes: location, name, center, length, and width. In addition, the Nose class adds specific attributes for shape and color, Also methods Blow(). The child class Ear also inherits all attributes and operations from FacePart. In addition it adds attributes like pierced or piercings, and clean. Chin adds an additional attribute bearded.

27 Inheritance Example: FacePart FacePart location:int[] name:string length:int w idth:int Clean():void hurt():void Nose color:int shape:int Blow ():void Ear pieced:bool piercings:int clean:bool Chin bearded:bool

28 Hierarchical Inheritance

29 Inheritance Inheritance has the advantages of (when done properly) reducing the amount of code that needs to be developed, tested, and documented as well as promoting commonality of function within a system, All of these reduce the total lifecycle cost of software. IMPORTANT NOTE: When considering Inheritance, make sure that the children objects are NOT just instances of the parent. A test for this is whether the child actually has additional attributes, and/or operations, and/or overrides parent attributes and/or operations. In most programming languages, private members will not be inherited.

30 Multiple Inheritance A child class can be derived from multiple parent classes. The resulting child class inherits all operations and attributes from each of its parents. Multiple inheritance is supported by many programming languages and often can help produce very rich objects.

31 Multiple Inheritance problems Major problems or complexities with multiple inheritance during design are name collisions and difficulty with modifying diagrams (due to the complexity). Name collision is when two base or parent classes have common attribute or operation names. Major problems later in the software lifecycle can include debugging and maintenance issues once the code is implemented. It may be hard to figure out where attributes and operators are actually coming from. Use Multiple Inheritance sparingly.

32 Aggregation Some objects are made up of other objects. These are type of collection class. For instance a peanut butter and jelly sandwich is made up of bread, peanut butter, jelly (and sometimes other things like bananas, etc.). PBJSanwich Bread 1...* Jelly 1...* 1...* PeanutButter

33 Composition A composition relationship represents a whole part relationship and is a type of aggregation. A composition relationship specifies that the lifetime of the part classifier is dependent on the lifetime of the whole classifier.

34 Example: Ticketing Step 3 DestinationList Customer Card PaymentAut hagency searches 1 1 pay_with 1 1 * 1 proce ss chooses buys * Destination * Ticket CreditCard DebitCard 1 1

35 Step 4: Add Attributes and Operations Attributes: previously identified using noun identification method additional properties/information related to each object Operations: circle all verbs, remove redundancies, and add as methods Key issue: make sure operation is of the correct class! Appropriate names! See programming ground rules.

36 Example: Ticketing Step 4 DestinationList Customer Card PaymentAuthAgency search():void sort():void searches cusname BuyTicket Pay CancelTicket pay_with 1 1 name:string number:string ProcessPayment():void * 1 process 1 1 * Destination name:string EAT:String cost:float buys chooses * Ticket departure:string time:string CreditCard expiredate:string securitycode:string DebitCard PIN:String

37 Rules for Class Diagrams class names: nouns (occasionally, noun phrases) Capital first letter attributes: nouns usually: lower case first letter operations: verbs/verb phrases or nouns if value-returning carefully distinguish, place attributes and operations use associations for complex objects, don't duplicate as attributes All: legal identifiers in target language no reserved words no illegal characters Just a starting point - more later

38 CRC Method CRC: Class Responsibility Collaboration CRC cards are an object oriented design tool (for brain storming) CRC cards are index cards including: the class name its super and sub classes (if applicable) responsibilities of the class names of other class with which the class will collaborate to fulfill its responsibilities the author Class: Superclass or Subclasses: Responsibilities Collaborators

39 CRC Design Process For each candidate class, the team fills in a card that contains the name of the class, the functionality of the class (responsibilities), and a list of the other classes it invokes to achieve that functionality (collaborations). This information comes from requirements and/or scenarios Next, the Cards are taped to a wall and lines or strings connect the public methods and data of all classes. Too many lines means high interconnectivity, which causes problems Can also mean class is doing too much Solution: split the class or move responsibilities to another class Finally, add details for attributes and methods

40 CRC Card Example Class: Elevator Button Superclass: Responsibilities Collaborators

41 CRC Card Example Class: Elevator Button Superclass: Button Responsibilities Request desired floor Request close door Request door open Request alarm Request elevator halt Collaborators User Elevator Control Elevator Control Elevator Bell, Elevator Phone Elevator Control Issue: 5 responsibilities is a lot! Use inheritance, introduce more button types Floor button, Door button, Close button, Alarm button, Halt button

42 Cohesion and Coupling Cohesion: A measure of the extent to which related aspects of a system are kept together in the same module, and unrelated aspects are kept out. A component should be single minded! Coupling: A measure of interconnection and dependency between modules/classes. Make components as independent as possible! Most popular phrase in OO design: high cohesion and low coupling!

43 Cohesion For simple systems, cohesion is not a significant problem. For large, complex systems, low cohesion generally means more maintenance and testing costs; it can also lead to security problems. The evolution of cohesion includes: Coincidental cohesion (worst) Logical cohesion Temporal cohesion Procedural cohesion Communicational cohesion Functional cohesion (best)

44 Coincidental Cohesion Parts of a module are grouped arbitrarily (randomly). Parts have no significant relationship. Example: put all code in the main function Causes: lack of creativity and/or experience rigid rules about module lengths maintenance without a design process can destroy structure, (for example we need to add this someplace, let s just put it in here. )

45 Coincidental Cohesion (2) Problems created by low cohesion: maintenance nightmares: cannot find defects or good places to extend functionality, hard to reuse such pieces, low efficiency, lots of data passing, harder to test, etc.

46 Logical Cohesion Parts of a module are grouped because they are logically categorized to do the same thing, even if they are different by nature. Example: group all I/O handling into one class (diskio(), screenio(), etc.) At least this is predictable and one can generally find a function when needed!

47 Logical Cohesion (2) Sometimes it is used to isolate code that is platform dependent and will need to be rewritten or seriously modified when ported to another platform. Example: put all device drivers in one module. Problems: interfaces hard to understand may lose efficiency due to data passing hard to scale up/distribute across multiple processors or computers. hard to reuse pieces may be nearly impossible to follow the flow.

48 Temporal Cohesion Parts of a module are grouped by when they are processed. The parts are processed at a particular time in program execution. Example: a function which is called after catching an exception which closes open files, creates an error log, and notifies the user. There use to be a need for this: When memory was very small (32K or smaller) and virtual memory was not common, programs had to be overlaid We wanted to minimize the number of times needed to save state, roll a chunk of program out of memory, and roll in a new chunk of program. Problems: not any better than logical cohesion.

49 Procedural Cohesion Parts of a module are grouped because they always follow a certain sequence of execution Example: a function to check file permissions and then open the file Problem: no better than temporal cohesion it is essentially temporal cohesion with added restriction that all the parts of the module correspond to a related action sequence in the program

50 Communicational Cohesion Parts of a module are grouped because they operate on the same data. Example: Combine multiple calculations in a loop like mean, min, max and standard deviation computed in the same loop. Functions that calculate and print based on the same data: addscorescomputemeanprintmean(). Benefit: Sometimes this is done to improve efficiency (avoid multiple data passing). Problem: low reusability.

51 Functional Cohesion Parts of a module are grouped because they all contribute to a single well-defined task of the module. Example: I/O One directory structure for each device, within which a class for Input and a class for Output, who are children of abstract I/O class. Functional cohesion is the ultimate goal! Methods are short and to the point. Ones related are grouped together locally in a file. Advantages: high reusability, extensibility, and maintainability

52 Exercise class Areas { double circlearea() {... } double rectanglearea() {... } double trianglearea() {... } } class Plane { double speed, altitude; takeoff() {... } void fly() {... } void land() {... } } class MyFunctions { void initprinter() {... } double calcinterest() {... } Date getdate() {... } } class Init { void initdisk() {... } void initprinter() {... } void initmonitor() {... } } // logical cohesion // communicational cohesion: // they all work on speed and altitude // coincidental cohesion // temporal cohesion

53 Coupling Coupling is a measure of interconnection and dependency between modules/classes. Given two classes A and B: If A knows B through its interface only Loosely coupled If A interacts with B also via non-interface stuff of B Tightly coupled Goal: low coupling This gives simple connections between modules.

54 Different Types of Coupling Content coupling (Worst/highest) Common coupling Control coupling Stamp coupling Data coupling (Best/lowest)

55 Content Coupling Module A modifies or relies on the internal workings of another module B (e.g. accessing local data of another module). Therefore changing the way B produces data (location, type, timing) will lead to changing the dependent module A. Example: no get/set methods, all data are public. goto statement Identify a content coupling issue if you are: using pointer to access private data of other classes (C++) branching into the middle of a subroutine (multiple entry points)

56 Common coupling Two modules have read/write access to the same global data. Changing the shared resource implies changing all the modules using it. Example: global variables. Always try your best to avoid using global variables! Single module with write access where all other modules have read access is not common coupling Problem: Hard to track down who made the change and who is changing.

57 Control Coupling One module A controls the logic of another module B, by passing B information on what to do. Example: passing a control flag or switches. Class B{ public void Do(int what){ if (what == 1) do_wow; else if ( what == 2 ) do_blabla; } } Class A{ void ControlDo( ) { B.Do(1); } Problem: often generalize a function beyond their original purpose, adding unnecessary complication. Module A and B are not independent: hard to reuse code. }

58 Stamp Coupling Also known as Data-structured coupling. Modules share a composite data structure and use only a part of it, possibly a different part. Example: passing a whole record to a function which only needs one field of it. Problem: Efficiency? Reusability? maintenance? employee = { age = 24, compensation = 2000 } def age_range(employee) range = 1 if employee.age < 10 range = 2 if employee.age > 10 && < 20;... return range end def compensation_range(employee)... only relies on employee.compensation end

59 Data Coupling Modules share data through parameters. Just the data needed are passed between the calling and called modules through parameters. A simple argument list and every item is used. Parameters are not passed several levels deep. Variables are not reused. Example: // In Class A: B.add(num1,num2); Parameter based communications: GOOD! a parameter has one and only one purpose in life.

60 Summary Analysis Phase and Design Phase Object Models Object Classes and Associations Class Diagrams Name Identification Method Associations Inheritance (is-a) Aggregation (part-of) Relationships CRC card Cohesion and Coupling