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

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

3. Mini-Project 2
Due: 3/3/17

4. Week 7

5. Plan for March Classes

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

7. Week 7 Chap 8 Design Characteristics and Metrics

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

9. Halstead Metrics (lexical complexity)

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

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

12. Card and Glass (Higher Level Complexity)

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

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

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

16. A Pseudo-Code Example of Functional Cohesion Measure

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

18. Chidamber and Kemerer (C-K) OO Metrics

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

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

21. User Interface

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

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

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

25. Case Study 3 DFD (App C, pg 312)

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

27. Case Study 3 DFD – Getting Started VTC

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

29. Week 7 UML VTC
Download/install Quicktime player

30. Chapter 8 Review Questions & Answers

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

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

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