CTIS 359 Principles of Software Engineering SOFTWARE DESIGN OO(A)D

Size: px

Start display at page:

Download "CTIS 359 Principles of Software Engineering SOFTWARE DESIGN OO(A)D"

Alisha Riley
5 years ago
Views:

1 CTIS 359 Principles of Software Engineering SOFTWARE DESIGN OO(A)D

2 Today s Objectives To explain the basic concepts of OO(A)D To describe some best practices regarding to OO(A)D

3 What is NOT UML? The UML is NOT OOA/D or a method, it is just a diagramming notation. It is useless to learn UML and perhaps a UML CASE tool, but not really know how to create an excellent OO design, or evaluate and exisiting one. Source: Applying UML & Patterns, Craig Larman Page 4

4 You may follow Domain Model 2. Domain Model Refinement 3. System Sequence Diagrams (=SSD) 4. Operation Contracts (=OC) 5. UML Code Mapping 6. Software Class GUI Classes

5 What is a domain model? OOAD Applying UML notation, a domain model is illustrated with a set of class diagrams in which NO operations (method signatures) and NO software artifacts (e.g., a window, a database) are defined. Source: Applying UML & Patterns, Craig Larman Page 134

6 What is a domain model? OOAD (Cont.) Domain model may show Conceptual classes (or domain objects) Associations Attributes of Conceptual Classes Source: Applying UML & Patterns, Craig Larman Page 134

7 What is a domain model? OOAD (Cont.) A Domain Model is an OOA construct that: Shows abstractions (conceptual classes) in the problem domain, NOT the solution domain Is best kept at high level so as to verify with end users, and other stakeholders Is built over several iterations

8 What is a domain model? OOAD (Cont.) X X

a list of existing conceptual class categories best

9 Strategies for building a conceptual classes Method 1)Reuse or modify the existing models Method 2) Draw from a list of existing conceptual class categories best practices Method 3) From nouns in the use cases text (=descriptions)

10 What is a domain model? OOAD (Cont.) 1. List the candidate conceptual classes using the Conceptual Class Category List and noun phrase identification techniques related to the current requirements under consideration. 2. Draw them in a domain model. 3. Add the associations necessary to record relationships for which there is a need to preserve some memory. 4. Add the attributes necessary to fulfill the information requirements

11 List of existing conceptual class categories Method 2 Conceptual Class Categories business transactions Guideline: These are critical (they involve money), so start with transactions. transaction line items Example(s) Sale Payment Reservation SalesLineItem Guideline: Transactions often come with related line items, so consider these next. product or service related to a transaction or transaction line item Guideline: Transactions are for something (a product or service). Consider these next. Flight Seat Meal Item Source: Applying UML & Patterns, Craig Larman Page 140-1

12 List of existing conceptual class categories (Cont.) Conceptual Class Categories where is the transaction recorded? Guideline: Important. roles of people or organizations related to the transaction; actors in the use case Guideline: We usually need to know about the parties involved in a transaction. place of transaction; place of service Store Example(s) Register Ledger FlightManifest Cashier Customer Store MonopolyPlayer Passenger Airline Airport Plane Seat Source: Applying UML & Patterns, Craig Larman Page 140-1

13 List of existing conceptual class categories (Cont.) conceptual class categories catalogs Guideline: Descriptions are often in a catalog. containers of things (physical or information) things in a container other collaborating systems Example(s) ProductCatalog FlightCatalog Store Bin Board Airplane Item Square (in a Board) Passenger CreditAuthorizationSystem AirTrafficControl Source: Applying UML & Patterns, Craig Larman Page 140-1

14 List of existing conceptual class categories (Cont.) conceptual class categories noteworthy events, often with a time or place we need to remember physical objects Guideline: This is especially relevant when creating device-control software, or simulations. descriptions of things Guideline: See p. 147 for discussion. Example(s) Sale Payment MonopolyGame Flight Item Register Board Piece Die Airplane ProductDescription FlightDescription Source: Applying UML & Patterns, Craig Larman Page 140-1

15 List of existing conceptual class categories (Cont.) conceptual class categories records of finance, work, contracts, legal matters financial instruments schedules, manuals, documents that are regularly referred to in order to perform work Example(s) Receipt Ledger MaintenanceLog Cash Check, LineOfCredit TicketCredit DailyPriceChangeList RepairSchedule Source: Applying UML & Patterns, Craig Larman Page 140-1

