COS520: Software Engineering I
Fall 2002 Daily Progress and Assignments

Monday, September 6, 2002

• These online diary entries will be written by two people a day, making sure that the work is distributed fairly.

 

 
 
 
 
 
 
 

Today we discussed the Leslie Lamport paper on the order of events in a distributed system.  We tried to figure out why Lamport wrote the paper and we came up with a few ideas:
- The ideas/mathematics in the paper will be true for any distributed system in which messages take time to deliver.
- There are problems with using physical clocks and time stamps for ordering and synchronizing events in a physical system.
- Lamport identified these problems and wrote this paper to fill in the gap, that in hindsight, should have been very obvious.

As a group we will need to work more at explaining the importance or practical meaning of papers/ideas instead of focusing on their literal meanings and algorithmic definitions.

We divided the class into three groups to discuss (1) what partial ordering is in this system, (2) what is the clock condition,  and (3) an implementation that meets the requirements of the  clock condition.  This class exercise maps directly with three main steps in Software Engineering (1) Idea/Requirements, (2) Specification,  and (3) Implementation.  We will be following these steps throughout the class.

During group one's presentation we found a direct isomorphism between the partial order of events defined in the paper and partially ordered graphs
and plans.  Determining that the system is a partial order is important because we can impose the properties of partial orders on the system instead of re-deriving them.  A mathematician who doesn't care about computer science and a computer scientist who doesn't know any math equally do not have the tools necessary to identify and fully understand the properties of the system and to appreciate the solution.

Implementation Notes:
- The implementation can be written in any language, but its interface must be dynamic.  The interface must allow the user to see what's going on with each process and to change various properties to see how they affect the system.
- It is important to study the algorithm very carefully because their are a lot of subtle items.

Assignments:
- What is the mathematics in Leslie Lamport's paper?
- What is the definition of a Partial Order?

--Erik Albert
 

• Today we had a class discussion on the Leslie Lamport paper "Time, Clocks, and the Ordering of Events in a Distributed System".

 

 
 
 
 
 

First we discussed "Why did Leslie Lamport write this paper?"

Three groups were assigned sections of the paper to discuss and present to the rest of the class.  Group 1 discussed the section on partial ordering, group 2 discussed the clock conditions, and group 3 discussed the implementation rules.

Group 1 was the only group that got a chance to present, and they discussed the properties of the "happened before"  relationship, and gave examples of various relationships between events in figure 1 of the paper.
 

Assignments:
- What were the mathematics in this paper?
- Carefully read the section on totally ordering.

-- Glen Beane
 

Monday September 9, 2002

• The class started by the following question asked by Professor Latour:

ë Where does the "happened before" relation fit in the world of computer science?í

Discussion:
Class started by discussing the difference between Specification and Requirements of a system. It was concluded that specification is a confirmation of the requirements that are created by the user and the system analysis. More on the subject of the specification and requirements of a system will be discussed in later chapters. Think about some situation where the implementation of a system satisfies invalid specifications because it does not meet the requirements.

Later, the class will discuss how the "happened after" relation fit in the system and requirements of the system.
 

Now back to the presentations that are continued from the last class.
- clock condition subject was presented (from Lamportís paper)
1. logical clocks were used instead of physical clocks. Reason: physical clocks have problems. That was not a sufficient answer. So the class was asked to go back to the paper and find the definition of physical clocks and logical clocks and the differences between them.
2. If   a->b then  C<a>  is less than  C<b>, where C<x> is the time stamp for event x.
3. Correct clocks where discussed. The conditions for correct clocks are found in the paper on page 560, col 1.
4. Note that Ci<a> is a set of clock functions C1<a>, C2<a>, C3<a> Öetc. (definition could be found on page 559, col 2)
5. A clock is correct if it lines up with events.
6. Question to think about: can you have two events occurring on the same time? This is discussed later in the paper.

- How does the implementation satisfy the clock condition?

1. Time stamp is introduced and kept track of.
2. discussed IR1 and IR2 on page  560, col 2.
3. processes always go forward in time.
4. IR2 will be put on the board again and discussed in more details.

-- Kamal Shannak
 

• In this (class) we discussed:

 

 
 
 
 
 

