L5-1 Recap : UML artefacts Actors Use Cases Use Case Diagrams Storyboards Black Box Functional Requirements Specification Diagrams: Class System System Sequence Test Design Statechart Activity Test Cases System System Development Validation Notes Details Signatures L5-2 1
Today • Modeling the run-time view! • Software Design – Metrics • Classification • Code Review L5-3 Modeling using UML Diagrams are the main artefacts of UML. ( These are not a sequence of steps!!!! ) • Use case diagrams – Functional behavior of the system as seen by the user. • Activity diagrams – Dynamic behavior of a system expressed as a flowchart. • Class diagrams – Static structure of the system: Objects, Attributes, and Associations. • Sequence diagrams – Dynamic behavior between actors and system objects. • Statechart diagrams – Dynamic behavior of an individual object. • ... L5-4 2
Use Case Example Name: Purchase ticket Event flow: 1. Passenger selects the number Participating actor: Passenger of zones to be traveled. 2. Distributor displays the Entry condition: amount due. • Passenger standing in front 3. Passenger inserts money, of of ticket distributor. at least the amount due. • Passenger has sufficient 4. Distributor returns change. money to purchase ticket. 5. Distributor issues ticket. Exit condition: • Passenger has ticket. L5-5 UML Sequence Diagrams • In requirements analysis To refine use case descriptions TicketMachine Passenger to find additional objects selectZone() (“participating objects”) • In system design to refine subsystem interfaces insertCoins() • Columns = classes • Arrows = messages pickupChange() • Narrow rectangles = activations • Dashed lines = lifelines pickUpTicket() L5-6 3
UML Sequence Diagrams: Nested Messages ZoneCheckbox TarifSchedule Display Passenger selectZone() lookupPrice(selection) price displayPrice(price) Dataflow … to be continued... • The source of an arrow indicates the activation which sent the message • An activation is as long as all nested activations L5-7 Sequence Diagram Observations • UML sequence diagram represent behavior in terms of interactions – Run-time view • They complement class diagrams, which represent structure – Compile-time view • Very useful for finding participating objects • Time-consuming to build but worth the investment where interactions are complex L5-8 4
Sequence Diagram Object :SimpleWatch :LCDDisplay :Time :WatchUser pressButton1() blinkHours() pressButton1() blinkMinutes() pressButton2() incrementMinutes() refresh() pressButtons1And2() commitNewTime() stopBlinking() Message Activation L5-9 Sequence Diagrams – Interaction Frames • alt (conditional) • opt (optional) • par (run in parallel) • loop (iteration) • region (one thread) • neg (invalid) • ref (reference: defined in another diagram) L5-10 5
Statechart Diagrams State Initial state Event button2Pressed button1&2Pressed Blink Increment Hours Hours Transition button1Pressed button2Pressed button1&2Pressed Blink Increment Minutes Minutes button1Pressed button1&2Pressed button2Pressed Stop Blink Increment Blinking Seconds Seconds Final state L5-11 Summary • UML provides a wide variety of notations for representing many aspects of software development – Powerful, but complex language (keep it simple!) – Can be misused to generate unreadable models (automatic generators) – Can be misunderstood when using too many exotic features (KISS!) • We concentrate only on a few notations: * Functional model: use case diagram * Object model: class diagram * Dynamic model: sequence, statechart and activity diagrams • UML is not a methodology, but the textbook describes a methodology that uses UML L5-12 6
UML artefacts Actors Use Cases Use Case Diagrams Storyboards Black Box Functional Requirements Specification Diagrams: Class System System Sequence Test Design Statechart Activity Test Cases System System Development Validation Notes Details Signatures L5-13 Measuring quality of abstractions We will never make an ultimate Five meaningful metrics: design on the first try. Design is an incremental and 1. Coupling iterative process! 2. Cohesion 3. Sufficiency How can we know if our 4. Completeness architecture is well designed? 5. Primitiveness When shall we stop the design process? L5-14 7
Coupling "Coupling is the strength of association between modules." Strong coupling makes a system harder to understand, change or correct. Complexity can be reduced by designing for weak coupling. Inheritance introduces significant coupling! Thus, select inheritance as a design method restrictively. L5-15 Coupling TicketMachine Aggregation = 3 ZoneButton weak coupling Composition = strong coupling Exhaust System 1 0..2 Muffler Tailpipe Button Inheritance = strongest coupling CancelButton ZoneButton L5-16 8
Cohesion "Cohesion measures the degree of connectivity within a module." Try to avoid coincidental cohesion, where entirely unrelated abstractions form a class or module. Thus, struggle for well-bounded behavior, where functional cohesiveness is achieved (semantics kept within the module). A class should be focused on one kind of thing L5-17 Sufficiency "A sufficient module captures enough characteristics of the abstraction to permit meaningful and efficient interaction." Keep it small! Keep it simple! Sufficiency implies a minimal interface. L5-18 9
Completeness "A complete module captures all the meaningful characteristics of the abstraction." Completeness implies an interface that covers all aspects of the abstraction. Thus, an interface that is general enough to be commonly usable. It is very subjective, and is easily overdone! L5-19 Primitiveness "Primitive operations are those that can be efficiently implemented only if given access to the underlying representation of the abstraction." Each method should be focused on one thing L5-20 10
Measuring quality of abstractions Five meaningful metrics: 1. Coupling 2. Cohesion 3. Sufficiency 4. Completeness 5. Primitiveness What are the important choices? L5-21 Choosing operations Crafting an interface is plain hard work. As we do the design, we find patterns of abstractions that leads us to create new classes or to reorganize existing ones, incrementally . The aim to to create primitive operations, which exhibit a small well-defined behavior. We call these fine-grained . L5-22 11
Choosing operations To contract out behavior to: 1. one operation simpler interface large complex operations unmanageably modules 2. several operations complex interface simpler operations fragmentation This is one of the core arts in design. L5-23 Choosing operations What is a Method ? A) Function (check state) B) Procedure (change state) C) A mixture of the above? L5-24 12
Criteria for choosing operations 1. Reusability Would this behavior be useful in more than one context? 2. Complexity How difficulty is it to implement the behavior? 3. Applicability How relevant is the behavior to the type? 4. Implementation knowledge Does the behavior's implementation depend upon the internal details of a type? Defining utility classes can help keeping a class primitive. L5-25 Choosing relationships Class structure when using inheritance, aggregation and composition: Narrow and deep Balanced Wide and shallow Inheritance Combination Aggregation or Composition Trees of classes with a Hard to define Forests of loosely coupled common super class classes Hard to achieve Small classes Large classes Successful trade-off Exploits commonality May not exploit commonality Hard to understand Easier to understand L5-26 13
Choosing relationships, Rules of thumb Rule of thumb 1: "Inheritance is appropriate when every instance of one class may also be viewed as an instance of another class." IS-A Rule of thumb 2: "If the behavior of an object is more than the sum of its individual parts, then aggregation is probably the superior." HAS-A Rule of thumb 3: "Favor composition over inheritance." L5-27 Choosing implementation The representation (implementation) of a class should always be an encapsulated secret of abstraction . That is, hide the implementation! Program to an interface, not an implementation! This makes it possible to alter the implementation without violating the interface and behavior!!! L5-28 14
Choosing implementation, example Class Square_Efficient_Storage { The most common int width; trade-off is void setWidth(int width) { this.width = width; storage } versus int getArea() { return width*width; computation . } … } Example: Class Square_Efficient_Computation { int width; int area; Imagine a square, which has a width. void setWidth(int width) { Should we store the area or calculate it this.width = width; area = width*width; each time we need it? } The answer is to store if focus is on int getArea() { return area; speed, and to calculate if focus is on space efficiency. } … } L5-29 Z Z Z Z Z Z ...oxygen anyone? L5-30 15
What is this? ? L5-31 It’s this! L5-32 16
Recommend
More recommend