16 From nouns in the use cases text Method 3 Linguistics Analysis Identify nouns & noun phrases in the textual description of domain, and consider them as candidate conceptual classes or attributes. Source: Applying UML & Patterns, Craig Larman Page 140-1

17 From nouns in the use cases text Method 3 Example Source: Applying UML & Patterns, Craig Larman Page 140-1

18 From nouns in the use cases text Method 3 (Cont.) Guideline: Care must be applied with this method; a mechanical noun-to-class mapping isn t possible, and words in natural languages are ambiguous. Source: Applying UML & Patterns, Craig Larman Page 140-1

19 Partial Domain Model Example Source: Applying UML & Patterns, Craig Larman Page 133

20 Benefit of Using Domain Models Lower the representation gap with OO modeling Source: Applying UML & Patterns, Craig Larman Page 138

21 Description Classes Add a description (conceptual) class (for example, ProductSpecification) when: There needs to be a description about an item or service, independent of the current existence of any examples of those items or services. Deleting instances of things they describe (for example, Item) results in a loss of information that needs to be maintained, due to the incorrect association of information with the deleted thing. It reduces redundant or duplicated information. Source: Applying UML & Patterns, Craig Larman Page 147

22 Description Classes WORSE BETTER Source: Applying UML & Patterns, Craig Larman Page 147

23 UML Association Notation Associations in a Domain Model Associations for which knowledge of the relationships needs to be preserved for some duration (miliseconds, maybe years) Associations derived from the Common Associations List Source: Applying UML & Patterns, Craig Larman Page 151

24 UML Association Notation (Cont.) An association is represented by a line between classes with Capitalized association name. An association is inherently bidirectional = Capitalized Source: Applying UML & Patterns, Craig Larman Page 151

25 UML Association Notation (Cont.) Association Name Reading Direction Arrow (Optional) Default Left Right Top Bottom Multiplicity Source: Applying UML & Patterns, Craig Larman Page 152

26 Common Association List Category A is a transaction related to another transaction B A is a line item of a transaction B A is a product or service for a transaction (or line item) B A is a role related to a transaction B A is a physical or logical part of B A is a description for B Examples CashPayment Sale Cancellation - Reservation SalesLineItem - Sale Item SalesLineItem (or Sale ) Flight Reservation Customer - Payment Passenger - List Seat Airplane Square Board Drawer Register ProductDescription Item FlightDescription Flight Square Board Source: Applying UML & Patterns, Craig Larman Page 155

27 Common Association List(Cont.) Category A is physically or logically contained in/on B A is known/logged/recorded/reported/c aptured in B A is a member of B A is an organizational subunit of B A uses or manages or owns B A is next to B Examples Register Store Passanger Airplane Sale Register Reservation FlightManifest Piece Square Cashier Store Pilot Airline Department Store Maintenance Airline Pilot Airplane Player Piece SalesLineItem SalesLineItem Square-Square City-City Source: Applying UML & Patterns, Craig Larman Page 155

28 No Attributes Representing Foreign Keys Attributes should NOT be used to relate concepts in the conceptual classes in domain model. The most common violation of this principle is to add a kind of foreign key attribute, as it is typically done in relational database designs, in order to associate two types. Source: Applying UML & Patterns, Craig Larman Page 165

29 No Attributes Representing Foreign Keys (Cont.) WORSE BETTER Do not use attributes as foreign keys Source: Applying UML & Patterns, Craig Larman Page 165

30 Domain Model (2) Refinement Generalization and specialization are fundamental concepts in domain modeling. Conceptual class hierarchies are often the basis of the inspiration for software class hierarchies that exploit inheritance. Source: Applying UML & Patterns, Craig Larman Page 501

31 Domain Model (2) Refinement (Cont.) Class hierarchy with separate and shared arrow notations. Source: Applying UML & Patterns, Craig Larman Page 505

32 Domain Model (2) Refinement (Cont.) Legal conceptual class partition, but is it useful in our domain? Source: Applying UML & Patterns, Craig Larman Page 505

