Week 9

• Lab 4 due now• Design Patterns• Good Design• Modules and Packages

– Deployment diagram– Component diagram

• SOLID Principles• Metrics• Lab 5 available – big one !

Date Week Topic Hand Out Due Back Test

6-Sep-13 1 Administrivia / Overview / Motivation, benefits of OO

13-Sep-13 2 Use Cases Lab 1: Use cases

20-Sep-13 3 CRC Cards, collab graphs Lab 2: CRC cards lab 1 5%

27-Sep-134 start class diag lab 2 5%

4-Oct-13 5 Finish class diag, Associations Lab 3: Class Diag

11-Oct-13 6 Inh & Polymorphism / midterm review lab 3 5%

18-Oct-13 7 midterm Midterm 25%

25-Oct-13 Reading Break

1-Nov-13 8 Interaction diag / Design Patterns Lab 4: Interaction Diag    

8-Nov-13 9 Good Design / Modules & Packages / Deployment and component diagrams /Metrics / SOLID

Lab 5: Critiques lab 4 5%  

15-Nov-13 10 State diagrams / Activity diagrams / Summary and Conclusion / The Future

22-Nov-13 11 Critiques critique lab (before class) 15%

29-Nov-13 12 Critiques

TBD Final Exam Final 40%

Kate Gregory

Principles of Good Design

• Maintain the independence of components.– as we go from a use case to a requirement to a

system component, each component must satisfy that requirement without affecting other requirements

• Minimize the information content of the design.– Keep it simple

Kate Gregory

Checklist• Each class has a single, clearly defined

purpose. • Lots of simple classes

– The less specialized the classes are, the more likely they will be reused.

• Common behavior (methods) moved to superclasses– But don’t overdo it!

• The superclass-subclass structure must make logical sense.

Kate Gregory

Coupling and Cohesion • Coupling is a measure of the strength of

association among objects.

• Cohesion is interactions within a single object or software component.

• Often lumped together because common design errors hurt both– Method in wrong class– Class too large– Class too small

Kate Gregory

Tightly Coupled Object

E

IHG

D

A B C

F

A Properly Coupled Design• Has less information passing

– If you split a class that belongs together, you must pass information between the two new classes that would have just all been available to member functions within the class.

– If you join two classes that should be separate, the new class will be coupled to all the things the two smaller ones were

• Passing less information between objects means less code to break when something changes.

A Cohesive Class

• Contains what it needs to do its work

• Can’t be split; it just wouldn’t make sense

• Doesn’t contain unrelated attributes or methods

• Has a single obvious name and purpose

Kate Gregory

What’s in it for you?• Keep things that have to change together as

close together as possible– That’s high cohesion, things belong together– Put code where you'd expect to find it

• Allow unrelated things in the code to change independently– That’s low coupling, things are insulated

• Minimize duplication– That’s instant reuse and appropriate coupling

Kate Gregory

Kate Gregory

Standardization Helps

• Design patterns provide a way to capture design knowledge, document it, and store it in a repository that can be shared and reused in different applications.

• Use implementation-specific foundation classes (.NET, STL, MFC, AWT, WFC, OWL, VCL…) so that all designers can count on capabilities

Kate Gregory

Modules, Subsystems, and Packages

• Gather classes together into groups– for assigning to developers– for building in specific languages– for deploying on specific computers– to separate functional groups

• Coupling must be minimized

Kate Gregory

Deployment Diagram

• Represents the computers on which objects are deployed

Kate Gregory

Component Diagram

• Packages, modules, subsystems

• May be deployed on same machine

Solid Principles

• S – Single Responsibility Principle

• O – Open-Closed Principle

• L – Liskov Substitution Principle

• I – Interface Segregation Principle

• D – Dependency Inversion Principle

Kate Gregory

Single Responsibility Principle

• “A class should have one, and only one, reason to change.”

• Requirements change.

• Classes with more than one responsibility are vulnerable against multiple requirements.

• Changing one responsibility may break another.

Kate Gregory

Open-Closed Principle

• “You should be able to extend a classes behavior, without modifying it.”

• Changing things can break other things– Encapsulation lets you change your inside– Is it possible to never change your outside?

• Add new subclasses that have new behaviour

Kate Gregory

Liskov Substitution Principle

• “Derived classes must be substitutable for their base classes.”

• This is just the IS-A rule, in disguise– We were using Liskov Substitution Principle

when we rejected rectangle IS A square and square IS A rectangle

Kate Gregory

Interface Segregation Principle

• “Make fine grained interfaces that are client specific.”

• We covered this when trying to design the inheritance hierarchy for the fleet– Putting ChangeOil in Vehicle made canoe etc

inherit it– Same problem with RotateTires– Solution: several small interfaces, used as needed

Kate Gregory

Dependency Inversion Principle

• “Depend on abstractions, not on concretions.”

