S1: Meeting 5
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
    • Ranked worst to best
  • Content coupling : M1 uses internal of M2
  • Common coupling : M1 and M2 shared global variables
    • side-effect problem
  • 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)