(1) "Happened before" relation, which is also a partial ordering relation and an error relation. And what does "happened before" relation fit in this case?
(2) Whatís the difference between requirement and specification? And how is validation issue involved with these 2 phases? And we also discussed the 2 way communication between these 2 phases.
(3) The differences between of "physical clock" and "logical clock".
(4) Why did he choose the worlds "physical" and "logical"? And whatís the purpose? (To be answered)
(5) Whether is the function C a unique function or not?
(6) How did he introduce the "correct clock"?  Why didnít he just define "correct clock" from the beginning?
(7) Clock definition.
(8) Whatís the difference between specification and implementation? In this case, specification is basically to answer what do we want do? We want the clock "correct". And implementation is how you can make it.
(9) Another interesting question is whether itís possible that 2 events can occur at the "same" time?
(10) We then quickly went through implementation part. Itís observed that some sort of unfairness may rise if clocks go at different speeds.
(11) In IR1, how much does process Pi increment? Whatís the definition of "message" and "process" in this case? (To be answered)
(12) Is it possible that Pi=Pj? (To be answered)

Assignment: prepare for the discussion of algorithm involved.

-- Haidong Bao

Wednesday, September 11 2002

• We continued working on Lamport's paper.

 

 
 
 
 
 

First, we finished discussing IR2 condition.
During the discussion, we were asked to think on question:
-- What is formal about IR2 rule and why it is important for the rule to be formal?
IR2 rule is formulated using math notations (event a, process Pi, timestamp Tm=Ci(a) ). Formality of IR2 gives specificity, precision, simplifies its formulation and makes the algorithm less ambiguous.  In answering the question, we recalled that mathematics in general is a communication tool that facilitates knowledge sharing by using formal (universally accepted) rules.

Then the class was divided into three groups to discuss the following topics:
(1) total order, derived from  "happened before" relation.(the definition, how it works, why it is important, etc.);
(2) the requirements/specification of the algorithm; and
(3) the implementation of the algorithm.

Topic 1: total order,
During discussion of the  (total order) relation, we clarified that the ordering of concurrent events is somewhat arbitrary because it is based on the processes' local logical clocks' values (local clocks might not be synchronized, might have different speeds and granulation units).  To solve this problem, the second part of Lamport's paper considers physical clocks. During discussion, we were asked to think about the following questions:
1. If two concurrent events X and Y are ordered as X  (total order) Y according to the system's logical clock, what can we say about their order in real life?  The ordering of concurrent events based on some arbitrary assumption (ordering of processes) may be different from the real ordering of events.
2. What is the possible use of partial ordering?
3. Does it make sense in real systems to decide up front how to order processes?

We stopped on discussing Topic 2.

-- Aitbala Sargent
 

• Actually we grouped into baches of 3 and took the following  parts each:

1.Total ordering.
2.Describing the requirements of the system .
3.Explain the Algorithm.

We completed  the first  part.We discussed about the total ordering of events and arbitrary total ordering . We discussed the requirements of the system. What are the conditions to be satisfied inoder to grant a resource to a process? We developed a rough idea of the 2nd part. We will discuss the 2nd and 3rd parts  in detail in friday's  class.

-- Neelima Guduru

Friday, September 13, 2002

• We discussed Lamportís mutual exclusion algorithm in more detail, as well as the function of a prototype. The discussion regarding the difference between specifications and requirements was revisited when we decided that a prototype helps to verify the specifications to the requirements. We determined the point of the algorithm to be the following:

- Mutual exclusion in a distributed system, where everyone sees the same ordering.

Some of the terms Lamport used to describe the algorithm were vague at best, which brings up some questions:
- What does Lamport mean when he says that if every process granted a resource eventually releases it, then every request is eventually granted?
- What does eventually mean? How long can it be?
- How do you determine fairness in a mutual exclusion algorithm?
- What does it mean for an algorithm to be fair?

Another question arose when discussing the rules of the system.
- Can you release a resource after requesting it, but before receiving it?
This was discussed, but we didnít come up with a firm decision regarding the issue. There is little evidence in the paper to suggest that it is not possible. As long as the process removes the resource request from itsí request queue, and notifies all the other processes to do the same, the resource should be released before the requesting process ever actually receives it.

Assignments:
For Wednesday:
- Journal entry for the timeclocks paper.
- What does it mean to prove an algorithm matches spec?
- Did Lamport prove that his algorithm matched spec?
- What is a queue?
- Why did Lamport call his data structure a queue?
- Read D.L Parnasí On the Criteria To Be Used in Decomposing Systems Into Modules