• Don’t code your Invoice class to print the invoice to the screen, or to write to a file– Instead have it “print” to a “Writer” -

something that implements the Writer interface– Now it can be used in many more contexts

Kate Gregory

More on Dependency Inversion• Opposite of what most people do

Receipt r;… code to get the receipt set up somehow …r.SavePdf("c:\receipts\Dec10.pdf");//orr.PrintPdf("MachineA","PrinterB“);

• Depend on an abstraction: far more extendable later.

Kate Gregory

Inverted Dependency

• interface IWriter– FileWriter– PrinterWriter

IWriter w = new FileWriter(“c:\receipts\Dec10.pdf”);

Receipt r;… code to get the receipt all set up somehow …r.WritePdf(w);

Kate Gregory

Flexibility

• Someone else can write:

IWriter w = new PrinterWriter("MachineA","PrinterB");

Receipt r;… code to get the receipt all set up somehow …r.WritePdf(w);

• now the PDF comes out on the printer

• Don’t overuse abstractionsKate Gregory

The SOLID Principles

• You already knew them

• Now you have names for them– You can use these names in conversations and

arguments

Kate Gregory

Kate Gregory

Metrics• Analyze your model• Look for outliers -- highest and lowest values• Look for surprises• Ask WHY something is high/low/unusual• Consider splitting a class, combining two classes,

moving methods and attributes• Draw conclusions about your system

Kate Gregory

Associations in code

• On a class diagram, another object is not an attribute

• But when you write code, you must represent that association some way

• Typically there is an attribute holding a pointer/handle/reference whatever to the other object

• One way only? Two way?• Must be settled before you can perform metrics

Kate Gregory

Associations in code

• One way:– One object has a pointer / reference to the other– You have a way to set it.

• Change it? Ctor only?

• Two way:– Each object has a pointer / reference to the other– Each has a way to set it

• Change it? Ctor only?

– You have a way to be sure they are consistent

• Either way, list and count methods and attributes

Kate Gregory

Metrics

• Simple counting and dividing

• Inheritance metrics

• Module Relationships

• Coupling

• Cohesion

Kate Gregory

Simple Counting and Dividing• Count number of methods, number of

attributes, etc

• Look for outliers and surprises– All classes have 5-7 attributes but one has 75,

why ?– A class has one attribute and 20 methods to

access it. Does this make sense ?

• Do not report “ratio” as 4:3 but as 1.33– Easier to compare large list of them

Report Metrics in a Table

Kate Gregory

Class # of instance variables

# of class variables

# of public instance methods

. . .

Truck 3 1 4

Shipment 3 0 6

…

Kate Gregory

Inheritance Metrics• Taking each subclass in turn and looking at the

immediate superclass,– How many methods from the superclass were inherited

unchanged? How many were overridden?– How many new methods did you add in the subclass?

How many attributes?

• Moving downwards through the inheritance tree starting at the top, how many methods and attributes were added at each level?

• Usually a subclass uses most of the inherited functionality and overrides only a little.

Kate Gregory

Measuring Relationships• Tree Impurity

– A measure of how difficult changing the interface will be– Measures what happens if you break the rules in

subsequent versions (eg change the name of a public method)

• Complexity – fanin and fanout– A measure of whether this object is a root (bosses others

around, but no responsibilities) a leaf (responds to requests from others but has no knowledge of or dependency on other classes) or a middleman (worst of both worlds in terms of maintaining the class.)

Kate Gregory

Tree Impurity

• 2(e-n+1)/((n-1)(n-2))• e – edges – existence of a method call

between the classes – don’t give multiple points for multiple calls

• n – nodes – number of classes• between 0 and 1

Tree Impurity• 0 means each class “knows about” two

others (or when some know more, it’s balanced by those who know just one)

Kate Gregory

Tree Impurity

• 1 means each class “knows about” all the others

Kate Gregory

Complexity

• (fanin * fanout)2

• fanin – count all the methods of the object that other objects call, and add an extra point for each argument of those methods

• fanout – count all the methods of other objects this object calls, and add an extra point for each argument of those methods

Kate Gregory

Complexity ExampleThe fanin of A is 3 (the

Update() method and its two parameters.)

The fanout of A is 3 (the Create() method and its parameter, plus the Print() method.)

The complexity of A is 92 or 81. The complexity of B is 0 and C is 36.

Kate Gregory

CouplingPick any two classes within your system and

ask yourself what kind of coupling exists between them:

1. No coupling – completely independent2. Data coupling – one calls methods of the other

and passes in data parameters3. Stamp coupling – both take the same record type

as a parameter to their methods4. Control coupling – one calls methods of the other

and passes in parameters that control behaviour (eg a verbose/terse report to a PrintReport() call)

Kate Gregory

Coupling (cont)

5. Common coupling – both use the same global data (or read and write the same file, same database, etc)

6. Content coupling – one makes direct reference to the inside of the other (perhaps it’s a subclass or a C++ friend) 

