Analysis I [A&N 6-11]

1. Analysis I[A&N 6-11]

2. “Analysis” as a core WF within UP • Typical deliverables: • updated project plan, • use case models • static and dynamic models • executable architectural baseline Inception Elaboration Construction Transition • requirement • analysis • design • implementation • test Iteration: 1 2 3 4 5 ... time

3. The “analysis” work flow • Goal: • identify key concepts in our business domains, and model those as so-called analysis classes • identify relation between those classes • also called: static/architectural model • model how those classes interact to realize your use-cases • also called: dynamic models (also referred to as “use case realization”)

4. UML’s object orientation • UML: • An object is an thing with attributes, which can change over time • It may have responsibilities to do certain things when requested  operations • Note the UML terms : • attributes and operations … vs variables and methods as in Java • Objects can collaborate, by sending each other messages  calling operations. p : Product price = 10 color = blue p : Product price = 9 color = blue s : ShopOwner p : Product price = 10 color = blue setPrice(9)

5. Class description, fully decorated <<entity>> Product + code : String + name : String [2] + price : Int = 0 + priceAfterDiscount(Discount d) : Int + priceAfterTax(Discount d, Tax t) : Int stereotype with multiplicity initial value • visibility: +, - • # (protected)  can be accessed by subclasses • ~ (package) • class-scoped (static) members  underlined Multiplicity specifies that an “item” occurs multiple times: [2] [0..2] [0..*], or just * [1..*]

6. 3 Analysis-level classes • However, at the analysis level your focus is on capturing concepts • focus on the big picture (details in other WF) • should be in terms of your business domain • should be meaningful to stakeholders Product + code : String + name : String [2] + price : Int = 0 + priceAfterDiscount(Dicount d) : Int + priceAfterTax(Discount d, Tax t) : Int Product name price priceAfterDiscount () priceAfterTax() vs

7. Analysis class • Sources to find them: your requirements, e.g. use cases • Noun/verb analysis A fragment from a use-case: The system inspects the basket to determine which item to buy. The system then determines the price of the item. The system shows the item’s description and price to the customer. This price is then charged to the customer. Noun / noun-phrases  class Possessed noun / np  attribute Verb  responsibility/operation

8. Noun/verb analysis A fragment from a use-case: The system inspects the basket to determine which item to buy. The system then determines the price of the item. The system shows the item’s description and price to the customer. This price is then charged to the customer. • Nouns • system • basket • item • (item’s) price • (item’s) description • customer • Responsibilities • to inspect basket to determine which item to buy • to determine the price of the item to buy • to show the item’s desc and price • to charge price to a customer Then assign responsibilities, e.g. : System inspectBasket charge

9. CRC • You can do it in conjunction with N/V analysis • Class Responsibility Card (CRC) analysis  brainstorm • Ask people to represent classes; ask then which responsibilities each want to take • For each responsibility, ask if he still needs collaboration  parameters or associations • Collaborators : other classes needed for class X to fulfill its responsibilities. • As you go you may discover you need more analysis classes class: System • Responsibilities: • InspectBasket • charge • Collaborators: • Basket • Customer

10. CRC • Responsibilities • to inspect basket to determine which item to buy • to determine the price of the item to buy • to show the item’s desc and price • to charge price to a customer class: Basket • Responsibilities: • calcPrice • Collaborators: • Item Item price desc System inspectBasket(basket) charge(customer) Basket calcPrice()

11. Example: web-ads • Actors: site owner, advertiser • Functionalities: add and remove advertisement, get ad’s statistic, charge advertiser. • Analysis classes : ad, site owner, advertiser, ads manager

12. Distributing top level responsibilities Class : Advertiser Resp. Adding ad Removing ad View his ad’s statistics • Collab. • Manager • Manager • Ad Class: Ad Resp. - Collab. - Collab. Ad Class: Manager Resp. Charge advertiser Class: Site Owner Resp. - Collab. -

13. You may choose to model 2nd level responsibilities ... These are 2nd level tasks/responsibilities needed to realize the top level. Don’t go to far within your Analysis part; you should focus on identifying what the tasks are, and less on how to realize them. This is the task for your Design part. Class : Advertiser Resp. Adding ad Removing ad View his ad’s statistics • Collab. • Manager • Manager • Ad Collab. Ad Class: Manager Resp. Charge advertiser Adding ad Removing ad Collab. - Class: Ad Resp. keep track number of clicks

14. Cohesion : you may need to separate these ... your business data  “entities” Item possible, but will get us in problem later, as the coding of user interface, such as “showing” becomes intertwined with your business logic. Customer • Responsibilities • to inspect basket to determine which item to buy • to determine the price of the item to buy • to show the item’s desc and price • to charge price to a customer Basket control classes BuyPanelUI boundary classes, e.g. UI

