About domain controllers Interaction diagrams Not usually a domain - PDF document

About domain “controllers” Interaction diagrams � Not usually a domain concept � Dynamic views of interacting objects – Added to the model during design – Starts by system event ( external message ) � They tie the system to external events – Receiving object either handles alone, or passes – e.g., classes a GUI will know about message along ( internal messages ) � Common types: � Links in diagrams indicate visibility between classes � Why bother diagramming? – Façade controller – represents whole system, overall business, “world” – e.g., an application coordinator – Easier to change drawing than code – Role controller – mimics a real-world role – Get big picture – better design, code, system – Use case controller – handles sequences of events, � Do together with class diagrams/specifications monitors use case progress � 2 basic types: sequence and communication � e.g., setEnabled(false) in Swing – means not ready yet Sequence diagrams Communication diagrams � Handy for more complicated interactions – show sequences by numbering the interactions � Use for simpler interactions – sequence easily shown as top-to-bottom interactions Notation for interactions More notation for interactions � Class vs. instance – � Conditions – [condition:boolean] – Sale – class name for static methods only – e.g., 1:[new sale]create() � – mySale:Sale – object name:type for other :POST------------------------:Sale � Messages – shown along link line – See fig. 15.30 (p. 244) for mutually exclusive – Must number in communication diagram conditions – Show parameters too (with optional types) � Use “stack” icon for multi-objects (collections) � e.g., 2: cost:=price(amount:double) – Note: message may be to the collection object itself – And return values if not void (e.g., a list), or to the individual elements if * � e.g., 1.1: items:=count():int � Show algorithms as notes (dog-ear symbol) � Iteration – use * and optional [iteration clause] – But only need if tricky or otherwise relevant – e.g., 3*: [i:=1…10]li:=item(i):LineItem 1

Design principles The expert principle � Assign responsibility to class that has the � Not exactly “rules” – things to consider necessary information – Should lead to high quality designs – i.e., the “information expert” � Easier to maintain, understand, reuse, and extend � Avoids passing info between objects – e.g., expert, low coupling, high cohesion, do-it-myself � Still have collaboration as objects help others � Note: Larman labels some as “patterns” – e.g., Sale knows about all LineItems , and – General Responsibility Assignment Software Patterns LineItems know quantity (and get price from Specs ) � Larman: assigning responsibilities = “desert island skill” � So let LineItem calculate subtotal() � Also notes: “one person’s pattern is another’s primitive � Sale accumulates total from subtotals building block” � Main benefit: encapsulation maintained – “Design patterns” usually are more specific – Easier to program, maintain, extend independently Low coupling High cohesion � Refers to functional cohesion � Minimize dependencies between classes – Means no class does too much work – especially not a – Note how expert principle does this too bunch of unrelated things – e.g., Sale does not contact ProductSpecification – Basically should avoid “bloated” classes directly – LineItem does that instead; otherwise, Sale � Hard to understand, maintain, reuse, … needs parallel collection of ProductSpecifications � Usually means other classes should take some � So fundamental it influences all design decisions responsibilities – Is an “evaluative” pattern – used to rate design quality – Like an overworked manager – should delegate more � Rule of thumb: insure all parts of a class are � Supports independent classes somehow related – all attributes and operations – More reusable, less subject to changes elsewhere, – Working together to provide “well-bounded behavior” easier to program, … � Benefits – the usual list, plus greater simplicity Events, states, and transitions Statechart diagrams � Purpose: to model the changing states of � Event – a significant occurrence complex objects – e.g., telephone receiver taken “off hook” Telephone � State – condition of an object at a moment in time (the time between events) initial state – e.g., telephone “idle” between being placed on hook and taken off hook off hook � Transition – relationship between two states as state Idle Active an event occurs on hook – e.g., when “off hook” event occurs, transition from “idle” to “active” state transition event 2

A use case statechart diagram Utility of statechart diagrams Process Sale � Normally not useful for internal events makeNewSale WatingForSale EnteringItems – Internal event – caused by an object inside the system enterItem boundary endSale – Because interaction diagrams already cover it authorized makeCashPayment WaitingForPayment � Useful for system as a whole – Especially to model changing system states during the makeCreditPayment course of a use case AuthorizingPayment makeCheckPayment � Larman calls it a use case statechart diagram � Helps designer insure things are done in the correct order � Note: many prior CS 50 students discovered this � Other notation: transition actions, guards, nested states – usefulness on their own see text figures 29.2 and 29.3 (pp. 489-90) – This quarter, we ask all of you to consider them More GRASP principles Software realities � Polymorphism – if behavior varies by type � Do-it-myself principle (a.k.a., animation pattern) – Assign responsibility for the variation to the types – Objects must do for themselves what normally is done to the real world objects they represent � Do not test for type or use other conditional logic! � e.g., in real world, somebody draws the figure – in software, � Indirection – to reduce coupling figure draws itself: figure.draw() – Assign responsibility to intermediate class or interface � e.g., trajectory.map() – normally mapped by outside observer if at all � Pure fabrication – artificial, non-domain class � Assume basic services are always available – Assign cohesive set of responsibilities to a fabrication – i.e., get/set for attributes, add/remove/… for lists, … � Protected variations – for variable/unstable parts – So no need to include in class diagrams or specs – Assign responsibilities to stable interfaces Inheritance – a software idea Diagramming generalization � An object-oriented software construct for � See figure 31.9 (p. 512) implementing generalization relations � Note: can overdo diagramming hierarchies – Can reuse code by inheriting it with new code – Show lower levels only if it helps communication � Allows consistent handling of different subtypes – Adding hierarchical levels increases complexity – As long as they have a common supertype � Harder to understand/explain � But can be overdone! � Opens door to team misinterpretation – e.g., see figure 31.10 (p. 513) – Common error: forcing an “is a” relationship – Another note: application of Bridge pattern (to be � e.g., class Easel extends Canvas – okay, but limited, because Easel cannot inherit from any other class now discussed) could simplify the design of fig. 32.9 – Alternative is composition � Question: what to do if new payment type like Debit card? � Solution involves abstract types � More flexible to let Easel have a Canvas to draw on 3