For Friday:
- Present one implementation of Lamportís mutual exclusion algorithm.

-- Aaron Strange
 
 

• First, we reviewed the requirement about this implementation algorithm  which need to satisfy three conditions. We focused on:

(1) how to solve synchronization problem: since only one process can use the resource at one time
(2) total ordering of events in the system
(3) every process has chance to be granted the resource

Second, we worked on the implementation algorithm, focused on the fact  that each process is keeping a local view (the request queue) of the shared common knowledge of the total ordering =>.

We noticed that a process can only be granted the resource when there is no  earlier resource request from the other process exists.

Assignment:

-What does the "eventually" mean in a distributed system?
-What is the purpose of this paper?
-What is the defination of a queue? Why Lamport call his data structure a request queue?
-What does it mean to prove a algorithm match the specification? And tell whether the algorithm is proven in this paper.
-The journal regrading Lamport's paper will be due on Wednesday.
-We will present our implementation of a prototype system on Friday.

-- Jiang Ma
 

• 9:00-9:23  No class next Monday; Journal entry due next Wen. ; Prototype project (clock) due next Fri.

9:23-9:27 review the requirement for clock
9:27-9:41 How to implement the clock
9:41-9:50 Def. of "Eventually" and "Fireness" and how would these two words are implemented in our projects?

We worked on the implementation of the mutual exclusion algorithm (messages passing), focusing on the fact that each process was developing a local view of the shared common knowledge of the total ordering .
- Assume the clock is correct;
- a process cant hold two or more resources at the same time, but it is ok that no processes have any resources;
- a resource can be granted to a process when there is no earlier request; The resource is granted by sending out ACK messages to all other resources.
- mutual exclusion

-- Wang Jia

Friday, September 20, 2002

• Today, we have the first project demonstration in CS computer room. We have 4 groups and every group implemented the Algorithm in the article of "Time, Clocks, and the Ordering of Events in a Distributed System" differently.

 

 
 
 

There are three groups using VB since VB has an advantage to demonstrate prototypes, esp. for visual interface. One group used VC to inplement their project.

Professor Latour asked some questions during the demonstration. One of the question is if we considered the problem of "communication delay".  Almost all the groups did not address this problem deeply.  In fact, in the beginning of the implementation, I considered the situation of communication delay, which is happened in real network communications.  However, after reading the Algorithm carefully, I noticed that there is an assumption in the Algorithm of this article, (please refer P561 for granting the resource condition II which is "different request for the resource must be granted in the order in which they are made".  Based on the assumption, our group decided not to include the communication delay issue into out implementation. I agree with  Professor Latour that we don't care about the physical requesting order, we here only need to focus on the logical ordering.  If the assumption I mentioned above can be explained by this meaning, it is easy to include the communication delay into our implementation.

It is impressive that each group has its own strength. Some put their emphasis on visual communication part; Others focused on the common knowledge shared by each process and their message passing. As far as I am concerned, this prototype demonstration should emphasze the following aspects:

1) Total ordering of processes (using logical clock, adjust time stamp, change individual clock for process)

2) Common knowledge of request queue shared by each process (no central synchronizing process, no central storage)

3) Resouce granting and release

4) communication delay

Our group implemented 1),2),3) successfully except 4). And we have added the delay part into our implementation.

I think it is a good experience for all of us to rethink how a prototype can demonstrate a system requirement.

-- Jiang Ma

Monday, September 23, 2002

• Before we began Parnasí paper, we overviewed some topics discussed last Friday. Since we have implemented prototype based on Lamportís paper, we found some interesting topics about prototype and specification. Then we examined the role of formal specification. There are at least 4 advantages:1 to help build system.2 to communicate precisely, preventing ambiguity.3 to clear up any misunderstanding.4 to help reasoning the system. And it also led to the question that whatís the meaning of reasoning the system. Basically itís what we expect the behavior of the system under either normal or critical situation (in this case, such as message propagation delay problem and so forth). And again we discussed the advantage about mathematic model. The mathematic model can help proving theorems about the system and also associate similar system to solve the problem. If a formal specification of the system is similar to an existing system, we may use the theory to prove our specification and also predicate the behavior of the system we will build. We also discussed the role of prototype. A prototype can help reasoning the system, proving theorem. It also can help user to verify the requirement and clear up any misunderstanding either between front end user and system analyst, or between system analysts.

 

 
 
 
 
 

