Recap : UML artefacts. Black Box Requirements. Functional Specification. System. System. Test. Design. System. System. Development.

Transcription

1 L5-1 Recap : UML artefacts Actors Use Cases Use Case Diagrams Storyboards Black Box Requirements System Validation Test Cases System Test Functional Specification System Development Notes Details Signatures System Design Diagrams: Class Sequence Statechart Activity L5-2 1

2 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

3 Use Case Example Name: Purchase ticket Participating actor: Passenger Entry condition: Passenger standing in front of ticket distributor. Passenger has sufficient money to purchase ticket. Event flow: 1. Passenger selects the number of zones to be traveled. 2. Distributor displays the amount due. 3. Passenger inserts money, of at least the amount due. 4. Distributor returns change. 5. Distributor issues ticket. Exit condition: Passenger has ticket. L5-5 UML Sequence Diagrams TicketMachine Passenger selectzone() insertcoins() pickupchange() pickupticket() In requirements analysis To refine use case descriptions to find additional objects ( participating objects ) In system design to refine subsystem interfaces Columns = classes Arrows = messages Narrow rectangles = activations Dashed lines = lifelines L5-6 3

4 UML Sequence Diagrams: Nested Messages Passenger ZoneCheckbox TarifSchedule Display selectzone() lookupprice(selection) Dataflow price displayprice(price) 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

5 Sequence Diagram Object :WatchUser :SimpleWatch :LCDDisplay :Time pressbutton1() pressbutton1() blinkhours() blinkminutes() pressbutton2() pressbuttons1and2() stopblinking() incrementminutes() refresh() commitnewtime() Activation Message L5-9 alt (conditional) opt (optional) par (run in parallel) loop (iteration) region (one thread) neg (invalid) ref (reference: defined in another diagram) Sequence Diagrams Interaction Frames L5-10 5

6 Statechart Diagrams Event button1&2pressed Blink Hours Initial state button2pressed Increment Hours State Transition button1pressed button1&2pressed Blink Minutes button2pressed Increment Minutes button1pressed Stop Blinking button1&2pressed Blink Seconds button2pressed Increment 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

7 UML artefacts Black Box Requirements System Validation Test Cases System Test Actors Use Cases Use Case Diagrams Storyboards Functional Specification System Development Notes Details Signatures System Design Diagrams: Class Sequence Statechart Activity L5-13 Measuring quality of abstractions We will never make an ultimate design on the first try. Five meaningful metrics: Design is an incremental and iterative process! How can we know if our architecture is well designed? When shall we stop the design process? 1. Coupling 2. Cohesion 3. Sufficiency 4. Completeness 5. Primitiveness L5-14 7

8 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 Composition = strong coupling 3 ZoneButton Exhaust System Aggregation = weak coupling 1 Muffler 0..2 Tailpipe Button Inheritance = strongest coupling CancelButton ZoneButton L5-16 8

9 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

10 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 L

11 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. L

12 To contract out behavior to: 1. one operation simpler interface large complex operations unmanageably modules 2. several operations complex interface simpler operations fragmentation Choosing operations 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? L

13 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 Trees of classes with a common super class Small classes Exploits commonality Hard to understand Combination Hard to define Hard to achieve Successful trade-off Aggregation or Composition Forests of loosely coupled classes Large classes May not exploit commonality Easier to understand L

14 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!!! L

15 Choosing implementation, example Example: The most common trade-off is storage versus computation. Imagine a square, which has a width. Should we store the area or calculate it each time we need it? The answer is to store if focus is on speed, and to calculate if focus is on space efficiency. Class Square_Efficient_Storage { int width; void setwidth(int width) { this.width = width; } int getarea() { return width*width; } } Class Square_Efficient_Computation { int width; int area; void setwidth(int width) { this.width = width; area = width*width; } int getarea() { return area; } } L5-29 ZZZZZZ...oxygen anyone? L

16 What is this?? L5-31 It s this! L

17 Classification The identification of classes and objects involves both discovery and invention. Discovery: Recognizing key abstractions and mechanisms, that form the vocabulary of the problem domain. Invention: Devising generalized abstractions as well as new mechanisms that specify how objects collaborate. Classification is grouping common structures or behavior. L5-33 Classification: Snake, Lion or Giraffe? L

18 Classification Classification help us identify generalization, specialization and aggregation hierarchies among classes. Coupling and cohesion is metrics for the commonality among classes and objects. The best software designs look simple, but it takes a lot of hard work to design a simple architecture. L5-35 Evolving classification Derivation Creating new subclasses from existing ones. Factorization Splitting a large class into several smaller ones. Composition Create one larger class by uniting smaller ones. Abstraction Discover commonality and devise a new class. L

19 Classification The developer has two primary design tasks, to find: 1. Key abstractions Discover the classes and objects that form the vocabulary of the problem design. 2. Mechanisms Invent relational structures for meeting requirements of collaborative behavior. L5-37 Classification......is about finding common attributes! L

20 Classify......the trains by yourself! Select any method that You deem proper. 3 minutes L5-39 The trains classified... One solution per person is likely! Half of the solutions are unique! Some examples: The length of the trains The color of the wheels Curved lines in the letters (A E F H I vs. B C D G J) Some solutions are more inventive than others, especially when using non-linear thinking and creative insight! L

21 To classify......is easier when more is known! What if: triangles = atomic waste squares = persons Systems experts are vital! L5-41 Who is right? L

22 Recap Implementation Program to an interface, not an implementation! Operations Reusability, Complexity, Applicability, Primitiveness Method: Function (check state) or Procedure (change state) L5-43 The first quiz will be on the next lecture (Friday, September 13) Will cover the material of the first 5 lectures L

23 That s all folks! Thanks for your attention! L5-45 L