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

Modeling the run-time view! Software Design Today Modeling the run-time view! Software Design Metrics Classification Code Review

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

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. Exit condition: Passenger has 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. 25

UML Sequence Diagrams In requirements analysis In system design Passenger 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 TicketMachine selectZone() insertCoins() pickupChange() pickUpTicket() 38

UML Sequence Diagrams: Nested Messages Passenger TarifSchedule Display ZoneCheckbox selectZone() lookupPrice(selection) price Dataflow 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 39

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 40

Sequence Diagram Object Message Activation blinkHours() blinkMinutes() incrementMinutes() refresh() commitNewTime() stopBlinking() pressButton1() pressButton2() pressButtons1And2() :WatchUser :Time :LCDDisplay :SimpleWatch Message Activation 18

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)

Statechart Diagrams State Initial state Event Transition Final state button1&2Pressed button1Pressed button2Pressed Increment Minutes Hours Blink Seconds Stop Blinking Initial state Event Transition button1&2Pressed Final state 19

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 45

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

Measuring quality of abstractions We will never make an ultimate design on the first try. Design is an incremental and iterative process! How can we know if our architecture is well designed? When shall we stop the design process? Five meaningful metrics: 1. Coupling 2. Cohesion 3. Sufficiency 4. Completeness 5. Primitiveness

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.

Coupling Aggregation = weak coupling Composition = strong coupling TicketMachine 3 Aggregation = weak coupling ZoneButton Composition = strong coupling Exhaust System 1 0..2 Muffler Tailpipe Button ZoneButton CancelButton Inheritance = strongest coupling

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

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.

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!

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

Measuring quality of abstractions Five meaningful metrics: 1. Coupling 2. Cohesion 3. Sufficiency 4. Completeness 5. Primitiveness What are the important choices?

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.

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.

Choosing operations What is a Method? Function (check state) Procedure (change state) A mixture of the above?

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.

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

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."

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

Choosing implementation, example Class Square_Efficient_Storage { int width; void setWidth(int width) { this.width = width; } int getArea() { return width*width; … Class Square_Efficient_Computation { int area; area = width*width; return area; The most common trade-off is storage versus computation. Example: 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.

ZZZZZZ...oxygen anyone?

What is this? ?

It’s this!

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.

Classification: Snake, Lion or Giraffe?

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.

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.

Classification The developer has two primary design tasks, to find: Key abstractions Discover the classes and objects that form the vocabulary of the problem design. Mechanisms Invent relational structures for meeting requirements of collaborative behavior.

Classification... ...is about finding common attributes!

Classify... ...the trains by yourself! Select any method that You deem proper. 3 minutes

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!

To classify... ...is easier when more is known! What if: triangles = atomic waste squares = persons Systems experts are vital!

Who is right?

Recap Implementation Program to an interface, not an implementation! Operations Reusability, Complexity, Applicability, Primitiveness Method: Function (check state) or Procedure (change state)

The first quiz will be on the next lecture (Friday, September 13) Will cover the material of the first 5 lectures

That’s all folks! Thanks for your attention!