We then discussed the Parnasís paper. There are 2 groups in the discussion, one for defending modularization 1, one for modularization 2. According to the group one, the advantages of modularization 1 are: easy straightforward; more efficient; less work. According to the group two, the advantages of modularization 2 are: easy to change; easier to build individual module; easy to debug.
Homework: whatís the difference between modular programming and object-oriented programming?

-- Haidong Bao
 

• Today we discussed about the topic "On the Criteria To be Used in Decomposing Systems into Modules" Half of the class suported the Modularization one and another half ,modularization two. We are going to continue it on Wednesday

 

 
 
 

We have talked a little about :

- how we reason the system.

- Using Mathematics we can define a system and how we will build the system using the axioms and the theorems

- How we build a system using formal specifications?

-- Neelima Guduru

Wednesday, September 25, 2002

• We discussed D.L. Parnasí paper in more detail and broke into 3 groups to discuss the parts of modularization 2 in more detail. We determined that modularization around data breaks up the functionality of the program into the different modules, whereas modularizing around functionality causes the data to be broken up. We determined the following about the three parts of the second modularization in our discussion:

 

 
 
 

Line Storage:
- Abstraction ? a list of all the lines
- Since the usage pattern is not stated, we do not know if it fills up randomly or sequentially
- The line storage could be implemented as an array, linked list, or even externally using paging schemes
Circular Shifter:
- Abstraction ? an index containing all of the circular shifts
- It hides the mapping from CSCHAR() to CHAR()
- Could be implemented as a mapping function, table, or even the full data set
Alphabetizer:
- Abstraction ? A list of all the circular shifts in alphabetical order
- The ALPH function could be implemented as empty if the list was searched for each call of ITH

Some observations that were made are that the circular shifter and the line storage are very similar, and that the alphabetizer works with the circular shifter in the same way a database works with data.

One question that arose from the discussion is:
- Why would you want to use a full data set representation for the circular shifter?

Some examples were thought of, but a clear consensus wasnít reached on the answer to this question.

Assignments:
For Friday:
- Read Hester paper Using Documentation as a Software Design Medium
- Suggest 2 applications of a circular shift module that lead to different implementations
- Consider 2 applications of a line storage module that lead to different implementations

-- Aaron Strange

Monday, September 30, 2002

• We watched Gregor Kiczales' video "Why Black Boxes are so Hard to Reuse: A New Approach to Abstraction for the Engineering of Software".  Below are some ideas of the video lecture.

 

 
 
 

Black-Box Abstraction.  Kiczales has first discussed the traditional principle of software design, known as black-box abstraction. Black-box abstraction exposes only functionality of a module and hides implementation details.  Although such design helps to manage the complexity of a problem, it can lead to performance difficulties.  The reason is that not all the aspects hidden behind the interface are implementation details, some of them are mapping dilemmas (strategy questions affecting performance differentially for different applications) and mapping decisions. The mapping conflicts (implementation of the module that does not suit the application) become more critical when the module is used in multiple contexts (module reusability).  Traditional ways to solve the conflicts is duplicating functionality already provided (hematomas of duplication) or coding to fit the specific context of desired mapping decisions (coding between the lines).

Conclusion:  the best implementation strategy for a module can't be determined unless the implementor knows how the module will be used.  In other words, module implementation must be somehow be opened up to allow the client some control over mapping decisions.

Separation of Control.  One way to solve the problem is to use the open implementation design based on object oriented technique.  The design separates the primary base interface, which provides the module functionality, and the secondary meta-interface, which can be used to alternate some implementation decisions that underlie the primary interface.  The long-term goal is to provide base/meta abstract descriptions that allow the user to make proper decisions without digging into the implementation.

-- Aitbala Sargent
 

• We continued discussion today on Parnas's modularization paper.

 

 
 
 

- Modularization around data splits up functionality.
- Modularization around functionality splits up the data.

In general, the separation of concerns modularizes around one or more aspects and cause the others to be divided.  Real time programmers, for example, modularize around time and thus both functionality and data are divided.  There are different concerns in different types of systems.

