OO Methodology Elaboration Iteration 3 – Part 1 Refining Models

2 Table of Contents Iteration 1 –Use-Case Model –Process Sale Use Case –Domain Model –Design Model Iteration 2 –GRASP: More Patterns for Assigning Responsibilities –Designing Use-Case Realizations with GoF Design Patterns Iteration 3 –Iteration 3 and Its Requirement –Related Use Cases –Modeling Generalization –Refining the Domain Model –Adding New SSDs and Contracts –Modeling Behavior in Statechart Diagrams –Designing the Logical Architecture with Patterns –Organizing the Design and Implementation Model Packages –Introduction to Architectural Analysis and the SAD –Designing More Use-Case Realization with Paterns –Designing a Persistence Framework with Patterns

3 Iteration 3 Requirements Handle credit payment authorization Provide failover to local services when the remote services cannot be accessed. Provide support for POS device handling, such as the cash drawer and coin dispenser Support for persistent objects

4 Relating Use Cases Three methods of relating use cases –include –extend –generalize The include relationship –a relationship from a base use case to an inclusion use case –specify how the behavior of the inclusion use case can be inserted into the behavior of the base use case –an inclusion use case represents encapsulated behavior that potentially can be reused in multiple base use cases –an inclusion use case is not a separate instantiable classifier –an inclusion use case sets attribute values in the base use case –the base use case must not access the attributes of inclusions Process SaleProcess Rental Handle Credit Payment >

5 The include Relationship Use Case: Process Sale (the base use case) Main Success Scenario: 1.Customer arrives at a POS... 7.Customer pays and System handles payment... Extensions: 7b. Paying by credit: Include Handle Credit Payment 7c. Paying by check: Include Handle Check Payment Use Case: Process Rental (the base use case) Extensions:... 6b. Paying by credit: Include Handle Credit Payment Use Case: Handle Credit Payment (inclusion use case) Level: subfunction Main Success Scenario: 1.Customer enters their credit information. 2.System sends payment authorization request to an external Payment Authorization Service System Extensions: 2a. System detects failure to collaborate with external system: 1. System signals error to cashier. 2. Cashier asks Customer alternate payment.....

6 The extend Relationship –a relationship from an extension use case to a base use case –The extension use case incrementally modifies the base use case in a modular way –a base use case defines a set of extension points, references of locations in the base case –an extension use case contains a list of one or more insertion segments –an extension use case accesses and modifies attribute values in the base use case –the base use case must not access the attributes of extensions Process Sale Extension Points: Payment VIP Customer Handle Gift Certificate Payment > Payment [Customer presents a gift certificate]

7 The extend Relationship Use Case: Process Sale (base use case) Extension Points: VIP Customer, step 1. Payment, step 7. Main Success Scenario: 1.Customer arrives at a POS... 7.Customer pays and System handles payment... Use Case: Handle Gift Certificate Payment(extension) Trigger: Customer wants to pay with gift certificate Extension Points: Payment in Process Sale Level: subfunction Main Success Scenario: 1.Customer gives gift certificate to Cashier 2.Cashier enter gift certificate ID....

8 The extend Relationship Example : ATM

9 The generalize Relationship –a taxonomic relationship between a child use case and the parent use case –the parent describes the characteristics the child shares with other use cases –the child inherits the behavior sequence of the parent and may insert additional behavior into it. –the child may modify behavior steps inherited from the parent Verify Identity Check Password Retinal Scan

10 Comparison of Use Case Relationships

11 Modeling Generalization Generalization-specialization class hierarchy Generalization is the activity of identifying commonality among concepts and defining superclass (general concept) and subclass(special concept) Generalization is different from inheritance –inheritance is a mechanism for combining shared incremental descriptions to form a full description of an element

12 Modeling Generalization Conceptual Subclass Definition Conformance –100% of the conceptual superclass’s definition shold be applicable to the subclass –the subclass must conform to 100% of the superclass’s attribute and associations (100% rule) Conceptual Subclass Set Conformance –all members of a subclass set must be members of their superclass set. (Is-A rule)

13 Modeling Generalization When to Define a Conceptual Subclass –the subclass has additional attributes of interest. –the subclass has additional associations of interest. –the subclass concept is operated on, handled, reacted to, or manipulated differently than the superclass or other classes –the subclass concept represents an animate thing that behaves differently than the superclass or other classes When to Define a Conceptual Superclass –the potential conceptual subclasses represent variations of a similar concept –the subclasses will conform to the 100% and Is-A rules –all subclasses have the same attribute which can be factored out and expressed in the superclass –all subclasses have the same associations which can be factored out and related to the superclass

14 Abstract Conceptual Classes If every member of a class C must also be a member of a subclass, the class C is called an abstract conceptual class

