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 !

DateWeekTopicHand OutDue BackTest 6-Sep-131Administrivia / Overview / Motivation, benefits of OO 13-Sep-132Use CasesLab 1: Use cases 20-Sep-133CRC Cards, collab graphsLab 2: CRC cardslab 1 5% 27-Sep-13 4start class diaglab 2 5% 4-Oct-135Finish class diag, AssociationsLab 3: Class Diag 11-Oct-136Inh & Polymorphism / midterm reviewlab 3 5% 18-Oct-137midtermMidterm 25% 25-Oct-13Reading Break 1-Nov-138Interaction diag / Design PatternsLab 4: Interaction Diag 8-Nov-139Good Design / Modules & Packages / Deployment and component diagrams /Metrics / SOLID Lab 5: Critiqueslab 4 5% 15-Nov-1310State diagrams / Activity diagrams / Summary and Conclusion / The Future 22-Nov-1311Critiquescritique lab (before class) 15% 29-Nov-1312Critiques TBDFinal ExamFinal 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

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

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"); //or r.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 abstractions Kate 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

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... Truck314 Shipment306 …

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 Example The 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 9 2 or 81. The complexity of B is 0 and C is 36.

Kate Gregory Coupling Pick any two classes within your system and ask yourself what kind of coupling exists between them: 1.No coupling – completely independent 2.Data coupling – one calls methods of the other and passes in data parameters 3.Stamp coupling – both take the same record type as a parameter to their methods 4.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 22 nd 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

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 22 nd start of class sharp! –Sign up for a presentation slot