We divided into three groups, each had a specific module (from modularization 2)  to study:

A. Line Storage
B. Circular Shifter
C. Alphabetizer

We then had to:

1. Present the abstraction (and interface).
2. Discuss what is hidden by the abstraction.

A. Line Storage.  The abstraction is a set of line holders, each addressable by line number, word number, and character number.  The implementation is hidden by the abstraction; it could be a large array, a linked list, or even some sort of paging system.

B. Circular Shifter.  The circular shifter has the same abstraction as the line storage module.  Again it is a set of line holders.  The abstraction hides the actual implementation, which can be an actual data type that hold all circular shifts, or it could be a mapping scheme from CSCHAR(l,w,c) -> CHAR(r,w,c).

C. Alphabetizer.  The abstraction is a set of lines ordered by alpha.  The implementation that is hidden by the abstraction is whether or not the data is copied, or there is a mapping going on, or even a scheme of dynamic programming.

HOMEWORK:

1.  Suggest two different usage patterns of the ALPH module that would lead you to two different implementations.

2.  Consider two applications of the line storage module (module 1) that will lead to two different implementations.

-- Erik Albert
 

• Today we watched the Video tape

 

 
 
 

           SELECTIONS  FROM  OOPSLA 1994
WHY BLACK BOXES ARE SO HARD TO REUSE :

A NEW APPROACH TO ABSTRACTION FOR THE ENGINEERING OF SOFTWARE
                                        Gregor  Kicgales
                     Xerox Palo Alto Research Center.

SUMMARY :
Fundamental chalenges of engineers : must master complexity.
Abstraction and decomposition are primary tools for doing so.

We use Black Box abstraction -->  mapping decisions showing through -->  Hematomas ,Coding betwen lines  -->  clients need control on mapping decisions  --> some other approaches...

Giving clients control  means :
- separatiom  of control
- scope control
- incrementality
- reliability

Kiczales  took the page replacement  example and some more to explain this...

He discussed about the Reflexive module .
 In this the interface is divided into 2 :
1. Base Interface.
2. Meta interface.

Basic Design goal  :     'hiding implementation "  is replaced by " separating control over mapping decisions"

He concluded his talk by giving the  other issues they are going to deal with.

-- Neelima Guduru

Wednesday, October 2, 2002

• Today we went over the videotape "Why Black Boxes are so Hard to Reuse: A New Approach to Abstraction for the Engineering of Software" by Gregor Kiczales. The key point in the video is base/meta separation and binding time. An interesting topic is aroused that what the role of template? Whatís the role between data type and container for example database object and vector? And whatís the function is the most basic or necessary? To me I was confused because that something we assume it should be. For a template like list, the basic functionality is to store and retrieve data. And how data stored and retrieved may affect the performance of a system. Later on we discussed the relationship between template and parameterized types. And it also reminded me the issue of template specialization, which is that when a template for a special type does not meet my requirements or is not ease to use , we can give the a special implementation for this type. I am not quite sure to what level that mapping decision is involved in this case or none at all. Dr Latour also gave an example of an implementation of stack on top of list. I guess he tried to illustrate the relationship between base interface and meta interface. He also talked about page and virtual memory mechanism. According to Kiczales, although black box abstraction of virtual memory is simple and intuitive, it hides lots of mapping dilemma, for example, LRU and MRU. Homework: pick up a system and examine the meta/base separation and decision; to what extend that programming language affect the way you think about meta/base separation; compare Parnasí idea and Kiczalesís.

 

 
 
 

-- Haidong Bao

Friday, October 4, 2002

• Today we started discussing the Hester/Parnas paper.  We broke into 3 groups and discussed (1) what is the dilemma, (2) the key design principles, and (3) the applications of concerns to the design process.

 

 
 
 

(1) What is the Dilemma?

 (i) no design before coding
 (ii) do not use documentation made in the design phase
  (a) there's a need to design first and use the documentation while coding.

 (iii) We then discussed how design is typically used in class projects, research projects, and in industry.

 (iv) Homework:  Read the abstracts from Parnas's collection of docs, and give an integrated
        framework that Parnas was trying to describe.

(2) The Key Design Principles

 (i) Analogous to software design principles
  (a) Separation of concerns (requirements, resource allocation, etc)
  (b) Information Hiding (low coupling between documentation components)