15. You can use RUP stereotyping of analysis classes • RUP stereotypes  identify the following stereotypes: • <<boundary>> class • <<control>> class • <<entity>> class Arlow’s Enterprise Pattern and MDA gives detailed templates for typical business-system stereotypes  so you don’t have to come up from scratch. A stereotype (UML): a variation of an existing model element, with the same form (e.g. attrs and relations), but with a modified intent. <<entity>> Item <<control>> Basket A <<include>> B UML provide a whole list of standard stereotypes. <<entity>> Customer <<boundary>> BuyPanelUI

16. Association: structural relations between classes • Association enables collaboration recall CRC. (or to put it differently, collaboration may thus requires association) E.g. your requirement may state: A visiting customer gets a basket, where items she selects to buy will be put in. Implying , roughly said, a customer has a basket, and a basket contains an item. called a “class diagram” owns consists of Customer Basket Item

17. Association reading direction, roles, and multiplicities owns Customer Basket association name, with direction < owns Basket Customer roles owner basket Customer Basket [0..1] 1 An association can have name, or roles, or both. But in [A&N] the last is considered as a bad style (*).

18. Multiplicity • Can express important business rules, e.g. • Frequently appearing relations: • one-one • one-to-many • many-to-many • A customer may own multiple basket, but not more than 10. • A basket must have an owner. Customer Basket [0..10] 1 Husband Wife 1 1 Husband Wife 1 * Husband Wife * *

19. Multiplicity • Constraints should be reasonable  refer to your requirements: Basket Item is this reasonable? * [1..*] • Other things ... • Syntax: [minimum…maximum], number, * ; see more in A&N • If no multiplicity is given, then it is unspecified. There is no default multiplicity! • Leave unspecified if you deliberately want to • postpone specifying it • let it unspecified

20. Association class salary employs Company Person [0..1] * employs salary .... where to put this attribute?? Company Person * * Job salary Every instance of this assoc is described by an instance of its assoc. class. An instance of such a model: c : Company p : Person j : Job the “employs” link between c and p should be somehow decorated with its own Job object.

21. “Circular/reflexive” association sponsors > * • A customer may sponsor 0 or more customers • A customer may be sponsored by a customer Customer [0..1] These are all valid instances of the above model: e : Customer c : Customer d : Customer f : Customer g : Customer h : Customer

22. Generalization/specialization Item - name : String - price : int + canDeliver(l : Location) : boolean • You inherit class “members”; what else? • You can add new members • You can override • “Abstract” class and operations; UML syntax: italic. (not very useful at the analysis-level models, more relevant for design-level) consists of superclass (more general ) Basket * • Computer • OS : OS • + getOS() : OS Software + canDeliver(l : Location) : boolean subclass (more specific) overridden operation

23. Polymorphism (OO) • An OO program is polymorphic in the sense that when it expects an object of a class C, it can be substituted with an object from any subclass of C. • But then the behavior of a subclass should be a “refinement” of its superclasses! Liskov Substitution Principle: • Adding new members and overriding can screw things  UML does impose subclassing must be “consistent” ... but leaves out too much on what “consistent” is. If q is a property provable about all objects x of class C, then q should also be a property of all objects y of any subclass C.

24. Overriding • Overriding in ItemA respects Liskov. • Overriding in ItemB not! (for 2 reasons...)  bad pre: 0<d post: 0<result Item price : int priceWithDiscount (d) pre: 0<=d post: 1<result pre: 0<d<=50 post: 0 <= result ItemA priceWithDiscount (d) ItemB priceWithDiscount (d)

25. So, how do we solve this? They share a lot of aspects; so you want to generalize. But, should Circle be a subclass of Ellipse, or the other way around? Ellipse radius radiusy calcArea () resize(rx,ry) Circle radius calcArea () resize(r) Circle CircleLike radius calcArea () resize(r) Ellipse radiusy resize(rx,ry)

26. Multiple inheritance Media name play() Item name price • Powerful modeling instrument • Subclass inherits from all its superclasses • Naming conflict (which “name” Song gets?), but there are solutions to this. • At the implementation level leads to some complication (we’ll return to this) Song

27. Example: how do we model this? • Students: • Bachelor, Master • External: other univ in NL, EU, non-EU • We maintain the courses they have passed: • Bachelor or master level

