RUP: Elaboration Phases Moving to Design

Domain Model (partial) for POS System: Adding Attributes

SSD for a Process Sale scenario .

 but is iteratively deepened through the rest of the project plan The idea is to design  the actual software artifacts  but not build them  analogy might be blueprints for a building .Moving to Design   Design is initiated mainly in the UP elaboration phase iterations.

Moving to Design  The three key design issues (in the object-oriented paradigm):    must create the objects must create the operations must assign responsibility for the operations to appropriate objects software contract (already done) interaction diagram (today)    Artifacts associated with design   sequence diagram communication (collaboration) diagram   Class diagram (today) Some other possibly (later) .

How do we create the Objects?  Look at the domain model     choose objects associated with the real world makes initial design easier helps in assigning operations to objects helps in later maintenance: as the world changes it is clearer what is impacted in the software  There will likely be ³internal´ objects at the presentation and services layer  they will reflect natural categories at their layer standard software design clichés that can recommend objects  Design patterns  .

How do we create the operations?  The first place to look   at the system sequence diagrams. gives the main operations that cross the system boundary At the use cases. especially fully dressed ones the main success scenario will suggest the operations crucial to carrying out that success scenario alternative scenarios will suggest other operations standard software design clichés that can recommend operations create new operations or do your job with existing ones?  The next place to look     Design patterns   A Key Difficulty  .

Assigning Operations to Objects (details later)  The main technique used in assigning operations to objects is design patterns  GRASP principles (Larman)       Expert Creator Low Coupling High Cohesion Indirection Protected Variations   GoF (Gang of Four) design patterns massive number of design patterns created since GoF. for general and special purposes .

Interaction Diagrams  For every operation it is useful to diagram the steps it carries out.  the main message passing behaviour to achieve the operation at level of abstraction that is more conceptual than code sequence diagrams: essentially the same syntax as system sequence diagrams. but for internal system operations communication (collaboration) diagrams  Interaction diagrams allow this to be done   Two kinds   .

Sequence Diagram Syntax : R egister msg1() msg2() msg3() msg4() msg5() : Sale .

1: msg3() 2.C lassA 1: msg2() :C lassB 1.1: msg5() 2: msg4() :C lassC fifth 2.2: msg6() sixth :C lassD fourth .Communication Diagram Syntax first second third msg1() .