(3) Application of the Separation of Concerns to the Design Process

 (i) Division of documentation into component documents based on separation of concerns.

For Next Friday (10/11):
Turn in complete journal (4 papers, 1 video, HW, project code/docs).

-- Erik Albert
 

• New group: all students are divided into 3 groups and assigned a 20-min presnetation for next Monday class. The subject for our team is "Formal documentation".

 

 
 
 

Assignment by next Friday: all journals (4 of them, including, the clock paper, the criteria paper, video tape and the documentation paper we are working on), all homework assignments, 2 projects (documentation for KWIC).

We discussed the documentation paper later:
Group 1: 1) no design before coding
                2) do not use the documents of design phase
                    need to do design first and use the documents when coding

Group 2: 1) separation of concerns -> constrains info. (that is clearly distinct and
                   independent)
                2) Info. hiding -> to make specification types of changes easy to implement.

Group 3: ideal documentation diagram.

We have not finished this part yet, which will be continue on next Monday. (10/07/02)

-- Wang Jia
 
 

• We discussed the Hester, S.D, Parnas, D.L., and Utter, D.F. "Using Documentation as a Software Design Medium" paper this class period. We broke into 3 groups to present the first three parts of the paper.

 

 
 
 

The first section brought about a discussion as to why we should go through a preliminary design process before coding a project. We agreed that most projects begin coding too early, and design decisions are often an afterthought of the coding process rather than carefully planned.

The second section focused on key design principles. The major emphasis was on the separation of concerns from the point of view of documentation. We discussed the difference between documentation concerns and modular concerns. The other point of this section was information hiding in order to make specific changes easy. We talked about the possible dangers of hiding too much information and not giving the user information about the mapping decisions made during development.

The final section was discussed briefly, and discussed a few terms. We ran out of time to go into much detail, but a question about requirements arose. Specifically, can hardware be part of the requirements. We concluded that it could because requirements are defined as anything that the outside world needs in order for the software to operate properly.

Assignments:
Friday, October 11:
All 4 journal entries, all homeworks, and both projects in your journal

-- Aaron Strange

Friday, October 11, 2002

• Today we discussed Davis Parnasí A Rational Design Process: How and Why to Fake It. We started the discussion with an interesting question. What are some types of program families or what are some ways to group programs together. We came up with some good examples in functionality, architecture, and product family. There are many other ways one could group programs, and these are just a few.

 

 
 
 

We then tackled the first section in the paper, which asked the question: Why is a software design process always an idealization? This is asking why a design process cannot exactly follow a rational design process. Some reasons are below:
- In many cases the user does not know exactly what they want/need or are unable to communicate it
- Even with all the requirements in hand, there are still facts missing that we need to complete the process, resulting in backtracking later on
- Humans are unable to fully comprehend the entire system as a whole, and errors will be made while separating concerns.
- Projects are subject to change due to external reasons, which may result in invalid design decisions
- Humans will make mistakes as long as they are involved
- Spontaneous ideas, which may not be the best for a given project, are often used as a way for the developer to test out an idea or technique.
- Projects often require reuse of existing software, which may not be ideal for the current project.

We closed the discussion with a point about documentation versus "the system". The documentation should be thought of as the system. The code is not the system. It is a description of the implementation of the system, but only part of the total system.

Assignments:
For Wednesday:
- Read David Garlan: Research Directions in Software Architecture

-- Aaron Strange

Friday, October 18, 2002

• We continue to discuss David Parnas and Paul Clements' paper "A Rational Design Process: How and Why to Fake It".

 

 
 
 

The class was divided into three groups to discuss the following topics:
1. Why will the software design process be always an idealization?
2. Why is it useful even if it is an idealization?
3. What should the software description tell us?

Topic 1: Why will the software design be always an idealization?
We discussed the seven reasons why a software design process will always be an idealization:
1. Users unable to describe requirements;
2. Even the requirements are known, many details cannot be known until the implementation phase (for example, there could be inconsistencies in requirements);
3. Humans can work with only a manageable amount of information (general picture vs. detailed picture);
4. Requirements changes for external reasons;
5. Humans make errors;
6. Humans have preconceived ideas (that may be derived not from the system requirements but from previous experience, knowledge, etc.);
7. Have to reuse existing software for economic reasons.

