S1: Meeting 5
- Administrative Issues
- Note: HW2 grades today
- Statistical Summary from HW#1
- Today's Topics for Discussion + Readings
- Design: Ch. 6 (pp. 139-156) & Ch. 11 (pp. 321-362)
- 6.1-3: Module, Cohesion, Coupling
- 11.1 Architectural and Detailed Design
- 11.2 Design Techniques
- 11.8 Object Oriented Design Technique
- 11.13-15 Design Testing, CASE Tools, Metrics
- 11.16, Appendix G: MSG Case Study
- Architectural Design: Identify Components and their Arrangement
- Detailed Design: Specify how a component will work
Copyright: S. Shekhar, C. S. Dept.,
University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S2: 11.1 Design Phase
- Context : the entire life cycle (Schach, Figure 3.2)
- Percentage effort for planning phase (Schach, Figure 1.2)
- What is a "design"?
- arrangement of details which make up a work of art
- Synonyms: outline, scheme, sketch
- Subphases in Design Phase
- Architectural design
- Identify modules and their interactions
- Detailed design
- Provide particulars of each module
- Design testing
- Q? What is a module?
- Q? What is an arrangement of modules?
Copyright: S. Shekhar, C. S. Dept.,
University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S3: 6.1-3: Module, Cohesion, Coupling
- Modularity Example: Personal computers
- Opearating System produced by company A
- Micro-processors by company B, Memory by Company C
- Display by company D, Disks by company E,
- P.C. assembled by company F, ...
- Operating System producer seldom need to talk to Display or Memory manufacturer
- What is a module?
- "a sequence of program statements,
- bounded by boundary elements,
- having an aggregate identifier" -- (p. 141)
- Q? Are the following modules? If so, identify boundaries.
- C++ class definition
- C include files
Copyright: S. Shekhar, C. S. Dept.,
University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S4: 6.1-3: Module, Cohesion, Coupling
- Module boundaries helps in
- Dividing work at the level of modules
- Contain side-effect of code changes within modules
- Allows data abstraction for reuse, ...
- Metrics of Architectural Design: Modularize system for
- Low coupling across modules
- High cohesion within each module
- Coupling = how modules interact
- e.g. Y2K problem, dependency on software
- High coupling = > weak module boundaries
- Low coupling = > strong module boundaries
- Cohesion : how well contents of a module belong together ?
- Ex. Core competency in organizations
- Coca Cola (soft drinks) vs. Pepsi (soft drinks, restaurants, ...)
- AT&T (1995) vs. {AT&T(1998), Lucent, NCR}
Copyright: S. Shekhar, C. S. Dept.,
University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S5: 6.1-3: Module, Cohesion, Coupling
- Classification of Coupling between modules M1 and M2
- Content coupling : M1 uses internal of M2
- Common coupling : M1 and M2 shared global variables
- Control coupling: M1 tells M2 what to do via a control parameter
- hard to understand from static code
- exception handlers in C/C++
- Stamp coupling : M1 uses only part of data sent by M2
- harder to understand, risk of accidentally data corruption
- Data coupling : M1 gets only that data from M2, that M1 uses
- Considered the best kind of coupling
Copyright: S. Shekhar, C. S. Dept.,
University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S6: 6.1-3: Module, Cohesion, Coupling
- Classifying kinds of cohesion : ranked from worst to best kind (?)
- Coincidental cohesion: Unrelated componentss bundled together
- Logical cohesion : do one of multiple related things (e.g. menus)
- Ex. Unix/DOS shell commands, I/O (see Fig. 6.5, pp. 146)
- Confusing interface if variable number of parameters
- Danger of interwined code across functions
- Temporal cohesion: series of actions related in time
- Ex. see pp. 145, sec. 6.2.3 para 1 OR Ex. 8.2 (pp. 262)
- Danger of high coupling with other modules
- Procedural cohesion : set of actions related to a process
- Ex.: MSG DFD (Fig. 8.27) as a single module
- Danger of high coupling with other modules
- Communicational cohesion: set of actions for common data
- Ex. update record in database, write it to audit trail
- Danger of high coupling with other modules
- Informational cohesion: collection of actions on a data type
- Ex. constructor, count-up, destructor
- Functional cohesion : does exactly one thing
- Ex. sort, spelling-checker, slide-maker
Copyright: S. Shekhar, C. S. Dept.,
University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S7: Exercise on Cohesion
- Q. Identify the type of cohesiveness in following groups:
- 1.Sort keyword list, Check current date, intialize constraints
- 2. Delete scratch files, close master file, close report file
- 3. read string, convert to upper case, search list for it
- 4. Display string, add string to keyword list, find length of string
- 5. Open keyword file, build keyword list, close keyword file
- Q. Specify the level of cohesion each of the following
1.void foip() {
int i;
for(i=0; i < =N; i++)
list_item[i]=upcase(list_item[i]);
master_file = fopen("MASTER.DAT","r");
oz = 79; satchel = 42;
printf("seconds since 1/1/70 is %ld\n", time(NULL));
}
Copyright: S. Shekhar, C. S. Dept.,
University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S8: Exercise on Cohesion
2.int bl(string s_key[]) {
int i;
for(i=0; i < =MASTER_ITEMS; i++)
fscanf(master_file, "%s", data_list[i]);
for(i=0; i < =N; i++)
list_item[i] = upcase(list_item[i]);
for(i=0; i < =N; i++)
if(strcmp(list_item[i],s_key)==0)
return(1);
return(0);
}
3.int hns(char the_string[]) {
int i;
strcpy(string_list[NEXT_ITEM++], the_string);
fprintf(string_file,"%s\n", the_string);
i = length(the_string);
return(i);
}
4.void bl() {
int i;
master_file = fopen("MASTER.DAT", "r");
for(i=0; i < =MASTER_ITEMS; i++)
fscanf(master_file, %s", data_list[i]);
fclose(master_file);
}
Copyright: S. Shekhar, C. S. Dept.,
University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S9: 11.3-4 Design Techniques: Classification
- Two basic aspects of software: Actions and data
- Corresponding design approaches:
- Action-oriented, data-oriented, and evenly balanced
- Action Oriented Design Methods
- Ex. Data Flow Diagram -- > Structure Chart (Call graph)
- Q? Which module is the root? (Fig. 11.3, 11.4, pp. 324)
- Focus: what the system does (processes are refined)
- Data Oriented Design Methods
- Ex. Information Engineering, Jackson (JSP)
- Focus: the data semantics (Leave for Csci 5702)
- t Oriented Method
- Balances data and process
- Look more at object oriented design (OOD)
Copyright: S. Shekhar, C. S. Dept.,
University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S10: 11.8 Object Oriented Design Technique
- Three Steps: (i) Identify methods in classes, (ii)C lient diagram
- and (iii) Detailed design
- Step 1: Identify the methods (actions) in the classes
- Ex. Fig. 11.25 (pp. 348) for class diagram in FIg. 9.7 (pp. 280)
- Q? Should data be all private ?
- Q? Inheritance: Should a method operate on inherited data?
- Q? Elevate common methods across derived classes to base class?
- Step 2: client analysis: USE relationship among classes
- M1 USES M2 iff correctness(M1) dependes on correctness(M2)
- e.g. Print-managers USE printer-device-drivers, but
- e.g. Print-managers may CALL print-error-message, but not USE it
- Q? What are the nodes in client diagram: classes or functions?
- See Fig. 11.26 (pp. 349) and Fig. 11.29 (pp. 360)
- Step 3: Do the detailed design (e.g. step wise refinement)
- Method signatures (parameters, types, etc.)
- Method description: psuedo-code (Fig. 11.27, pp350)
Copyright: S. Shekhar, C. S. Dept.,
University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S11: 11.8 Object Oriented Design : Coupling and Cohesion
- OOD does not gurantee high cohesion and low coupling
- Coupling issues specific OOD
- Coupling via Implementation inheritance
- C++: coupling via friend-of functions, public data members
- trade off coupling against programming convenience
- Trend: Interface inheritance, Binary reuse
- = > Component technology (Java Beans, MS COM)
- Cohesion issues for OOD
- Schach argues that inheritance does not affect cohesion
- Depends on designer
Copyright: S. Shekhar, C. S. Dept.,
University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S12: 11.13-15 Design Testing, CASE Tools, Metrics
- Testing
- Check if design meets requirement specification
- Correctness
- CASE Tools
- Drawing, Data Dictionary
- consistency checks (e.g. class diagram vs. client relationships)
- Screen, Report Generators
- Metrics
- coupling, cohesion, fault statistics
- complexity : cyclomatic , length*sqr(fan-in * fan-out),
- number of ancestors of a class, etc.
Copyright: S. Shekhar, C. S. Dept.,
University of Minnesota, Minneapolis, MN 55455. ,,.(home)
S13: 11.16, Appendix G: MSG Case Study
- Step 1: Class Methods (Fig. 11.28, pp. 359)
- Why does base class have no data member? e.g. name
- Redundant methods?: put, get, vs. read, write
- Should there be another class called list-of-inestments?
- List the class-methods & instance methods of each class.
- Step 2: Client Diagram (Fig. 11.29, pp. 360)
- Compare with Dynamic& Functional models (Fig. 9.11, 9.12)
- Compare with class methods (Fig. 11.28)
- Q. Identify add, modify, delete (mortgage) in client diagram.
- Step 3: Detail design (Fig. 11.30 & Appendix G)
- Compare with class methods (Fig. 11.28)
- Objects vs. Files: Are investments file ?
- Q? Why does delete_record accessed no files? (Fig. 11.30)
- Q. Draw a call graph of all methods. Compare it with client diagram.
Copyright: S. Shekhar, C. S. Dept.,
University of Minnesota, Minneapolis, MN 55455. ,,.(home)