School of Business Administration Software Engineering Spring Term 2017 Marymount University School of Business Administration Professor Suydam Week 7

Agenda for Week 7 Mini-Project 2 Plan for March classes App C Essential Software Design Chap 8 Design Characteristics and Metrics Review Questions Case Study 3 – UML

Mini-Project 2 Due: 3/3/17

Week 7

Plan for March Classes

Case Study 3 UML & Textbook Appendix C MP3 App C UML Diagrams MP3 App C UML DFD Example 2, pg 312

Week 7 Chap 8 Design Characteristics and Metrics

Chapter 8 - Characterizing “Good” Design Besides the obvious - - - design should match the requirements - - - there are two “basic” characteristics -- Consistency across design : Common UI – looks, logical flow Common error processing Common reports Common system interfaces Common help All design carried to the same depth level completeness of the design All requirements are accounted for All parts of the design is carried to its completion, to the same depth level Some “Legacy Characterization” of Design Complexity Halstead metrics McCabe’s Cyclomatic Complexity metric (most broadly used) Henry-Kafura Information Flow (Fan-in/Fan-out) metrics Card and Glass design complexity metrics

Halstead Metrics (lexical complexity)

T.J. McCabe’s Cyclomatic complexity metric (control flow)

Henry-Kafura (Fan-in and Fan-out)

Card and Glass (Higher Level Complexity)

Good Design Attributes Easy to: Understand Change Reuse Test Integrate Code It is believed that we can get many of these “easy to’s” if we consider: Cohesion Coupling

where Functional is the Cohesion Cohesion of a unit, of a module, of an object, or a component addresses the attribute of “degree of relatedness” within that unit, module, object, or component. Functional Performing 1 single function where Functional is the Levels of Cohesion “highest” Sequential Communicational Higher the better Procedural Temporal Logical Coincidental Performing more than 1 unrelated functions

Using Program and Data Slices to Measure Program Cohesion Bieman and Ott introduced a measure of program cohesion using the following concepts from program and data slices

A Pseudo-Code Example of Functional Cohesion Measure

Coupling Coupling addresses the attribute of “degree of interdependence” between software units, modules or components. Content Coupling Accessing the internal data or procedural information Data coupling is coupling where Levels of lowest Common Coupling Control Coupling Lower the better Stamp Coupling Data Coupling Passing only the necessary information No Coupling Ideal, but not practical

Chidamber and Kemerer (C-K) OO Metrics

Origin of Law of Demeter A design “guideline” for OO systems that originated from the Demeter System project at: Northeastern University in the 1980’s Aspect-Oriented Programming Project Addresses the design coupling issue through placing constraints on messaging among the objects Limit the sending of messages to objects that are directly known to it

Law of Demeter An object should send messages to only the following kinds of objects: the object itself the object’s attributes (instance variables) the parameters of the methods in the object any object created by a method in the object any object returned from a call to one of the methods of the object any object in any collection that is one of the above categories

User Interface

UI Design Prototype and “Test” UI design prototypes: Low fidelity (with cardboards) High fidelity (with “story board” tools) Usability “laboratories test” and statistical analysis # of subjects who can complete the tasks within some specified time Length of time required to complete different tasks Number of times “help” functions needed Number of times “redo” used and where Number of times “short cuts” were used

MP3 Requirement/Weight Case Study 3 UML MP3 Requirement/Weight Inside Visio 2013 Page UML Distilled Page Data Flow Diagrams DFD (Context, DFD0, DFD1, DFD2) (30%) 583 None (see Video slide 27) Static structure (class) diagram (10%) 593 36 State chart diagram (10%) 598 108 Sequence diagram (10%) 595 54 Deployment diagram (10%) 601 98 Component diagram (10%) 600 140 Collaboration diagram (10%) 599 144 Activity diagram (10%) 596 118

Case Study 3 UML Diagrams Click on above image to open chapter

Case Study 3 DFD (App C, pg 312)

Case Study 3 DFD – Getting Started Database Model Diagram Visio 2010 Software Group: Dataflow Model Diagram Visio 2013

Case Study 3 DFD – Getting Started VTC https://youtu.be/scfC8abVrm0

Other UML with MS Visio 2010 & 2013 Software Group: UML Tools

Week 7 UML VTC Download/install Quicktime player

Chapter 8 Review Questions & Answers

Review Questions -- Answers 1. What are the two general characteristics of a design that naturally carry over from requirements?   Ans: The design is an evolution from requirements. So the two general characteristics are: a) consistency and b) completeness of requirements usually carry over to the design. Page: 166 2. What is the cyclomatic complexity of the design flow shown in Figure 8.4 where the diamond shapes represent decision branches and the rectangles are statements? Ans: The cyclomatic complexity using the simple formula of (# of binary branches + 1), the cyclomatic number of Figure 8.4 is (3+1) or 4. Page: 168 3. What are glue tokens and super glue tokens? Which type contributes more to cohesion and why? Ans: Glue tokens are data tokens that lie in more than one data-slice, and super glue tokens are data tokens that lie in every data-slice. The super glue tokens contribute more to cohesion because they lie in every data slice. Page: 173

Review Questions -- Answers 4. What are the levels of cohesion?   Ans: There are 7 levels of cohesion listed in the order of worst to best: coincidental, logical, temporal, procedural, communicational, sequential, and functional. Page: 172 5. What are the levels of coupling? Ans: There are 5 levels of coupling listed in the order of worst to best: content, common, control, stamp, and data. Page: 175 6. What are the six C-K metrics in OO? Ans: They are: a) weighted number of methods per class, b) depth of inheritance tree of the class, c) number of children of a class, d) coupling between objects, e) number of responses to a class message, and f) lack of cohesion among methods in a class. Page: 177

Review Questions -- Answers 7. What is a depth of inheritance tree (DIT) in C-K metrics, and why may a large DIT be bad for design?   Ans: DIT is the maximum length of inheritance from a given class to its “root” class. A large DIT would mean a long length between the root and the class. The increase in this distance increases the chance of error. Page: 178 8. In contrast to general design, what is user interface design interested in? Ans: The general software design is concerned about the software components, their characteristics and their interactions. User interface design is focused on the interaction between the software and its human users; thus both software and human attributes are of concern in user interface design (the people rather than software system). Page: 180-181 9. List four out of the eight rules of user interface design identified by Shneiderman and Plaisant. Ans: There are actually 8: a) consistency, b) provide short cuts, c) informative feedback, d) closure in dialogues, e) simple error handling and prevention, f) permit “re-do”, g) support locus of control, h) reduce the amount of short-term memory needs. Any four of the eight would be fine. Page: 181