The discussion of the last reason led us to few interesting points:
- Reuse of existing software could result in hematomas of duplication discussed by Gregor Kiczales in his video "Why Black Boxes are so Hard to ReuseÖ".
- The idea of reusing the existing software is utilized in creating COTS (Common-Of-The-Shelf software); the last is also an idealization (for the different parts of the system not necessarily match).
- Notion of a program family -- is it
- Programs with different structures but similar functionality;
- Programs that have strong architectural relationship; or
- Product line?

Topic 2: Why is a description of a rational idealized process useful?
Rational idealized software design process used as a standard process provides the following benefits.  It can be used as/to:
1. a guidance for designers (helps us how to proceed);
2. use the experience/knowledge of other designers (the effort to find the facts necessary to design an ideal system helps to design better and backtrack less);
3. measure the progress a project is making;
4. review the project (easier to review the documentation than the code);
5. transfer people, ideas, and software between projects.

Assignments:
Read papers:
- David Garland "Research Directions in Software Architecture" and
- Mary Shaw, "Comparing Architectural Design Styles."

Prelim is scheduled for November 9; papers for the exam will be given out on November 2.

-- Aitbala Sargent

Back to Table of Contents 

---

Monday, October 21, 2002

• In The previous architecture, Object oriented, there was the black box where we could not see what's going on inside, but instead we know the interface for each black box, or object. In the State-Based Architecture, we get to have a look about the states inside the box to see what's is exactly going on. State-based architecture focus on the major states of the system and on the events that cause the transition between states. State machines appear as secondary views in Kerby design, as well as in Shaw's feedback-control design and Paul Ward and Dinesh Keskar's real-time design.

 

 
 
 

-- Kamal Shannak
 

• Today we discussed Part of the Mary Shaw's paper "Comparing Architectural Design Styles".

We discussed the topics :
 Cruise-Control Problem
 Objected-oriented Architectures
  i) Booch:Object-oriented programming.
  ii) Yin and Tanik: Reusability

We compared the object-oriented designs of both Booch model and Yin and Tanik models and their architectuaral designs.

--Neelima Guduru.
 

• This class we started Mary Shawís paper Comparing Architectural Design Styles. We looked at the cruise control problem and the first two object oriented designs for it. We first talked about the system definitions, followed by Boochís version of the architecture, ad finished with Yin and Tanikís version.

 

 
 
 

The major discussion involved the diagrams that were used to discuss each architecture. In particular, the semantics of the boxes and arrows I each diagram. Booch approached the problem differently than Yin and Tanik, although both used object based designs. One major difference was that Yin and Tanik encapsulated current speed and desired speed into one object, the cruise control system. This doesnít change the system a lot, but resulted in noticeable change in the interactions of objects in the diagram.

There was also a discussion regarding the circles and arrows semantics between diagrams in the same design. For example, Boochís dataflow, functional, and object-oriented diagrams are all just boxes and arrows, but they all mean something different. In the dataflow diagram, there are boxes for objects, functions, and data. The arrows show the flow of data in the system. The functional diagram shows the functions of the system and how they interact it the cruise control system. The object oriented design had object boxes and access arrows.

In summary, the major point of this class was to show that boxes and arrows can have many different meanings, and that one must be careful when looking at diagrams to be sure they have the right semantics.

-- Aaron Strange

Friday, October 25, 2002

• Today we discussed Shawís process-control paradigm. We are divided into 4 groups to represent each figure. The figure 16 serves as control architecture for cruise control. It represents a control relation. However it doesnít capture the whole facets of the problem. We also discussed the box and arrow representation. In this figure, there are 2 diagrams (object diagram and data flow diagram) superimposed to each other. The figure 17 is used to determine if the system is active or not. This figure can be used to solve active/ inactive toggle from previous figure. Itís a state-transition diagram. It uses only 5 states to capture the key events in the system. We also simulated the state transition based on both figures. We examined the relationship between them. Figure 18 is an event table for determining set point. It can be added to figure 16 to determine desired speed input. The last figure is like a whole picture that incorporates above 3 figures. We also discussed the clock in the figure. Itís interesting to see how 3 different diagrams combine to have a new face of the system. Todayís discussion also addressed how one diagram can be mapped to other. We also tried to redraw some figure to make it clearer.

 

 
 
 