.enterItem Sequence Diagram { enterItem(id. // local visibility via assignment of returning object ProductSpecification spec = catalog. qty) { .. quantity) spec := getSpecification( itemID ) ...getSpecification(id).. } } : R egister : ProductC atalog enterItem (itemID .

  but is awkward to develop since you must anticipate every object that participates in the message before hand (see system sequence pay by credit scenario.Tips About Interaction Diagrams  Choosing between sequence and communication diagrams  sequence diagram shows explicit time-line. next slides) but is more flexible and closer to functional styles of method creation  communication diagram seems more jumbled.  . reading down.

see sub-operations in the pay by credit scenario. not a branch  Every solid arrow in an interaction diagram   You don¶t need a separate interaction diagram for each and every operation   some will be clearer when specified as sub-operations within another sequence diagram (e. not n+1 is a method call in the programming language: it is a call to a sub-function.g.i.Tips About Interaction Diagrams  Be sure to use numbering properly in communication diagrams  a sub message to message n is indicated with n. next slide) .

expiryD ate) reply := requestApproval(request) postR eceivable( receivable ) postSale( sale ) . quantity) description. total * [more items] endSale() taxLineItems := getT axes( sale ) total w ith taxes makeC reditPayment (credN um.POS Pay by Credit Scenario Process Sale Pay by C redit Scenario :N extG enPO S System : C ashier actor :T axC alculator actor :C reditAuthoriz ation Service actor :Accounts makeN ew Sale() enterItem(itemID .

The Class Diagram  Analogy: the class diagram is to design what the domain model is to analysis The class diagram summarizes      the main objects in the actual design (classes) the main associations and cardinalities between objects the main attributes and their type in each object the main operations assigned to each object (methods) what the main classes will be in the software and what methods each will be responsible for  The class diagram is a snapshot of   .

.) makePayment(... 1 getSpecification(.POS Class Diagram Store address : Address name : T ext addSale(....) 1 1 1 Sale date : D ate isC omplete : Boolean time : T ime becomeC omplete() makeLineItem(. * itemID : ItemID .) 1 Looks-in 1 ..) H ouses 1 1 R egister C aptures endSale() enterItem(..) makeN ewSale() makePayment(. ...........) getT otal() 1 D escribes 1 1 ProductSpecification ProductC atalog C ontains description : T ext price : M oney 1. * quantity : Integer getSubtotal() Logs-completed4 * 1 Paid-by 1 Payment amount : M oney ... U ses * SalesLineItem C ontains 1.

T hey are not the sam e thing.The Domain Model is not the Class Diagram U P D o m ain M o d el Stakeholder's view of the notew orthy concepts in the dom ain. ¡ ¡ ¡ A Paym ent in the D om ain M odel is a concept. Paym ent am ount inspires objects and nam es in Sale T his is one of the big ideas in object technology.. T his reduces the representational gap. Paym ent am ount: M oney getBalance(): M oney 1 Pays-for 1 date: D ate startT m e: T m e getT otal(): M oney . and its representation in softw are.. T herefore. but the form er inspired the nam ing and definition of the latter. the representational gap betw een how stakeholders conceive the dom ain. 1 Pays-for 1 date t me   ale . but a Paym ent in the D esign M odel is a softw are class. has been low ered. U P D esig n M o d el T he object-oriented developer has taken inspiration from the real w orld dom ain in creating softw are classes.

Visibility: the ability of one object to ³see´ or have a reference to another object  attribute visibility  B is visible to class A because B is an attribute of A: remains as long as class A exists B is visible to class A because B is passed as a parameter of a method of A: remains only while method is being executed B is visible to class A because B is declared as local within a method of A: remains only while method is being executed B is visible to class A because B is global to A: permanent  parameter visibility   local visibility   global visibility  .

quantity) : Register : ProductCatalog desc = getProductDesc( itemID ) . desc = catalog. . qty) { .... } public void enterItem(itemID..Attribute Visibility B is visible to class A because B is an attribute of A: remains as long as class A exists class Register { . } enterItem (itemID. private ProductCatalog catalog.....getProductDesc(itemID) .

. qty). qty) : roduct a talog ¦ £ a keLineIte ( roduct e scription desc.. int qty) ¤ £¢ { .1: create(desc.. sl = new SalesLineIte (desc. qty) :Sale 1: desc = get roduct e sc(id) ¤ £ 2.Parameter Visibility B is visible to class A because B is passed as a parameter of a method of A: remains only while method is being executed : e gister ¥ ¢ ¢ enterIte ( id. .. qty) ¢ 2: a keLineIte ( desc. } ¢ ¢ sl : SalesLineIte ¢ .

.ge t roduct e s(id). . // loca l visibility via a ssign e nt of re turning obje ct roduct e scription de sc = ca ta log. } : e giste r de sc = ge t roduct e sc( ite I : ) roduct a ta log e nte rIte (ite I .. qty) { ... qua ntity) .Local Visibility B is visible to class A because B is declared as local within a method of A: remains only while method is being executed e nte rIte (id.

because it persists as long as A and B exists One way to achieve global visibility is to assign an instance to a global variable. which is possible in some languages. such as Java. but not others. which we will discuss later   .Global Visibility  B is visible to class A because B is global to A: permanent. such as C++. The preferred method to achieve global visibility is to use the Singleton pattern.

Assigning Responsibility   What objects get which responsibilities? Responsibilities for ³doing´  an object doing something itself. such as:   creating an object doing a computation   initiating an action to be carried out by other objects controlling and coordinating activities in other objects knowing about private encapsulated data knowing about related objects knowing about things it can derive or calculate  Responsibilities for ³knowing´     There are good vs bad ways of assigning responsibilities .

Larman¶s GRASP Principles  Information Expert  assign a responsibility to the information expert. the class that has the information necessary to fulfil the responsibility a version of expert for creation: assign to B the responsibility of creating an instance of class A if       Creator  B contains A B aggregates A B has initializing data for A B records A B closely uses A  Controller  a version of expert for handling system events: the class responsible for handling system events should be a class representing the overall system. device or subsystem or a class representing a use case scenario within which the system event occurs .

objects are focussed assign the responsibility to an intermediate object to mediate between objects so they aren¶t tightly coupled identify points of predicted variation or instability and assign responsibilities to create a stable interface around them when related alternatives or behaviours vary by type. assign the responsibility for the behaviour using polymorphic operations to the types for which the behaviour varies  High Cohesion (evaluative)   Indirection   Protected Variations   Polymorphism  .The GRASP Principles (II)  Low Coupling (evaluative)  assign responsibilities so that unnecessary coupling remains low assign responsibilities so that cohesion remains high.

not a ProductSpecification.Use of the GRASP Principles by C ontroller by C reator enterItem(id. It may contain many SalesLineItems. List) C AU T IO N : T his is a multiobject collection (such as a M ap). not to a ProductSpecification. not a SalesLineItem.g. qty) :Sale 1: spec := getSpecification(id) 2. C AU T IO N : T his is a multiobject collection (such as a List).1: spec := find(id) 2.1: create(spec.. SalesLineItem :SalesLineItem :Product Specification add the newly created SalesLineItem instance to the multiobject (e. . It may contain many ProductSpecifications. qty) :Product C atalog sl: SalesLineItem by Expert 1.2: add(sl) T his find message is to the M ap object (the multiobject). qty) :R egister 2: makeLineItem(spec.

. . C us tom e r a rriv e s . the de s ign c la s s e s dis c ov e re d w hile de s igning U C R s c a n be s um m a riz e d in c la s s dia gra m s .. C a s hie r P roc e s s S a le c onc e ptua l c la s s e s in the dom a in ins pire the na m e s of s om e s oftw a re c la s s e s in the de s ign us e .. . qua ntity ) . .on dom a in c onc e pts U se-C ase M o d el : S y s te m P roc e s s S a le 1 ..) ...... C a pture d.c a s e re a liz a tion w ith inte ra c tion dia gra m s m a k e N e w S a le ( ) e nte rIte m ( id. 3 ...) : P roduc tS pe c ific a tion .. . P roduc tC a ta log . .... § U se C ases S y s te m S e que nc e D ia gra m s U s e C a s e D ia gra m s D e s ig n M o d e l : R e gis te r : P roduc tC a ta log c re a te ( ) : S a le R e gis te r 1 1 .. C a s hie r m a k e s ne w s a le .... qua ntity ) .... s y s te m e v e nts : C ashier make N e w S a le ( ) e nte rIte m ( id.. P roduc tC a ta log ge tS pe c ific a tion( . qua ntity ) s pe c := ge tS pe c ific a tion( id ) a ddLine Ite m ( s pe c ..Relationship of Various UP Artifacts D o m a in M o d e l S a le tim e S ta m p 1 R e gis te r 1 .... m a k e N e w S a le ( ) e nte rIte m ( ..

Sign up to vote on this title
UsefulNot useful