Unified Modeling Language (UML)

1. Unified Modeling Language (UML) “ a language for specifying, visualizing, and constructing the artifacts of software systems, as well as for business modeling” • unification of Booch, Jackobson and Rumbaugh modeling approaches • graphical depiction of O-O analysis and design models • Use cases: functional reqts. (what) • Class diagrams: static structure of objects, their data and operations • State diagrams: dynamic models of objects change their state in response to events • Sequence diagrams: dynamic models of interaction between objects

2. Benefits of O-O modeling • Increased consistency among models developed for analysis, design and programming • Improved communication among users, analysts, designers, programmers • Explicit representation of commonality among system components • Reusability of analysis, design and programming results • Robustness of systems • Ability to tackle more challenging problem domains

3. Student Course name dateOfBirth year address phone code dept title creditHours calc_age() calc_gpa() register(course) enrollment() prereqs() :Course J.Daniels:Student code=IDS405 dept=IDS title=blah_blah creditHours=3 name=Jack Daniels dateOfBirth=01/01/99 year=senior

4. Attributes Anatomy of a class Encapsulation:All information is packaged under one name, and can be reused as one specification or program component Information hidingAttributes of a class can be accessed only through the class operations/methods/services (external interface for a class) • Reduced impact of side effects of changes • More cohesive methods • Class is de-coupled from other parts of system Operations/ methods

5. State of an object: values for attributes, and links to other objects Object identity Operations (service provided by an object to its client) • Constructor: creates a new instance of an object-class • Query: does not change state of object, no side-effects. -no need to explicitly show operation like get_name() -target object is always an implicit argument • Update: alters the state of an object

6. Customer Product Line 1 1 Places Includes 1..* * * 1..* Requests Order Product Class Diagram (ORD) : object-class associations Object Diagram: instance diagram - graph of instances that is compatible with a given class diagram.

7. :Customer A :Customer A :Customer A :Order 1 :Order 1 :Order 1 Object (Instance)diagram :Product A2 :Product A6 :Product P5 :Product X6 :Product P2 :Product Line A :Product Line P :Product Line X

8. * * tutor Student Course * * pupil Tutors Registration Account Issues beginDate numHours term grade acctNum password serverSpace * 0..1 CheckEligibility()

9. Software tool * * * Course Student user forum Log beginDate expirydate hoursLogged estimateUsage()

10. Course Offering Course Student Code title crdHours term section Name ssn dateOfBirth /age Scheduled-for Registers-for * * * 1..* registrants * * /participants {age = currentDate - dateOfBirth} Derived attribute, association

11. Course Offering Course Student {abstract} Name ssn dateOfBirth Code title crdHours term section Scheduled-for Registers-for * * * 1..* registrants enrollment() enrollment() register-for(class) calc_tuition() • Abstract class • Concrete class • Abstract operation • polymorphism Grad-Student UG-Student ugMajor greScore tuition=300 satScore actScore tuition=250 Calc_tuition() Calc_tuition()

12. University Aggregation 1 1..* 1..* 1 1 School Building Admn.Unit Composition 1 1 20..* * Department Room Composition: part belongs to only a single whole, and dies with the whole

13. Object Communication Through Message Passing: Message: request sent by an object for the services/assistance of a second object. Receiving object responds by choosing appropriate method, executing it and returning control to caller. E.g.: Customer wants to check status of an order Order Customer Message request O# ODate O-Status ... Display Status of order#1267 AddOrder() ModifyOrder() DisplayStatus() ...

14. POLYMORPHISM: Same named behavior may be completed differently for different object classes 1 Customer * Withdraw() Bank Account Checking Account Saving Account Withdraw() Withdraw() Passbook Account Saving Invst Account Withdraw() Withdraw() Bank Acct X X: Withdraw()

15. Object Behavior design • Assign methods to classes Rental Category Rental Order Line Due-Date Rental Tape TapeName Rental Order RO# • Method Determine DueDate ----- Which Class ?

16. Assigning Methods to Classes : • try to assign method to class that knows the required attributes • assign method to class that is logically expected t perform the method

17. Object Behavior Analysis: some guidelines • Methods should be distributed fairly evenly among classes, so that you avoid having a few “control” objects and many “data” objects • When possible, assign method to class that knows the attributes needed to perform the method • when no single class knows all the attributes needed, assign method to the class that would be logically expected to perform the method

18. Guidelines [contd] • Methods used to create and break relationships should be assigned to the class that controls the relationship • Method that changes the state of an object should be assigned to the class. • When in doubt, act it out!

19. Example Rental Customer Authorized User Rental customer can exist without be associated with Authorized User, but not vice-versa. So, method AddAuthorizedUser() should be assigned to Rental Customer (the controlling class) Example Two classes: Account and Payment. A method reportStatus(..) returns values “overdue” or “paid”. Which class should contain this method?

20. Example Method addAccount() creates a relationship between a Customer instance and an Account instance. Each customer can be related to zero or many Accounts objects, but each Account object must be related to exactly one Customer object.Which class should this method be assigned to? Example A method calcExtendedPrice(..) multiplies the quantity of a line item by the price of the line item. Quantity is an attribute of LINE-ITEM and price is an attribute PRODUCT. Should this method be assigned to LINE-ITEM or PRODUCT?

21. Evaluating Object-behavior design • Present functionality vs. future adaptability (reusability) • Coupling: • should not have to pass a lot of data between objects - no message should need more than three parameters • No messages should be sent from sub-classes to access data in a super-class - taken care of by inheritance. • Coupling is a natural side-effect of specialization and composition relationships - however, collaboration relationships should not be so strong that Class-A and useless without Class-B.

22. Evaluating Object-behavior design [contd.] • Cohesiveness • single functionality per method Eg. completeOrderFooter(..) that also prints the order - two separate methods better • overriding of attributes and methods defined in a super-class should not be too frequent. • Clarity • Complexity vs. reusability • neither too deep, nor too wide

23. Evaluating Object-behavior design [contd.] • Simplicity • should not have too many methods in a class • 5 or 6; number of attributes less than twice number of methods • too many methods signify an application specific definition of a class, which will be difficult to reuse. • “Act-ability” • high quality OO design can be acted out be humans playing the role of objects • can be verified by a structured walk-through • mappings between real-world objects and system objects should be transparent.