|Friday, 9/6||Lamport Overview|
|Monday, 9/9||Clocks and "Happened Before"|
|Wednesday, 9/11||Clocks and "Happened Before" (continued)|
|Friday, 9/13||3 Aspects of Mutual Exclusion algorithm|
|Friday, 9/20||Review of Lamport Mutual Exclusion Algorithm Prototype|
|Monday, 9/23||Lamport paper review and Parnas paper introduction|
|Wednesday, 9/25||The Criteria for Decomposing Systems into Modules (cont.)|
|Monday, 9/30||Why Black Boxes Are So Hard to Reuse|
|Wednesday, 10/2||Why Black Boxes Are So Hard to Reuse (cont.)|
|Friday, 10/4||Using Documentation as a Software Design Medium|
|Friday, 10/11||A Rational Design Process: How and Why to Fake It|
|Friday 10/18||A Rational Design Process: How and Why to Fake It (cont.)|
|Monday, 10/21||Comparing Architectural Design Styles|
|Friday, 10/25||Comparing Architectural Design Styles (cont.)|
|Monday, 10/28||Wheeler - Stoplight Control System|
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
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.
- 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.
- What is the mathematics in Leslie Lamport's paper?
- What is the definition of a Partial Order?
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.
- What were the mathematics in this paper?
- Carefully read the section on totally ordering.
-- Glen Beane
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
(1) "Happened before" relation, which is also a partial ordering relation
and an error relation. And what does "happened before" relation fit in
(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
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
(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
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
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.
- 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
- Present one implementation of Lamportís mutual exclusion algorithm.
-- Aaron Strange
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.
-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
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
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
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
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
- 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
- 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
- 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.
- 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
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
- 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
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.
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
FROM OOPSLA 1994
WHY BLACK BOXES ARE SO HARD TO REUSE :
A NEW APPROACH TO ABSTRACTION FOR THE ENGINEERING OF SOFTWARE
Xerox Palo Alto Research Center.
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
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
-- Haidong Bao
(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
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
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
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.
Friday, October 11:
All 4 journal entries, all homeworks, and both projects in your journal
-- Aaron Strange
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.
- Read David Garlan: Research Directions in Software Architecture
-- Aaron Strange
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.
- 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
-- Kamal Shannak
We compared the object-oriented designs of both Booch model and Yin and Tanik models and their architectuaral designs.
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
-- Haidong Bao
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
-- Haidong Bao
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.
-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