In general, the lower the coupling the better.

Kate Gregory

Cohesion• Look at the classes in a given module and ask yourself

why they are in the same module. Do they exhibit:1. Functional cohesion – they combine to perform a single well-

defined function (such as “get order information from user” or “process payroll”)

2. Sequential cohesion – they combine to perform several functions that must occur in a specific sequence (such as “process all the deposits and then all the withdrawals”)

3. Communicational cohesion – they perform several different functions, but on the same body of data (such as “scheduling work hours, paying employees, and printing taxation paperwork”)

Kate Gregory

Cohesion (cont)

4. Procedural cohesion – they perform a variety of business functions that involve similar procedures in the software (such as “downloading exchange rates, uploading sales totals, and exchanging edi work orders all over the Internet”)

5. Temporal cohesion – they perform a variety of business functions on unrelated clumps of data, but all these function occur at the same time (such as “store opening functions” or “year end cleanups”)

6. Logical cohesion – there is a logical relationship of some sort among the various functions they perform (also known as grasping-at-straws cohesion)

Kate Gregory

Cohesion (cont)

7. Coincidental cohesion – there is no real reason for these classes to be in the same module (also known as “can we call a module Leftovers?”) Your goal is functional cohesion for every module. Never confess to anything lower than communicational cohesion if you can possibly help it.

Kate Gregory

Module metrics

• All of the metrics that apply between classes in a module can also be determined between modules in a system.

• Use metrics to assess not just whether your classes are designed well, but whether they are gathered into modules well

Kate Gregory

Critiques

• Make sure you are signed up for a presentation time!

• No matter when your presentation is: NO LATE CRITIQUES ACCEPTED. – Due at start of class on the 22nd

• I expect each of you to attend the entirety of both classes

Kate Gregory

Written Critique Tips

• Present the details in the order I asked for them– objective errors, opinions, inheritance, revised

deliverables, metrics, design principles, summary

• You must suggest changes and corrections if you say something is wrong

• You must provide anything you say is missing• You can highlight parts of the solution you liked

as well as those you think are wrong• Hint: for me, leaving something out is easier than

writing a bad version of it

Written Critique Tips

• You are expected to consider adding diagrams and deliverables you learned about after the critique was assigned

• You are allowed to add missing business rules, add classes, split classes, combine classes, move methods from one class to another, rename classes, change parameters and whatever else you feel is necessary to improve or fix the solution. Make sure you know why you are making that change.

• I will be marking on writing issues (spelling, grammar, organization, fonts, layout) as well as technical ones

Answers to FAQs• Do not ask me to mark your assignment in

advance. As always, I will mark it whenever you like, but I will only mark it once. It is a natural part of this assignment that you will find things confusing, wrong even, because there are things in the provided solution that are wrong.– Find them, comment on them, say how you would

do them. That is the point of the lab.

Kate Gregory

Answers to FAQs

• Show me the old deliverable (diagram etc) if you are going to point out errors in it. Ideally mark them in some way (circles, arrows etc)

• Do not show me anything I don’t need to see or “bulk up” the report with 3 or 4 versions of the same thing

Kate Gregory

Answers to FAQs• For each list, diagram or other deliverable I give you,

critique it. Does it have all it should? Does it have extra stuff? Are the decisions it demonstrates good ones?

• What matters is your intelligent defense of the position you have chosen.

• It is not possible to give an extension on this assignment. You must come and present when all the rest of your group does and you must hand in the written portion at the start of the first critique class.

One other thing• This lab has been around for a while

• I change it every year

• If I can tell you are using someone’s old solution, I will give the whole group ZERO– Report an error that is not in this year’s handout?– Use a section heading from last year’s outline?– Use last year’s order?– Omit a section that is new this year?– Don’t try it, don’t even think about it

Presentation Tips• Divide the work among the group members

– You will ALL lose marks if one of you doesn’t speak

– Plan in advance who will answer which kinds of questions

• Introduce each speaker

• Consider having one of you act as “MC”– Tell us who is going to talk about what, thank each

speaker– Monitor time for each speaker

Presentation Tips

• You can use the classroom projector to display tables, diagrams, or bullet points– Don’t use a tiny font– Don’t show too much of your report

• You only have ten minutes total

• Focus on what you want to demonstrate

– Bring your own laptop and practice in advance– Sit at the back of the room and see if its

readable

Kate Gregory

Kate Gregory

Presentation Tips• Rehearse, both alone and as a group

– Know your time limits and be sure you will hit them

– Practice asking each other questions

• Do not add material to your presentation after hearing others -- it won’t help you

• Do not write sentences and read them to us!

• Face the audience and keep your chin up

• Avoid holding your notes in your hand

Kate Gregory

Next Week• Read for next week:

– State Diagrams– Activity Diagrams

• Lab 5 - Critiques due Nov 22nd start of class sharp!– Sign up for a presentation slot