COS520: Software Engineering I
Fall 2007 Daily Progress and Assignments

Main topics that where discussed are as follows:

• The Course is split into the following topics:
1. Part I: Introduction: We will be covering the development process through two case studies, and Two introduction papers, as well as in the course text.
   • "Time, Clocks, and the Ordering of Events in a Distribted System" (Lamport, Leslie)
   • "On the Criteria to be Used in Decomposing Systems into Modules" (Parans, David)
   • "How to read an egineering paper" (Griswold, Bill) This is an introduction paper on reading other papers
   • "Programming-in-the-large Versus Programming-in-the-small" (DeRemer, F and H.H. Kron)
   • "Cultures of Prototyping" (Schrage, Michael; Winograd Text [course text])
2. Part II: The Software Design Process and Documentation Support: This will be covered in 5 papers plus the Course Text
   • "A Software Design Manifesto" (Kapor, Mitchell; Winograd Text)
   • "Design of the Conceptual Model" (Liddle, David, Winograd Text)
   • "Managing the Development of large software systems: concepts and techniques" (Royce, W. W.)
   • "A Spiral Model of Software Development and Enhancement" (Boehm, Barry)
   • "A Rational Design Process: How and Why to Fake it" (Parnas, David and Clements, Paul C.)
   • "Embracing Change with Extreme Programming" (Beck, K)
   • "How Microsoft Builds Software" (Cusumano, Michael and Richard Selby)
   • "Using Documentation as a Software Design Medium" (Hester, S.D., Parnas, D.L., Utter, D.F.)
   • "Design Languages" (Rheinfrank, John and Evenson, Shelley; Winograd Text)
   • "Action-Centered Design" (Denning, Peter, and Durgan, Pamela; Winograd Text)
3. Part III: Software Architectures: This section will be handled through 2 case studies, 5 papers, and the course text.
   • "The Implementation of Reliable Distributed Mulitprocess Systems" (Lamport, Leslie)
   • "The Byzantine Generals Problem" (Lamport, Leslie)
   • "Comparing Architectural Design Styles" (Shaw, Mary)
   • "Design patterns: Abstraction and reuse of object-oriented design" (Gamma, E., et. al)
   • "Architectural Mismatch: Why Reuse Is So Hard" (Garlen, David, Allen, Robert, Ockerbloom, John)
   • "Aspect-oriented Programming" (Kiczales, G., J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, et. al.)
   • "The 4+1 View Model of Architecture" (Kruchten, Phillippe P.)
   • "Foundations for the Study of Software Architecture" (Perry, Dewayne, E)
   • "Keeping it Simple" (Brown, John Seely and Duguid, Paul; Winograd Text)
4. Part IV: Formal Specifications and Verification: This section is handled in Three papers, plus the course text.
   • "Larch: Lanuages and Tools for Formal Specification (Texts ad Monographs in Computer Science)"(Guttag, John V, et. al)
   • "Specification Case Studies" (Hayes, Ian, et al.)
   • "On the INevitable Intertwining of Specification and Implementation" (Swartout, William, Balzer, Robert)
   • "Footholds for Design" (Gal, Shahaf; Winograd Text)
5. Part V: Formal Testing: This will covered by one paper and the course text.
   • "Toward a Theory of Test Data Selection" (Goodenough, J. B., and Gerhardt, S.L.)
   • "Design as Practiced" (Norman, Donald; Winograd Text)
• Course Grades:
  • Take-Home Prelim 1: 15 Points
  • Take-Home Final: 15 Points
  • Class Participation: 10 Points
  • Projects: 40 Points
    • 2 Individual Projects (see sylabus)
    • 1 gourp Project (see sylabus)
• Journal Must be Kept
  • For Readings:
    • Bibliography (standard and Annotated)
    • 1 Page description of how the paper fits in with class
  • For Topics:
    • 2 page essay describing how readings fit together (more info on sylabus)
  • For Course:
    • 2 page essay on how all readings fit together and the main points from class.
• Final Class Team Project Objectives:
  • Working System
  • Documentaion
  • Poster

Looking Forward:

• Start Reading the Clocks Paper, and read the How to read a paper paper.

Main topics that where discussed are as follows:

• The Partial Order definition given in the paper -- The relation "→" on the set of events of a system is the smallest relation satisfying the following three conditions:
  1. If a and b are events in the same process, and a comes before b, then a→b.
  2. If a is the sending of a message by one process and b is the receipt of the same message by another process, then a→b.
  3. If a→b and b→c then a→c (Transitivity). Two distinct events a and b are said to be concurrent if ¬ (a→b) and ¬ (b→a).
• Concurrency described in the following three ways:
  1. Occurs when two or more events take place during the same time in multiple processes.
  2. Formal definition given in the paper, the last part of the partial ordering definition.
  3. The following diagram that visually depicts concurrency. In the diagram we have: time moving forward from the bottom to the top, two process, P₁ and P₂ drawn as vertical lines, and clock ticks shown partitioned by wavy lines.
• The "Happened before" relation, which is defined using the partial ordering definition from above. Notice that restricting concurrent events as defined above results in extending the typical notion of a partial ordering so that the notion of "happened before" is an irreflexive partial ordering.

Looking Forward