15 NextGen POS Class Hierarchies Payment Classes Authorization Service

16 NextGen POS Class Hierarchies Authorization Transaction Classes –Degree of generalization

17 Modeling Changing States Do not model the states of a concept X as superclasses of X. Rather either: –define a state hierarchy and associate the states with X –Ignore showing the states of a concept in the domain; show the sates in a state diagram instead. Transition between Non-member Customer and Member Customer ???

18 Constraints on Generalization A constraint on a generalization specifies further information about how the generalization could be used and extended Predefined constraints –overlapping –disjoint –complete –incomplete Worker ButcherBaker Candlestick Maker {overlapping, incomplete} Customer Female Customer Male Customer {complete,disjoint}

19 Association –Association is semantic relationship between two or more classifiers that involves connection among their instances –Each instance of an association(a link) is a tuple (an ordered list) of references to objects Structure Advanced Topics –association class –n-ary association –derived association –qualifier AB q_name:C 0..* role qualifier multiplicity rolename navigability association path aggregation/ composition associate association name

20 Association Class Association class is an association that is also a class It may have attributes, operations and associations with other classes Semantics –a link(instance) of an association class takes its identity from the object references in it. job1 : c1 – p1 job2 : c1 – p2 job3 : c1 – p1 –an association is a set of tuples and has no duplicates among its object references Company Person Job salary 0..* employer employee duplicate (not correct)

21 Association Class Consider the following associations –implicit relationship by Job class –provides duplicates in relationship among Company and Person objects c1 – job1 – person1 c1 – job2 – person2 c1 – job3 – person1 An Example 1. a person owns stock (some number of shares) of a company 2. a person purchased stock of a company several times each with different price at different time duplicate (correct) Company Person Stock quantity 0..* CompanyPerson Job salary 0..* 1 1 CompanyPerson Purchase salary date cost 0..* 1 1 buyer seller buyer

22 Association Class NextGen POS Requirements –Authorization services assign a merchant ID to each store for identification –A payment authorization request from the store to an authorization service needs the merchant ID –A store has a different merchant ID for each service Placing Merchant ID in the Store class or AuthorizationService –it is incorrect because a Store can have more than one value for merchantID A better solution, not yet useful

23 Association Class Final Solution : using an association class Guidelines for adding association classes –an attribute is related to an association –instances of the association class have a life-time dependency on the association –there is many-to-many association between two concepts and information associated with the associated with the association itself –a link (an instance of association) is identified by two objects in it.

24 n-ary Association An association among three or more classes each instance of the association is an n-tuple of values from the respective classes Properties –navigability is meaningless –multiplicity may be specified but is less obvious and complicated –aggregation is meaningless Generally, n-ary associations are useful only when all the values are needed to uniquely determine a link An n-ary association is almost always implemented as a class whose attributes include pointers to the participant objects Year Player Team season goal keeper team * * *

25 n-ary Association Multiplicity in n-ary association –the multiplicity is defined with respect to the other n-1 ends. e.g. in a ternary association (A,B,C), the multiplicity in C states how many C objects may appear in association with a particular pair of A and B objects. Example: Course Registration –for a (course, student) pair, there is zero or one professor –for a (student, professor) pair, there are many courses –etc. Student Professor Course * * 0..1 Registration

26 n-ary Association Example(cont.) Student Professor Course * Registration * * 11 1 Student Professor Open Course 1 Registration 1..* * 11 1 Course * 1

27 Qualifiers Qualifier –a slot for an attribute or list of attributes on a binary association –the values of the attributes select a unique related object or a set of related objects from the entire set of objects –it is an index on the traversal of an association –qualified object vs target object –a qualifier always acts on an association whose multiplicity is many in the target direction The purpose of the qualifier is to reduce the multiplicity to one by adding the qualifier so that a query can be assured of returning a single value Bank account # Person * 1 multiplicity after qualification target class qualified class qualifier (bank, accont#) -> one person one person -> many (bank, account #)

28 Qualifiers Example Directory filename File * 0..1 (directory,filename) -> o or 1file directory -> many files file -> many (directory, filename) file-> many directories file -> many file names Directory filename File * * {same} same but different level of details (directory,filename) -> o or 1file directory -> many files file -> many (directory, filename) file-> 1 directory file -> many file names

29 Qualifiers Qualified Association in NextGen POS

30 Roles Role names Roles as Concepts vs Roles in Associations

31 Derived Elements Derived element is an element that can be computed from other elements and is included for clarity It is logically redundant and adds no semantic information Person birthdate /age { age = currentDate- birthdate } Company Person 1 * 1 * Department worksForDepartment /worksForCompany derived association

32 Constraints on Associations Ordered Exclusive-OR Insurance company Insurance contract Person Compnay {or} 1 0..* 1..* 0..*