28. Options (1) (2) Student StdNr Name Student StdNr Name <<abstract>> ExternalStd homeUniv BachelorStd BachelorStd MasterStd MasterStd An external student is not a student. However, it is an abstract class. So there is no direct instance of it that you can use to replace a Student. So in that respect this design is safe. However, there is another issue: any bachelor student is now automatically an external student, which is not what we want. ExternalStd homeUniv An external student is neither bachelor nor master.

29. Options Course Name Code Load * has passed (3) Student StdNr Name ExternalStd homeUniv [0..1] NLExternalStd BachelorStd EUExternalStd MasterStd NonEUExternalStd This is not ideal either because e.g. an exchange student is now a “feature” of a student, and not a special kind of students.

30. Navigation parentOf Cat name eat() Shop name pet kid Kid name Parent parent 1 1 An instance of this model : bob:Kid s:Shop octo:Parent c:Cat Octo can refer to / call on bob’s stuff : kid.name But also to c’s stuff : kid.pet.name kid.pet.eat() But cannot refer to any stuff of s. Objects get auto-ability to “navigate” over associations to get other objects and collaborate with them .

31. Navigation Cat name eat() Kid name • But sometimes you want this: • UML gives three idioms to interpret navigability • Idiom-1 is most complete • “>” means navigable, “X” not-navigable • no decoration  undefined • Idiom-3 is incomplete, but mostly used in practice: X A B A can navigate to B, but not the other way around Navigable in both directions A B Other cases have no meaning  illegal.

32. Dependency consists of Basket calcPrice(c : Currency) Item * <<use>> Requirement: the price is expressed in a default currency. Currency You consider it is important to capture the dependency more explicitly in the model: supplier • “Dependency” : a relation where a ‘client’ depends in a way from a ‘supplier’ (yes, very broad concept...) • In class modeling: can be used to complement association. • Is not limited to relation between classes.

33. Dependency modeling is not limited to relation between classes Currency <<instantiate>> Basket calcPrice() <<use>> defaultCurrency : Currency

34. Few other types of dependency Customer name address Analysis-level model <<trace>> Customer name lives at Design-level model Address 1 <<derive>> 1 1 City Post-code More, see A&N

35. Generalization set and Power type <<powertype>> RegistrationCost cost : int Customer registeredCustomer { disjoint } : RegistrationCost Special Free Premium VIP Rarely used…

36. Package Diagram • Use packages to group models together; very useful when you have lots of models. • Public, private • UML package also models namespace. CustomerPckg Currency + Profile <<import>> + Customer + Address <<use>> ... - Policy ...

37. Not used, future backup

38. Java’s object orientation • Java; what is your concept of “object” ? • UML’s concept is not much different, but since you also use UML to discuss models with shareholders, you need to talk in a more abstract terminologies. class ShopOwner { List<Product> products ; ... public void setPrice(int k, int p) { x = products.get(k) ; x.setPrice(p) ; } } class Product { int price ; Color color ; ... public void setPrice(int p) { price = p ; } } How do you call these ?

39. How A&N explains it.. “association” owns Customer Basket <<instantiate>> <<instantiate>> <<instantiate>> c : Customer b : Basket “link”, corresponds to actual pointer/reference in implementation. A bit over-diagramed. We won’t use this too often; but at least now you know how to read it.

40. Example: SchetsPlus Ok, to draw I need a drawing board, a pen, and a gum: DrawingBoard SchetsPlus Pen Gum Now, where do these concepts fit in? Line Text Shape FreeForm FilledRectangle Rectangle • Were do these responsibilities fit in? • drawing a shape • clearing board • rotating board • setting pen color • undo-ing the last draw

41. SchetsPlus; possible solution DrawingBoard clear() rotate() 1 setTxtMode() setDrawMode(shape) setGumMode() SchetsPlus 1 1 Pen setColor(c) Gum gum(points) 0..1 0..1 Text draw(string) Shape draw(points) FilledRectangle Rectangle Line FreeForm

42. Example: SchetsPlus’s UI DrawingBoard clear() rotate() 1 SchetsPlus 1 1 Pen setColor(c) setTxtMode() setShape(shape) Gum gum(points) 0..1 0..1 Text draw(string) Shape draw(points) * SchetsPlusUI ShapeButton • Were do these things fit in ? • free-form shape button • rectangle shape button • clear and rotate buttons • pen color combobox • drawing canvas * LineButton BoardButton FreeFormButton ClearButton RotateButton

43. Optimize the packaging... Product Sales • Model-level packages typically map to implementation packages, which further maps to partitioning of your development, testing, and maintenance teams. • For maintenance, package your classes so that: • the coupling between packages are minimized • the packages are still cohesive reorganize...? Product Management Customer Management