• Look closely at the specification of logical clocks in the paper.
• Additionally, when looking at the logical specification of clocks, look for reasoning about its correctness.

Main topics that where discussed are as follows:

• Conditions to be satisfied for Implementation:
  1. Any Process That has been granted a resource must release it before it can be granted to another process.
  2. Different requests for a resource must be granted in the order in which they are recieved (Logical Order).
  3. If Every Process that has been granted a resource eventually releases it, every request is eventualy granted.
• Implementaion Details
  1. P_i sends resource request to ALL processes, and puts its request on the request queue (timestamped T_m:P_i).
     
     
  2. P_j receives T_m:P_i request for resource, and places ther request (in time-stamp order) on its request queue. Acknowledgement is sent to P_i.
     
     
  3. P_i sends (T_m:P_i) release resource messege to every other process and removes it from its own (P_i) request queue.
     
     
  4. P_j recieves T_m:P_i release resource message and removes the related resource request from its request queue. (should be at the front of the queue)
     
     
  5. Process P_i is granted the resource when the following conditions are TRUE:
     
     1. There is a T_m:P_i in its request queue which is before any other according to "⇒"
     2. P_i has recieved a message from every other process, and all other processes time stamps are > T_m
        
        
• Looking at these requirements, we make the following connections:
  • Implimentation Detail (ID) 1 and 2 satisfy Implimentation Condition (IC) 2.
  • ID 3 and 4 satisfy IC 1
  • ID 5 handles actually taking control of a resource, and combined with all other IDs, we satisfy IC 3.

Looking Forward

• Start reading Parallel paper.
• Implement this algorithm as a group (applet?). UPDATE: (Due 27 Sep 2007)

Discussed the paper On the Criteria To Be Used in Decomposing Systems into Modules by D.L. Parnas

• Modularization of KWIK index
  1. Module:
     int CHAR(int line, int word, int character);
int SETCHAR(int line, int word, int character, int data_character);
void DELINE(int line, int word);
  2. Module:
     Reads original lines and call Module 1 to store them.
  3. Module: Circular Shifter
     Same set of methods as Module 1, but for all of the circular shifts of lines.
     CSSETUP, must be called first.
  4. Module: Alphabetizer
     ALPH, prepares
     int ITH(int index) // index of the circular index which comes ith in alphabetical order
  5. Module: Output
     The desired printing of set of lines or circular shifts.
  6. Module: Master Control
     Coordinates the sequence of calls.
• A diagram showing one representation of the KWIK index modularization is shown below.
• Questions discussed
  • Why are we implementing the clocks?
  • How can we visualize the difference between modularization 1 & 2?
  • Given a layer, what is the abstraction that it gives the layer above? What about the layer below?

Looking Forward

• Implement the KWIK index modularization:
  1. storage
  2. circular shifting
  3. alphabetizing
• Start looking at case study 3 - Multi process paper
• Demo the clocks program next Thursday. Think about the processes as state machines.

Main topics that where discussed are as follows:

• Global Knowledge:
• The system as a whole has a global knowledge (or consciousness)
• The "Amoeba" of the system cannot blindly change state -- knowledge must be transferred.
  • Changes that do not foward knowledge can destroy the system.
• When the "Amoeba" changes shape, it must "stretch" to encompass the new, and transfer its data before disconnecting old.
• (graphic here)
  
  
• Majority Graphs
  • For this type of system to work, the idea of a "Majority Graph" must be maintained.
    • Ex: If a network consists of 5 interconnected nodes, the majority graph would have to consist of at minimum 3 interconnected nodes.
  • (graphic here)
    
    
• Reliable Parallel Systems (part I)
  • Goals:
    • To enable the system to continue functioning despite the failure of one or more processes or communications lines
    • To enable the system to continue functioning despite the malfunctioning of one or more processes or communications lines
      
      
  • Definitions:
    • Failure: Process or Communcation line stops working completely (removed from system)
    • Malfunction: Process or Communication line provides inaccurate or inconsistant data.
      
      
  • Difficulties:
    • Continue work with enough (info/processes)
      • Also need to know what a majority consist of.
    • Consistent information - how do we handle it?? (not for this paper...)
      • Byzantine General's Problem
        
        
  • Questions on paper:
    • What happens with a double point failure that separates a network into two??
      • Case 1: If no majority graph exists, requests will be queued until such time as a majority is present
      • Case 2: If one section is a majority graph, and the other is not, majority graph will continue to handle requests.
        Non-majority Graph will queue requests until such time as it can contact majority
        
        
        
      
      
      

    Does Ameba collapse instantly on two node failure.

    Yes, we think so. We only have to assure a majority graph still exists to remain functioning.
    
    

    Are users an alternate path for data-flow

    We are as yet undecided, leaning towards no.
    
    

    Who's perspective is a failure from?
    
    

    Does the system (in this paper) assume the recieved message is the same as the message sent?

    yes
    
    

    It is important to note that decisions are only made within the "Amoeba" area.

.

Looking Forward

• Get together and decide on plan for next class. Read the parallel paper carefully.
• Time Clocks Applet will be demonstarted in the next class.
• Think about implementation of the reliable parallel system utilizing 5 + nodes.
• Look at proof with a fine tooth comb. Work through it very carefully.