Domain Model (2) Refinement (Cont.) Guideline Create a conceptual subclass of a superclass when: 1. The subclass has additional attributes of interest. 2.

33 Domain Model (2) Refinement (Cont.) Guideline Create a conceptual subclass of a superclass when: 1. The subclass has additional attributes of interest. 2. The subclass has additional associations of interest. 3. The subclass concept is operated on, handled, reacted to, or manipulated differently than the superclass or other subclasses, in ways that are of interest. 4. The subclass concept represents an animate thing (for example, animal, robot) that behaves differently than the superclass or other subclasses, in ways that are of interest. Source: Applying UML & Patterns, Craig Larman Page 508

Domain Model (2) Refinement (Cont.) Guideline Create a superclass in a generalization relationship to subclasses when: 1. The potential conceptual subclasses represent variations of a similar concept.

34 Domain Model (2) Refinement (Cont.) Guideline Create a superclass in a generalization relationship to subclasses when: 1. The potential conceptual subclasses represent variations of a similar concept. 2. The subclasses will conform to the 100% and Isa rules. 3. All subclasses have the same attribute that can be factored out and expressed in the superclass. 4. All subclasses have the same association that can be factored out and related to the superclass. Source: Applying UML & Patterns, Craig Larman Page 508

35 Domain Model (2) Refinement (Cont.) Justifying Payment subclasses Source: Applying UML & Patterns, Craig Larman Page 511

36 Domain Model Refinement (2) Abstract Conceptual Classes Definition If every member of a class C must also be a member of a subclass, then class C is called an abstract conceptual class. Source: Applying UML & Patterns, Craig Larman Page 513

37 Domain Model Refinement (2) Abstract Conceptual Classes (Cont.) Source: Applying UML & Patterns, Craig Larman Page 514

Domain Model (2) Refinement Association Classes Multivalued Guideline In a domain model, if a class C can simultaneously have many values for the same kind of attribute A, do not place attribute A in

38 Domain Model (2) Refinement Association Classes Multivalued Guideline In a domain model, if a class C can simultaneously have many values for the same kind of attribute A, do not place attribute A in C. Place attribute A in another class that is associated with C. For example: A Person may have many phone numbers. Place phone number in another class, such as PhoneNumber associate many of these to Person. Source: Applying UML & Patterns, Craig Larman Page 517

39 Domain Model (2) Refinement Association Classes (Cont.) Source: Applying UML & Patterns, Craig Larman Page 518

40 Domain Model (2) Refinement Association Classes Guideline Clues that an association class might be useful in a domain model: 1. An attribute is related to an association. 2. Instances of the association class have a lifetime dependency on the association. 3. There is a many-to-many association between two concepts and information associated with the association itself. Source: Applying UML & Patterns, Craig Larman Page 519

41 Domain Model (2) Refinement Association Role Names Guideline Each end of an association is a role, which has various properties, such as: name multiplicity Source: Applying UML & Patterns, Craig Larman Page 522

42 Domain Model (2) Refinement Association Role Names (Cont.) An explicit role name is NOT required it is useful when the role of the object is not clear. It usually starts with a lowercase letter. If not explicitly present, assume that the default role name is equal to the related class name, though starting with a lowercase letter. Source: Applying UML & Patterns, Craig Larman Page 519

43 Domain Model (2) Refinement Association Role Names (Cont.) Source: Applying UML & Patterns, Craig Larman Page 519

44 Domain Model (2) Refinement Association Role Names (Cont.) Same instance of a person takes on multiple (and dynamically changing) roles in various associations Source: Applying UML & Patterns, Craig Larman Page 519

45 You have done enough on STATIC modeling Need some DYNAMIC modeling

46 System Sequence Diagrams (=SSD) Having explored domain modeling, SSD will be used to identify SYSTEM operations. (their effect on the domain model objects will be discussed in OCs) An SSD shows, for a particular course of events within use case. Guideline: Draw an SSD for a main success scenario of each use case, and frequent or complex alternative scenarios. Source: Applying UML & Patterns, Craig Larman Page 175

47 System Sequence Diagrams (Cont.) Source: Applying UML & Patterns, Craig Larman Page 177