-- Haidong Bao
 

• We continued our discussion of the Shaw "Comparing Architectural Design Styles" paper. All students were divided into 4 groups and responsible for one figure (figure 16, 17, 18, 19). We focused on interrelation between any two of them. The cruse control system was discussed in detail to show how one object interacts with others.

 

 
 
 

We also discussed where the object oriented model fits in. Actually, in shaw's paper, objects sometimes can be referred as "function" and arrows/arcs between them would be dataflow, accessibility or use. In here, the concept of Object-oriented has more general meanings.

Basically, Fig. 16 is the main part of the system and it can be break down to several parts into Fig. 17 and fucntionality is defined in Fig. 18 (Table).A little confusion at the end, when we talked about the clock in Fig. 19. Why is the clock shown by itself and what is the idea behind that. This needs to be straightened out later.

-- Wang Jia

Monday, October 28, 2002

• Today we discussed Dr. Wheelerís paper on formal documentation. We were divided into 3 groups. One is to describe the system documentation structure figure, one is to describe Parnasís figure. Both groups are to compare with each other. The other group is to draw the finite state machine of the traffic light example given in this paper. The 2 figures are similar to some extent. We went through all the details of Wheelerís figure. In functional architecture or "A", he introduced validation plan. The validation plan here is not the same as the test plan in Parnasís. The validation plan here is sort of mixture of requirement. As he mentioned, the system specification is informal. Only that formal specification can be validated at this phase. When specification is finished, we need to validate that if the specification meets the requirement. Since some time the requirement is not clear and complete and even casual sometimes. We need to work closely with the user. Since we make specification based on requirement, itís expected that lots of work on writing down formal requirement. The final product is system specification, which serves as a contract between system analysis and end user. This process involves lots of collaboration between those 2 groups. In this thought, validation plan is generated based on requirement to test the specification. And the whole part fits in requirement specification in Parnasípaper. Then we discussed modularization rationale. Itís not in Parnasí figure. He did mention about it. Basically itís to say why we decompose modules in this way or that way, the design decision involved, the other choices and tradeoffs of them. Another interesting part is that module dependency and module interface is encapsulated in a box called system architecture in Wheelerís paper, while they are separate boxes in Parnasí. In wheelerís, the encapsulation is to follow information hiding and separation of concern. Itís possible that we may change module decomposition later, thus module interface as well, since they are coupled. In this way encapsulate them in a box; we hide the decision from outside so we minimize the cost of any change of inside. It addresses the interaction between these 2 parts. In Parnasí they are separate components, although they reflect the same relationship and dependency, the design doesnít follow the principle exactly. We also find that resource allocation part is missing. Assignment: we are asked to find out where Parnas talks about justification of module decomposition. whatís the reason that 2 figures have different way leading to process structure. Finally we will do finite state machine based on the example individually.

 

 
 
 

-- Haidong Bao
 

• Today, we compared and contrasted Wheeler's System Documentation Structure(figure 2-1) with Hester and Parnas' Documentation framework (fig 1).

 

 
 
 

Our discussion ficus on the differences bewteen Wheeler's paper and Parnas' paper.

(1) The difference between Validation and Verification:
    Validation means to confirm about what the user wants.
    Verification means to make sure the things we want.
(2) There are "Validation/Verification plan" on each level in Wheeler's paper, but there is only verification code in Parnas' paper.
(3) Wheeler put "Module Dependency" and "Module Interface" into one Box called "System Architecture" since they works closer to each other and affect to the implementation of the system.
(4) Wheeler use "Modularization Rationale" between "System Specification" and "Module Decomposition". It emphasize the reason why we decompose module like that. But there is no Rationale part in Parnas' paper.
(5) Wheeler do not use the "Resource Allocation" in his paper. It meight be included in the "System Specification" part.
(6) Wheeler put "Process Structure" and "Module Design" into one box called "Detail Disign" which focus on the implemetation detail information.
 

Assignment:

-Go back to read and go over Parnas' paper again and to make sure why there are two arrows from "Module Decomposition" to "Resource Allocation" and "Process Structure".
-Construct a FSA Machine to demostrate the system behavior of Stoplight Control System.
-Prepare the final project from now. Read the paper carefully and set up a meeting with Prof. Larry next week to talk about the final project.

-- Jiang Ma