48 System Sequence Diagrams (=SSD) Don t draw an SSD for all scenarios, UNLESS you are using an estimation technique (such as Function Point Counting) that requires identification of all system operations. Source: Applying UML & Patterns, Craig Larman Page 180

49 Operation Contracts Having explored SSDs and system operations, Operation Contracts takes the system operations and define their effect of the domain object models. Source: Applying UML & Patterns, Craig Larman Page 181

50 Operation Contracts Example Operation: Cross References: Preconditions: Postconditions: Contract CO2: enteritem enteritem(itemid: ItemID, quantity: integer) Use Cases: Process Sale There is a sale underway. - A SalesLineItem instance sli was created (instance creation). - sli was associated with the current Sale (association formed). - sli.quantity became quantity (attribute modification). - sli was associated with a ProductDescription, based on itemid match (association formed). Source: Applying UML & Patterns, Craig Larman Page 183

51 Analogy: The Spirit of Postconditions: The Stage and Curtain Why write postconditions in the past tense? Think about them using the following image: The system and its objects are presented on a theatre stage. 1. Before the operation, take a picture of the stage. 2. Close the curtains on the stage, and apply the system operation (background noise of clanging, screams, and screeches ) 3. Open the curtains and take a second picture. 4. Compare the before and after pictures, and express as postconditions the changes in the state of the stage (A SalesLineItem was created ). Source: Applying UML & Patterns, Craig Larman Page 186

52 UML Code Mapping The enteritem interaction diagram Source: Applying UML & Patterns, Craig Larman Page 249

53 UML Code Mapping (Cont.) Source: Applying UML & Patterns, Craig Larman Page 249

54 UML Code Mapping (Cont.) Source: Applying UML & Patterns, Craig Larman Page 377

55 UML Code Mapping (Cont.) class Payment // all classes are probably in a package named // something like: package com.foo.nextgen.domain; public class Payment { private Money amount; public Payment( Money cashtendered ){ amount = cashtendered; } public Money getamount() { return amount; } } Source: Applying UML & Patterns, Craig Larman Page 377

56 UML Code Mapping (Cont.) Class ProductCatalog public class ProductCatalog { private Map<ItemID, ProductDescription> descriptions = new HashMap()<ItemID, ProductDescription>; public ProductCatalog() { // sample data ItemID id1 = new ItemID( 100 ); ItemID id2 = new ItemID( 200 ); Money price = new Money( 3 ); ProductDescription desc; desc = new ProductDescription( id1, price, "product 1" ); descriptions.put( id1, desc ); desc = new ProductDescription( id2, price, "product 2" ); descriptions.put( id2, desc ); } public ProductDescription getproductdescription( ItemID id ) { } return descriptions.get( id ); } Source: Applying UML & Patterns, Craig Larman Page 377

57 UML Code Mapping (Cont.) public class Register { private ProductCatalog catalog; private Sale currentsale; public Register( ProductCatalog catalog ) { this.catalog = catalog; } public void endsale() { currentsale.becomecomplete(); } public void enteritem( ItemID id, int quantity ) { ProductDescription desc = catalog.getproductdescription( id ); currentsale.makelineitem( desc, quantity ); } public void makenewsale() { currentsale = new Sale(); } public void makepayment( Money cashtendered ) } { currentsale.makepayment( cashtendered ); } Source: Applying UML & Patterns, Craig Larman Page 377

58 Software Class GUI Classes Source: Applying UML & Patterns, Craig Larman Page 313

language that you are going to implement.

59 OO Design OO Programming Language During the OO Design process, you should also consider the characteristics of the programming language that you are going to implement. Characteristics of the programming language impose critical constraints on the overall system design.

60 Characteristics of some widely used OO PL Feature Smalltalk C++ Eiffel Java C# Strong Typing optional Static/dynamic Typing D S S S+D S+D Garbage Collection X Multiple Inheritence X X X Pure Objects X X X Dynamic Loading X X Standardized class libraries Correctness Costructs X X X X X X Source: Object Oriented Systems Analysis and Design using UML, 3/e Page 87

61 End Any questions/suggestions?

Object-Oriented Functional Analysis and Design for POS Example

Object-Oriented Functional Analysis and Design for POS Example Focus in Analysis, Design, Implementation Analysis Investigation to the problem in problem domain Design Logical solution(model) for implementation