Branch-and-Bound Pattern
The pattern has 4 basic operations branching, evaluation, bounding, and pruning operations. The problem is split into sub problems like branches and this decomposition can be done using some other patterns like geometric decomposition pattern or so, and then these pieces can be parallelized and run on multiple cores. Each sub problem get evaluated and if it has a feasible solution then proceed it for the bounding and then to prune so that we will have optimal solution.
I like the flowchart and it’s very nicely described. I like the algorithmic style of presenting the paper as it is appropriate for this one.
Graphical Models Pattern
Looks like this pattern is still in process and didn’t give me a feel for it be a parallel pattern. It only mentioned how transformations and searching of trees can be parallelized. I am not sure if I understand the whole problem that author is trying to solve. Looking forward for class and then reread it again…
Structured Grids Pattern
This pattern explains how to parallelize operations on a large grid or array. The pattern uses geometric decomposition to decompose the problem into smaller arrays and then operations are performed in parallel in each array. Ghost nodes are used to figure out any dependencies of neighboring nodes.
I like the double buffering and adaptive mesh refinement idea s to refine the rendering. I have read some adaptive mesh refinements before in gaming to reduce the number of vertices and edges in a 3D model. Usually this is performed during game development and cached somewhere. Overall I like this paper batter than others I have read for this week’s class.
Thursday, November 12, 2009
Shared Queue, Speculation, Circuits
I would like to say a pattern paper with more than 8-10 pages may be boring and it may not keep users undivided attention in reading it. So Prof. Johnson is clever asking us to write a pattern with 6 or so pages.
All these 3 pattern papers are too long to me and for last few pages I struggled to keep my attention. Concepts for patterns are clear but they may have done a better job keeping it simple and clear with good examples. Here is my brief review on these patterns and looking forward for good discussion on these though…
Shared Queue Pattern
Shared queues are well known in application development community. A centralized share queues are easier to implement. A well known use of shared queue is with a thread pool. This can be implemented as individual threads take tasks directly from the queue or a master thread distributes the tasks to the threads.
This paper used the examples with separate locks for push and pull but I think it is easier to use and maintain a single lock for the entire queue. Two locks might be more depending on the number threads at a time in the queue and maximum size of the queue.
Speculation Pattern
This speculation is similar to branch prediction that I learned in CS421. Given example is not very clear to me and I may get better understanding of this pattern with respect to parallel world and speculation.
Circuits Pattern
As I am learning about the time bounds that depend on the input size from the algorithms class (As algorithm teaches to be linear or polynomial in execution of the algorithm with respect to input size) this pattern’s problem is eye catching for me.
I like the example but I wish they showed it from high level language. I have to listen to class to get more insight in this one….
All these 3 pattern papers are too long to me and for last few pages I struggled to keep my attention. Concepts for patterns are clear but they may have done a better job keeping it simple and clear with good examples. Here is my brief review on these patterns and looking forward for good discussion on these though…
Shared Queue Pattern
Shared queues are well known in application development community. A centralized share queues are easier to implement. A well known use of shared queue is with a thread pool. This can be implemented as individual threads take tasks directly from the queue or a master thread distributes the tasks to the threads.
This paper used the examples with separate locks for push and pull but I think it is easier to use and maintain a single lock for the entire queue. Two locks might be more depending on the number threads at a time in the queue and maximum size of the queue.
Speculation Pattern
This speculation is similar to branch prediction that I learned in CS421. Given example is not very clear to me and I may get better understanding of this pattern with respect to parallel world and speculation.
Circuits Pattern
As I am learning about the time bounds that depend on the input size from the algorithms class (As algorithm teaches to be linear or polynomial in execution of the algorithm with respect to input size) this pattern’s problem is eye catching for me.
I like the example but I wish they showed it from high level language. I have to listen to class to get more insight in this one….
Monday, November 9, 2009
PRES: Probabilistic Replay with Execution Sketching on Multiprocessors
This paper is interesting to read (took few passes to get hold of what authors are saying) and like the ideas presented. Looking forward for good discussion in the class tomorrow --
What do you expect from a debugging tool?
Let me examine the internal state of the application throughout the execution of it so that I can see what is going on inside while it is executing the code.
What debugging tools do you usually use? What are good and bad about them?
I use Rational Software products server web sphere server (based of Eclipse) run in debug mode and look at the system out and error logs to debug the app and server allow to be started in debug mode and we can insert the break points so that when server steps in to that place it will stop and take details of the details and we can also do line debugging as we step through the app.
It is good because it will show us the variable values and method interaction etc… at time that were setup through break points. However, they are bad for concurrent programming debugging.
I wish this tool have a way to more naturally step through the interactions rather than stepping through the breakpoints or prescheduled items and produce the results of the values and interactions as it completes the task.
What are the challenges of debugging a sequential program? What are additional challenges of debugging a parallel program?
Debugging in a sequential program is relatively easy with a tool. Just give some known input with an expected output, and step through the application to see how the input is changed it resulted in bad or unwanted output than what was expected. Debugging parallel programs is harder as we need to know how the work is divided and what to expect the results for the piece that is getting executed on a single etc…
How important is replay for debugging?
If we can’t reproduce the bug and know where it is coming from then it is very hard to be able to fix it and know that it (same bug) won’t be occur again in the future. Debugging allow us to efficiently reproduce the bug and lead us or show us the potential reason for the bug so that we can fix it.
If you need to design a deterministic replay system, how are you going to do it for sequential programs? Does it work for parallel programs? If no, how to make it work?
For sequential programs, we can take state information at various points in the program that would give enough information to known where the inconsistencies are occurring and then the deterministic algorithm can use this information to find the reply. The same idea can be applied to parallel programs, but they may need more current state information gathered from different cores and give to deterministic algorithm to find the reply back.
What do you expect from a debugging tool?
Let me examine the internal state of the application throughout the execution of it so that I can see what is going on inside while it is executing the code.
What debugging tools do you usually use? What are good and bad about them?
I use Rational Software products server web sphere server (based of Eclipse) run in debug mode and look at the system out and error logs to debug the app and server allow to be started in debug mode and we can insert the break points so that when server steps in to that place it will stop and take details of the details and we can also do line debugging as we step through the app.
It is good because it will show us the variable values and method interaction etc… at time that were setup through break points. However, they are bad for concurrent programming debugging.
I wish this tool have a way to more naturally step through the interactions rather than stepping through the breakpoints or prescheduled items and produce the results of the values and interactions as it completes the task.
What are the challenges of debugging a sequential program? What are additional challenges of debugging a parallel program?
Debugging in a sequential program is relatively easy with a tool. Just give some known input with an expected output, and step through the application to see how the input is changed it resulted in bad or unwanted output than what was expected. Debugging parallel programs is harder as we need to know how the work is divided and what to expect the results for the piece that is getting executed on a single etc…
How important is replay for debugging?
If we can’t reproduce the bug and know where it is coming from then it is very hard to be able to fix it and know that it (same bug) won’t be occur again in the future. Debugging allow us to efficiently reproduce the bug and lead us or show us the potential reason for the bug so that we can fix it.
If you need to design a deterministic replay system, how are you going to do it for sequential programs? Does it work for parallel programs? If no, how to make it work?
For sequential programs, we can take state information at various points in the program that would give enough information to known where the inconsistencies are occurring and then the deterministic algorithm can use this information to find the reply. The same idea can be applied to parallel programs, but they may need more current state information gathered from different cores and give to deterministic algorithm to find the reply back.
Loop Parallelism - Task Queue - Graph Partitioning
These pattrens are neatly documented and easy to understand while i was reading. I will try to answer James questions on these to continue conversation...
Loop Parallelism
1. The author says the goal of incremental parallelization is to "evolve" a sequential program into a parallel program. If you have experience in refactoring code from sequential to parallel, how did your approach differ from the steps presented in the paper?
Paper gave good approach in my view. If it were me, probably I start with mostly used areas (frequency) and analyze it first and then combine with rest of the code. If the entire app is difficult to change then look for the pieces that can be improved and apply parallelism to them.
2. Many of us have used Eclipse or another IDE, with their respective plugins, for execution profiling. What has been your experience with these tools? What is your preferred method of locating the code in question (automatic or manual)?
I have used profiling facilities that are provided in Rational Software Architect (It is based on the eclipse platform). I used it to write a plug-in which will give us the code coverage analysis (How much of your code is covered through your test cases). My preferred method is automatic.
3. The author states, "The application of many transformations to many loops may be necessary before efficient performance is achieved." What is your opinion on this statement?
It depends on complexity and also understanding of the underlying loop more than anything else. So more you know about the loop and its potential transformation the more you can optimize the transformation.
Task Queue
How would you compare the Task Queue pattern to other similar distribution patterns like divide-and-conquer and fork/join pattern?
We have a queue or queues that have multiple tasks coming in, so we take each task (divide) and work on it and when we are done with it we post the results to caller(conquer step).
Graph Partitioning
This was probably one of the more math-oriented patterns I have seen and/or read. How often have you experienced a situation where the graph partition strategy would have been useful? If never, can you think of any future situations where this pattern might be come in handy and could be applied
Any situation that can be represented as graph and have some known structure (like bipartite or so on) then we should be able to use this pattern. I can think of a situation where I need to program matching and find best matching of the pairs (which is typical graph theory app) and we can represent that as bipartite graph and use this pattern. It may not be anytime soon using this pattern in my work…
Loop Parallelism
1. The author says the goal of incremental parallelization is to "evolve" a sequential program into a parallel program. If you have experience in refactoring code from sequential to parallel, how did your approach differ from the steps presented in the paper?
Paper gave good approach in my view. If it were me, probably I start with mostly used areas (frequency) and analyze it first and then combine with rest of the code. If the entire app is difficult to change then look for the pieces that can be improved and apply parallelism to them.
2. Many of us have used Eclipse or another IDE, with their respective plugins, for execution profiling. What has been your experience with these tools? What is your preferred method of locating the code in question (automatic or manual)?
I have used profiling facilities that are provided in Rational Software Architect (It is based on the eclipse platform). I used it to write a plug-in which will give us the code coverage analysis (How much of your code is covered through your test cases). My preferred method is automatic.
3. The author states, "The application of many transformations to many loops may be necessary before efficient performance is achieved." What is your opinion on this statement?
It depends on complexity and also understanding of the underlying loop more than anything else. So more you know about the loop and its potential transformation the more you can optimize the transformation.
Task Queue
How would you compare the Task Queue pattern to other similar distribution patterns like divide-and-conquer and fork/join pattern?
We have a queue or queues that have multiple tasks coming in, so we take each task (divide) and work on it and when we are done with it we post the results to caller(conquer step).
Graph Partitioning
This was probably one of the more math-oriented patterns I have seen and/or read. How often have you experienced a situation where the graph partition strategy would have been useful? If never, can you think of any future situations where this pattern might be come in handy and could be applied
Any situation that can be represented as graph and have some known structure (like bipartite or so on) then we should be able to use this pattern. I can think of a situation where I need to program matching and find best matching of the pairs (which is typical graph theory app) and we can represent that as bipartite graph and use this pattern. It may not be anytime soon using this pattern in my work…
Tuesday, November 3, 2009
Task Parallelism, Recursive Splitting, Discrete Event
Task Parallelism
As name suggested task parallelism is nothing but task level parallelism, breaking a large task into many smaller ones, and then proceeding to find which ones can operate in parallel. This pattern has lot of details in it along with some hardware details that are relevant for the parallelism (needed 2 passes to grasp what author is saying about). I like the context and Forces section but thought solution section may need some more improvement with more clear information on how to approach the solution.
Recursive Splitting
This pattern describes how one can effectively implement parallel execution for the recursive algorithm that splits the data and each part of the recursion will execute as a separate task. This paper talked about following as solution steps for algorithmic strategy involving recursive splitting:
1. Express problem recursively with more than one task generated per call
2. Use a balanced data structure, if possible
3. Use a fork-join or task-queue implementation
4. Use optimizations to improve locality
I like the clarity and simplicity of the paper.
Discrete Event
This pattern is interesting one. Here the problem described for this pattern(from paper) :
Suppose a computational pattern can be decomposed into groups of semi-independent tasks interacting in an irregular fashion. The interaction is determined by the flow of data between them which implies ordering constraints between the tasks. How can these tasks and their interaction be implemented so they can execute concurrently?
And solution (from paper):
A good solution is based on expressing the data flow using abstractions called events, with each event having a task that generates it and a task that processes it. Because an event must be generated before it can be processed, events also define ordering constraints between the tasks. Computation within each task consists of processing events.
I like the approach of how it makes easier to detect deadlocks, but like see more examples in implementation point of view.
As name suggested task parallelism is nothing but task level parallelism, breaking a large task into many smaller ones, and then proceeding to find which ones can operate in parallel. This pattern has lot of details in it along with some hardware details that are relevant for the parallelism (needed 2 passes to grasp what author is saying about). I like the context and Forces section but thought solution section may need some more improvement with more clear information on how to approach the solution.
Recursive Splitting
This pattern describes how one can effectively implement parallel execution for the recursive algorithm that splits the data and each part of the recursion will execute as a separate task. This paper talked about following as solution steps for algorithmic strategy involving recursive splitting:
1. Express problem recursively with more than one task generated per call
2. Use a balanced data structure, if possible
3. Use a fork-join or task-queue implementation
4. Use optimizations to improve locality
I like the clarity and simplicity of the paper.
Discrete Event
This pattern is interesting one. Here the problem described for this pattern(from paper) :
Suppose a computational pattern can be decomposed into groups of semi-independent tasks interacting in an irregular fashion. The interaction is determined by the flow of data between them which implies ordering constraints between the tasks. How can these tasks and their interaction be implemented so they can execute concurrently?
And solution (from paper):
A good solution is based on expressing the data flow using abstractions called events, with each event having a task that generates it and a task that processes it. Because an event must be generated before it can be processed, events also define ordering constraints between the tasks. Computation within each task consists of processing events.
I like the approach of how it makes easier to detect deadlocks, but like see more examples in implementation point of view.
Armstrong Thesis – Chapter 5:
This chapter describes how to program fault-tolerance using Erlang. The reading describes strategies for programming fault-tolerance, supervision hierarchies, and well-behaved functions.
A fault-tolerant system should be organized into a hierarchy of tasks. The highest level tasks should run the application according to the software design specification. If this task cannot be performed then a simpler lower level task should be performed. I like the strategies mentioned in this chapter and I am thinking it will provide robust and fault tolerable system. I like the idea of having supervision hierarchies. The tree representation is a nice way of distributing error recovery responsibilities to nodes, so that each node can monitor the errors in its descendent nodes.
Described error recovery mechanism looks good but it may be difficult to identify and define the errors in order to write the error recovery mechanism, I am thinking it may be nice idea if we can write some generic error recovery mechanisms and let the application have some intelligence to see which type of error recovery that It can apply to and as the application more used then programmers can better guess the error styles and errors so outer layer app should be able to pick up these added error recoveries and use them. Well-behaved functions (WBF) are a way of determining what an error is(probably this should build that intelligence in choosing the right error category like I mentioned above). WBF are functions that should not generate an exception unless an error is encountered. So this allows the programmer to interpret any exception generated by a WBF as an error. I like the rules specified to when to raise the exceptions.
A fault-tolerant system should be organized into a hierarchy of tasks. The highest level tasks should run the application according to the software design specification. If this task cannot be performed then a simpler lower level task should be performed. I like the strategies mentioned in this chapter and I am thinking it will provide robust and fault tolerable system. I like the idea of having supervision hierarchies. The tree representation is a nice way of distributing error recovery responsibilities to nodes, so that each node can monitor the errors in its descendent nodes.
Described error recovery mechanism looks good but it may be difficult to identify and define the errors in order to write the error recovery mechanism, I am thinking it may be nice idea if we can write some generic error recovery mechanisms and let the application have some intelligence to see which type of error recovery that It can apply to and as the application more used then programmers can better guess the error styles and errors so outer layer app should be able to pick up these added error recoveries and use them. Well-behaved functions (WBF) are a way of determining what an error is(probably this should build that intelligence in choosing the right error category like I mentioned above). WBF are functions that should not generate an exception unless an error is encountered. So this allows the programmer to interpret any exception generated by a WBF as an error. I like the rules specified to when to raise the exceptions.
Tuesday, October 20, 2009
Armstrong Thesis Ch2: The Architectural Model
This chapter presents architecture for building fault-tolerant systems.
The keys to this software fault-tolerance are(from the paper directly):
• Software modularity through processes, and messages.
• Fault containment through fail-fast software modules.
• Process-pairs to tolerant hardware and transient software faults.
• Transaction mechanisms to provide data, and message integrity.
• Transaction mechanisms combined with process-pairs to ease exception handling, and tolerate software faults.
The main goals of programming concurrently(COPL – explained down) is reliability (through the process abstraction), scalability, security and even modularity.
Processes are stated as central items in the system and author states that the only way to have true reliability is to have each module in its own process so that errors can be contained and the process killed if an error is detected. The idea is that when the error process is killed environment can be recovered quickly as all other processes are error free and the only one which had issues have been killed. This makes the recovery easier.
Author introduced a new concept of a Concurrency Oriented Programming Language (COPL) in which programs should model the concurrent items and programmers can map the concurrency world one-to-one with the concurrency of their programs. To achieve this it is made a first class citizen of the language and the runtime environment utilizes green threads to make concurrency cheap, which gives the programmer the freedom to model all the concurrency of the problem domain. I have to read one more time to get full idea but hoping to listen to class first on this item.
Processes communicate through asynchronous message passing. So no state can be shared and process share data through message passing. This communication style supposed to enforce more reliability, since messages are asynchronous should make the system more dead lock free and programs that copy data have greater data locality and avoid false sharing, which are important for performance.
The keys to this software fault-tolerance are(from the paper directly):
• Software modularity through processes, and messages.
• Fault containment through fail-fast software modules.
• Process-pairs to tolerant hardware and transient software faults.
• Transaction mechanisms to provide data, and message integrity.
• Transaction mechanisms combined with process-pairs to ease exception handling, and tolerate software faults.
The main goals of programming concurrently(COPL – explained down) is reliability (through the process abstraction), scalability, security and even modularity.
Processes are stated as central items in the system and author states that the only way to have true reliability is to have each module in its own process so that errors can be contained and the process killed if an error is detected. The idea is that when the error process is killed environment can be recovered quickly as all other processes are error free and the only one which had issues have been killed. This makes the recovery easier.
Author introduced a new concept of a Concurrency Oriented Programming Language (COPL) in which programs should model the concurrent items and programmers can map the concurrency world one-to-one with the concurrency of their programs. To achieve this it is made a first class citizen of the language and the runtime environment utilizes green threads to make concurrency cheap, which gives the programmer the freedom to model all the concurrency of the problem domain. I have to read one more time to get full idea but hoping to listen to class first on this item.
Processes communicate through asynchronous message passing. So no state can be shared and process share data through message passing. This communication style supposed to enforce more reliability, since messages are asynchronous should make the system more dead lock free and programs that copy data have greater data locality and avoid false sharing, which are important for performance.
Event based and Map reduce patterns
Event based
This pattern talks about how the composed of components can post events or listen to events and a medium which is act as the bridge between the listeners and announcers. The medium dispatches the received events to affected listeners and allows listener to register and listen to events of their choice. Nicely written pattern and I used this in CS427 when I developed an android application.
Map reduce
I have introduced to this one when I did functional programming last semester using Ocaml. The idea is applied with parallelism here. The map function is applied in parallel to each object in a set, then the results are collected and combined by the reduce function to get the output. This is implicitly implemented so user’s just needs to supply the map and reduction and everything else will be taken care by the framework. This is very useful pattern as we have larger data sets and like to apply the reductions on it.
This pattern talks about how the composed of components can post events or listen to events and a medium which is act as the bridge between the listeners and announcers. The medium dispatches the received events to affected listeners and allows listener to register and listen to events of their choice. Nicely written pattern and I used this in CS427 when I developed an android application.
Map reduce
I have introduced to this one when I did functional programming last semester using Ocaml. The idea is applied with parallelism here. The map function is applied in parallel to each object in a set, then the results are collected and combined by the reduce function to get the output. This is implicitly implemented so user’s just needs to supply the map and reduction and everything else will be taken care by the framework. This is very useful pattern as we have larger data sets and like to apply the reductions on it.
Thursday, October 15, 2009
On OPL Pattrens - Pipes & Filter, Layered Systems, Iterative Refinement
We already studied about Pipes&Filters and Layered patterns but these OPL papers present them from a parallel perspective.
The new Pipes & Filters and Layered Systems patterns are written in very simple form and give us the quick idea on the pattern.
Since these are familiar patterns to continue our conversation on these topics, I present my thoughts on Prof. Johnson’s questions –
How do the two repeats differ from the first versions that you read?
These new versions of Layered Systems and Pipes and Filers Systems presented for parallel system. For Pipes and Filers I like the solution presented as directed graph gave a good idea on the solution through this analogy.
They are shorter. Did they miss anything?
Since I am familiar with these patterns they look sufficient but after reading I thought it may be difficult for those who are learning these patterns for the first time to understand fully from these papers.
Did they include something that the first versions didn't?
First version has more details of how we can implement these patterns than this version but I like the idea of presenting the solution for pipes-n-filters pattern for parallelism through a directed graph.
Did you learn anything from them?
Not really. But like the way they presented simple and straight forward.
Do you have any advice to the authors of these patterns?
I would like to suggest presenting more on how these patterns (since they are known and common patterns for the sequential app designers) could be used or modified to use parallelism advantages more explicitly.
For the new pattern, have you seen programs that used it?
I didn’t use it before but it reminded me of general programming loops and Danny Dig’s paper ReLooper and felt familiar to me.
The new Pipes & Filters and Layered Systems patterns are written in very simple form and give us the quick idea on the pattern.
Since these are familiar patterns to continue our conversation on these topics, I present my thoughts on Prof. Johnson’s questions –
How do the two repeats differ from the first versions that you read?
These new versions of Layered Systems and Pipes and Filers Systems presented for parallel system. For Pipes and Filers I like the solution presented as directed graph gave a good idea on the solution through this analogy.
They are shorter. Did they miss anything?
Since I am familiar with these patterns they look sufficient but after reading I thought it may be difficult for those who are learning these patterns for the first time to understand fully from these papers.
Did they include something that the first versions didn't?
First version has more details of how we can implement these patterns than this version but I like the idea of presenting the solution for pipes-n-filters pattern for parallelism through a directed graph.
Did you learn anything from them?
Not really. But like the way they presented simple and straight forward.
Do you have any advice to the authors of these patterns?
I would like to suggest presenting more on how these patterns (since they are known and common patterns for the sequential app designers) could be used or modified to use parallelism advantages more explicitly.
For the new pattern, have you seen programs that used it?
I didn’t use it before but it reminded me of general programming loops and Danny Dig’s paper ReLooper and felt familiar to me.
Chess - Finding and Reproducing Heisenbugs in Concurrent Programs
CHESS is an automated concurrency testing tool developed my Microsoft for finding and reproducing Heisenbugs in the concurrent programs. “Heisenbugs” are bugs resulted from unexpected interference among threads, which are extremely difficult to reproduce and eliminate. This type of bugs may show up in systems that may otherwise have been running stable for months and their cause may be as simple as adding some extra debug statements.
When Chess is attached to a concurrent program, it takes complete control over the scheduling of threads and asynchronous events and captures all the interleaving non determinism in the program. This provides a way to find all the execution paths results in an error and can reproduce. The challenge here is not only to integrate CHESS with complex APIs but also to make sure that it does not introduce extra behavior that is not related to the concurrent program.
The most important component of CHESS, the scheduler and the primary goal of the CHESS scheduler is to capture all the nondeterminism during a program execution. This allows the scheduler to later reproduce a chosen concurrent execution by replaying these nondeterministic choices. It is implemented by redirecting calls to concurrency primitives to alternate implementations from a wrapper library. Including an implementation of these primitives as part of the program is a design choice that may simplify the schedule which now needs to understand only simpler system primitives that the lock implementation uses. However the tradeoff with this approach is that it does not allow the scheduler to expose all the nondeterminism in the lock implementation. Another design decision meant to simplify the implementation of the scheduler is to abstract the execution of the concurrent program using Lamport’s happens-before graph, which is a graph that captures the relative execution order of threads in a concurrent program. This approach offers a common framework for reasoning about all synchronization primitives used in the program which abstracts away the timing of instructions in the execution.
One more important piece of chess is dealing with data races uses single threaded execution. This may slow down the execution a bit but it can be compensated by running multiple instances in parallel, each exploring a different part of the interleaving state space.
I think this is very good tool to capture bugs that are uncaught by stress testing and it is also tracking where the bugs are accruing in the execution and this make the tool very valuable. It will be nice to try out the tool in future.
When Chess is attached to a concurrent program, it takes complete control over the scheduling of threads and asynchronous events and captures all the interleaving non determinism in the program. This provides a way to find all the execution paths results in an error and can reproduce. The challenge here is not only to integrate CHESS with complex APIs but also to make sure that it does not introduce extra behavior that is not related to the concurrent program.
The most important component of CHESS, the scheduler and the primary goal of the CHESS scheduler is to capture all the nondeterminism during a program execution. This allows the scheduler to later reproduce a chosen concurrent execution by replaying these nondeterministic choices. It is implemented by redirecting calls to concurrency primitives to alternate implementations from a wrapper library. Including an implementation of these primitives as part of the program is a design choice that may simplify the schedule which now needs to understand only simpler system primitives that the lock implementation uses. However the tradeoff with this approach is that it does not allow the scheduler to expose all the nondeterminism in the lock implementation. Another design decision meant to simplify the implementation of the scheduler is to abstract the execution of the concurrent program using Lamport’s happens-before graph, which is a graph that captures the relative execution order of threads in a concurrent program. This approach offers a common framework for reasoning about all synchronization primitives used in the program which abstracts away the timing of instructions in the execution.
One more important piece of chess is dealing with data races uses single threaded execution. This may slow down the execution a bit but it can be compensated by running multiple instances in parallel, each exploring a different part of the interleaving state space.
I think this is very good tool to capture bugs that are uncaught by stress testing and it is also tracking where the bugs are accruing in the execution and this make the tool very valuable. It will be nice to try out the tool in future.
Tuesday, October 13, 2009
Refactoring for Reentrancy
This paper is the third one on automatically refactoring programs for parallelism. In this case, the tool enabled programmers to change programs to make them reentrant, by removing global references, using lazy initializers and warning about unsafe API calls. After reading this paper, I think the tool could be useful in some situations where a program is re-factored with the goal of running several copies simultaneously but overall this tool is not very impressive and may need lot more work to be able to recognize by the users as a good tool.
In summary, the contributions of this paper are as follows (directly from the paper):
1. Characterization of the causes of non-reentrancy in Java programs,
2. Mostly-automated refactoring for making Java programs reentrant by replacing global state with thread-local state, with associated precondition checking that warns of possible behavioral changes due to fragile static initializer behavior and non-reentrant library usage,
3. An implementation of a refactoring tool, Re-entrancer, as an extension to the Eclipse JDT, and
4. An evaluation of Re-entrancer on a set of Java applications, demonstrating its practicability.
The refactoring is comprised of the following 5 steps:
1. Removal of non-reentrant accesses to library global state.
2. Encapsulation of static fields in the application in getter/ setter methods.
3. Replacing static initializers with explicit lazy initialization.
4. Replacing global state with thread-local state.
The refactoring tool does all these automatically, and gives the developer warnings before doing so. Given benchmarks for analyzing the results were far from impressive - some programs ran even slower despite using multiple threads due to the overhead created by the getters and setters. The program could also take substantial time to run. I would also have liked more reasoning on why some methods were rejected at the beginning of the paper, such as making an environment block. It requires a lot of code change, but this approach did to, it would be interesting to see them contrasted.
In summary, the contributions of this paper are as follows (directly from the paper):
1. Characterization of the causes of non-reentrancy in Java programs,
2. Mostly-automated refactoring for making Java programs reentrant by replacing global state with thread-local state, with associated precondition checking that warns of possible behavioral changes due to fragile static initializer behavior and non-reentrant library usage,
3. An implementation of a refactoring tool, Re-entrancer, as an extension to the Eclipse JDT, and
4. An evaluation of Re-entrancer on a set of Java applications, demonstrating its practicability.
The refactoring is comprised of the following 5 steps:
1. Removal of non-reentrant accesses to library global state.
2. Encapsulation of static fields in the application in getter/ setter methods.
3. Replacing static initializers with explicit lazy initialization.
4. Replacing global state with thread-local state.
The refactoring tool does all these automatically, and gives the developer warnings before doing so. Given benchmarks for analyzing the results were far from impressive - some programs ran even slower despite using multiple threads due to the overhead created by the getters and setters. The program could also take substantial time to run. I would also have liked more reasoning on why some methods were rejected at the beginning of the paper, such as making an environment block. It requires a lot of code change, but this approach did to, it would be interesting to see them contrasted.
Thursday, October 8, 2009
BA CH13: Object Oriented Vs Functional Programming
This chapter authors compare and contrast of functional programming versus object-oriented programming. OO is discovered later to functional language sets and developed nicely. So, I am not sure how we can successfully compare these 2. I only did functional programming in few of school projects (when it’s really necessary :) and not more than that but I am OO fan and I will continue to be in the coming years too.
As author mentioned in the chapter, In Object oriented programming everything is an object and will have a state and behavior. This style provides modularity and information hiding, reusability, dynamic binding, inheritance among many others.
In functional programming, a set of functions each of which performing a task. Executing these set of function results in the solution to the problem. Like in OO, functional programming is also achieving modularity, by the use of stateless functions, high level functions, and other recursively defined types, as well as lazy evaluation, so this is only shows fine-grain modularization. I think this makes it harder to use it to build larger applications
Q1: What types of problems lend themselves to a Functional Solution?
Mathematical problems that do not require remembrance of state but simply produce results after the calculations.
Q2: What types of problems lend themselves to an Object-Oriented Solution?
Real life problems, Objects that will have state and can represent items occurring in real life and can communicate with other objects and accomplish solutions.
Q3: Is the Functional universe more flexible from a software Architecture point of view? If so, how; and of not, why?
I think, we can always just take any function and pass it to other function to wrap additional functionality around it. But I think it is difficult to manage the code like this though..
Q4: Is Object-Oriented environment more manageable as a system grows towards the enterprise level? If so, how; and of not, why?
Yes, OO system is manageable as systems grow larger. As one of the main concepts of OO it is reusable and maintainable. Additional functionality can easily be added to the existing system by simply adding new classes, inheriting, changing implementations of parent methods or over writing inherited methods, etc...
As author mentioned in the chapter, In Object oriented programming everything is an object and will have a state and behavior. This style provides modularity and information hiding, reusability, dynamic binding, inheritance among many others.
In functional programming, a set of functions each of which performing a task. Executing these set of function results in the solution to the problem. Like in OO, functional programming is also achieving modularity, by the use of stateless functions, high level functions, and other recursively defined types, as well as lazy evaluation, so this is only shows fine-grain modularization. I think this makes it harder to use it to build larger applications
Q1: What types of problems lend themselves to a Functional Solution?
Mathematical problems that do not require remembrance of state but simply produce results after the calculations.
Q2: What types of problems lend themselves to an Object-Oriented Solution?
Real life problems, Objects that will have state and can represent items occurring in real life and can communicate with other objects and accomplish solutions.
Q3: Is the Functional universe more flexible from a software Architecture point of view? If so, how; and of not, why?
I think, we can always just take any function and pass it to other function to wrap additional functionality around it. But I think it is difficult to manage the code like this though..
Q4: Is Object-Oriented environment more manageable as a system grows towards the enterprise level? If so, how; and of not, why?
Yes, OO system is manageable as systems grow larger. As one of the main concepts of OO it is reusable and maintainable. Additional functionality can easily be added to the existing system by simply adding new classes, inheriting, changing implementations of parent methods or over writing inherited methods, etc...
ReLooper
This paper describes an interactive refactoring tool ReLooper for parallelizing loops in Java. It does this by using the Java ParallelArray(an array data structure that supports parallel operations over the array elements) framework, which allows operations to be carried out concurrently by threads on an array. I like this tool as it is interactive and give users a chance to make sure parallelism is done correctly. I think this tool can be very useful to parallelize a loop where each iteration performs its own independent operation. To continue conversation, here are my thoughts on Danny’s questions …
Q1: Sometimes it is possible to retrofit parallelism by refactoring an existing sequential application. Other times the whole system needs to be re-architected for parallelism. What are the advantages / disadvantages of these approaches? When would you do one over the other?
Refactoring a sequential application to parallel will give better performance over all and save cost of making the application to parallel but may leave code and architecture unclean. I may prefer this approach if I have limited resources (people and money to do it) and my application has cleaner architecture in hand and it’s not very big. In this situation, I may be able to covert the application to parallel but still be able to clean the code and architecture as needed.
I may not be able to do above in the case where I don’t have architecture of the application in hand and I don‘t know how the most of the functionalities in the application are implemented (I may be using this as black box in my newer development parts of the application). In this case, conversion may cause more confusion for maintenance and even result in different behavior of the app than required. So, we should go for either full re-architecture for parallelsim.
Q2: There are many libraries that target concurrency and parallelism (e.g., Java's ParallelArray, Microsoft's TPL, Intel's TBB, OpenMP, MPI, etc.). What are the advantages and disadvantages of using parallel libraries?
Libraries will help programmers to implement parallelism quickly and easily without worrying about some of the underlying implementation details. However, programmers may miss opportunities for parallisim overlooking only the available library available items.
Q3: The approach presented in the paper puts the programmer in the driving seat: the programmer selects a snapshot of code, and a refactoring. The process is semi-automated, but not fully automatic. Compare and contrast the refactoring approach with a fully automatic approach, like the one used in automatic parallelizing compilers.
I think each have it’s own benefits and work well for their situations. A fully automated system requires less work and may be better to use it in places where we know we don’t need human interaction to convert them from sequential to parallel, but we will need a semi-automated tool like this one where we know that we need some control how the parallasim is applied to maintain the application integrity.
Q4: Some of the transformations presented in the paper make the code harder to understand (e.g., replacing a loop with a parallel operation). What are some approaches to unclutter the parallel code?
May be some commenting showing or relating the converted items to original code (sequential code) and also maintain neat structure of the code after conversion may help to read it better.
Q5: Automatic loop parallelization has been a long time topic in the Fortran community, with compilers having various degrees of success. Is this problem still relevant for Object-Oriented code? What is different now?
I think the problem is still relevant but more complex. In OO programming we have more complicated concepts like shared objects can be more difficult to detect and account for when parallelizing code.
Q6: The paper presents some empirical evaluation to support the claim that the tool is useful. What are some other factors that you would have liked to see evaluated?
I would like to see actual data size that was run on these cores and also it will be nice to see more details along with table 2 like how much human interaction needed to resolve the conflicts etc.
Q7: The paper presents several program analyses to ensure that loop iterations can run safely in parallel. Are you convinced that these analyses are enough, in other words, can you think about examples that would not be covered by the presented analyses?
Since I haven’t tried the actual tool, it’s hard to come up with a scenario where this tool is not covered but overall paper convenes me that it is safe as it clearly described that it does static analysis on the code before conversion.
Q1: Sometimes it is possible to retrofit parallelism by refactoring an existing sequential application. Other times the whole system needs to be re-architected for parallelism. What are the advantages / disadvantages of these approaches? When would you do one over the other?
Refactoring a sequential application to parallel will give better performance over all and save cost of making the application to parallel but may leave code and architecture unclean. I may prefer this approach if I have limited resources (people and money to do it) and my application has cleaner architecture in hand and it’s not very big. In this situation, I may be able to covert the application to parallel but still be able to clean the code and architecture as needed.
I may not be able to do above in the case where I don’t have architecture of the application in hand and I don‘t know how the most of the functionalities in the application are implemented (I may be using this as black box in my newer development parts of the application). In this case, conversion may cause more confusion for maintenance and even result in different behavior of the app than required. So, we should go for either full re-architecture for parallelsim.
Q2: There are many libraries that target concurrency and parallelism (e.g., Java's ParallelArray, Microsoft's TPL, Intel's TBB, OpenMP, MPI, etc.). What are the advantages and disadvantages of using parallel libraries?
Libraries will help programmers to implement parallelism quickly and easily without worrying about some of the underlying implementation details. However, programmers may miss opportunities for parallisim overlooking only the available library available items.
Q3: The approach presented in the paper puts the programmer in the driving seat: the programmer selects a snapshot of code, and a refactoring. The process is semi-automated, but not fully automatic. Compare and contrast the refactoring approach with a fully automatic approach, like the one used in automatic parallelizing compilers.
I think each have it’s own benefits and work well for their situations. A fully automated system requires less work and may be better to use it in places where we know we don’t need human interaction to convert them from sequential to parallel, but we will need a semi-automated tool like this one where we know that we need some control how the parallasim is applied to maintain the application integrity.
Q4: Some of the transformations presented in the paper make the code harder to understand (e.g., replacing a loop with a parallel operation). What are some approaches to unclutter the parallel code?
May be some commenting showing or relating the converted items to original code (sequential code) and also maintain neat structure of the code after conversion may help to read it better.
Q5: Automatic loop parallelization has been a long time topic in the Fortran community, with compilers having various degrees of success. Is this problem still relevant for Object-Oriented code? What is different now?
I think the problem is still relevant but more complex. In OO programming we have more complicated concepts like shared objects can be more difficult to detect and account for when parallelizing code.
Q6: The paper presents some empirical evaluation to support the claim that the tool is useful. What are some other factors that you would have liked to see evaluated?
I would like to see actual data size that was run on these cores and also it will be nice to see more details along with table 2 like how much human interaction needed to resolve the conflicts etc.
Q7: The paper presents several program analyses to ensure that loop iterations can run safely in parallel. Are you convinced that these analyses are enough, in other words, can you think about examples that would not be covered by the presented analyses?
Since I haven’t tried the actual tool, it’s hard to come up with a scenario where this tool is not covered but overall paper convenes me that it is safe as it clearly described that it does static analysis on the code before conversion.
Monday, October 5, 2009
BA CH 12 : When the Bazaar Sets Out to Build Cathedrals
For Tuesday's class we will be studying BA chpater 12 and i will be leading the discussion. I am hoping to explore the following questions:
In page 283, Authors talk about some key decisions that KDE made between QT V3 to QT V4 release and favor to redesign majority of the KDE and this was risky and needed to support KDE QT 3 in parallel until completing the KDE QT 4. I think redesign is a wise decision and time proved indeed it is, “made KDE very stable and platform independent structure and this drove more users to use KDE and so on…” What can we learn from decision making? Do you have any similar experience? Do Cathedral type projects need this type of decision making in the middle of construction of the projects?
We see important projects like “PIM (personal information maintenance -Bazaar structure) is developed by open source community. Author mentioned some key technical decisions like dropping the idea if it doesn’t work in reasonable time frame; maintain the core functionality working all the time while the changes have been made to the project, etc… What are some other ideas that you get in mind while you are reading these technical decisions or some other ideas that we may have seen in cathedral type project building (in our work places)?
After reading the Evolution of Akonadi, KDEPIM community depended on architecture meetings / conference secessions to discuss the key architecture items and author mentioned about most of the high level / key items are agreed but implementation of individual items still faced some heated discussions. Have you had any similar experience where you agreed to key concept but varied how it needs to be implemented either in bazaar / cathedral model implementation of the project?
After reading the chapter I am, one more time convinced that complete problem analyzation is needed to get the powerful and complete solutions. (If we know problem excited with current piece of design / code we will fix it at some point?), Do you agree?
What are strengths of the Bazaar Structure that out build the cathedral structures that we have known?
In page 283, Authors talk about some key decisions that KDE made between QT V3 to QT V4 release and favor to redesign majority of the KDE and this was risky and needed to support KDE QT 3 in parallel until completing the KDE QT 4. I think redesign is a wise decision and time proved indeed it is, “made KDE very stable and platform independent structure and this drove more users to use KDE and so on…” What can we learn from decision making? Do you have any similar experience? Do Cathedral type projects need this type of decision making in the middle of construction of the projects?
We see important projects like “PIM (personal information maintenance -Bazaar structure) is developed by open source community. Author mentioned some key technical decisions like dropping the idea if it doesn’t work in reasonable time frame; maintain the core functionality working all the time while the changes have been made to the project, etc… What are some other ideas that you get in mind while you are reading these technical decisions or some other ideas that we may have seen in cathedral type project building (in our work places)?
After reading the Evolution of Akonadi, KDEPIM community depended on architecture meetings / conference secessions to discuss the key architecture items and author mentioned about most of the high level / key items are agreed but implementation of individual items still faced some heated discussions. Have you had any similar experience where you agreed to key concept but varied how it needs to be implemented either in bazaar / cathedral model implementation of the project?
After reading the chapter I am, one more time convinced that complete problem analyzation is needed to get the powerful and complete solutions. (If we know problem excited with current piece of design / code we will fix it at some point?), Do you agree?
What are strengths of the Bazaar Structure that out build the cathedral structures that we have known?
Tuesday, September 29, 2009
BA Ch 10: The Strength of Meta Circular Virtual Machines: Jikes RVM
I appreciate the authors for presenting the papers on Virtual Machines and their architectural and design details. Last chapter and this one are interesting to me as I use J2EE heavily but never got a chance to read about the design and implementation of JVM. After reading these 2 chapters i felt like discovered lot of details. Specifically, I also liked portion of the chapter that talked about the JVM myths. This chapter focused more on the details of VM implementation more than architecture of it.
Major portion of the chapter talked about the Meta circular virtual machine. It is a VM where the runtime environment is coded in the same language as that being hosted. Jikes is coded in Java and acts as a Java runtime environment. This allows for many techniques to increase performance and functionality. I completely agree that using Java’s collection simplifies the development by allowing the components to focus on their roles. It is a great advantage of Java compared to languages likes C where the programmer needs to take care of managing the underlying data structure and memory.
Jikes RVM implemented its own threading because of lacking multithreading support in the previous century. However, chapter noted a reference for making an API for their thread usage supposedly allowing easy substitution of other threading techniques. Another successful open source project!!!
Major portion of the chapter talked about the Meta circular virtual machine. It is a VM where the runtime environment is coded in the same language as that being hosted. Jikes is coded in Java and acts as a Java runtime environment. This allows for many techniques to increase performance and functionality. I completely agree that using Java’s collection simplifies the development by allowing the components to focus on their roles. It is a great advantage of Java compared to languages likes C where the programmer needs to take care of managing the underlying data structure and memory.
Jikes RVM implemented its own threading because of lacking multithreading support in the previous century. However, chapter noted a reference for making an API for their thread usage supposedly allowing easy substitution of other threading techniques. Another successful open source project!!!
Our Pattern Language (OPL)
This paper is about parallel pattern language for parallel programming. Over all I like the paper as it gives overview of different parallel patterns but lacks details of any pattern.
The author organized the patterns into layered system. The layers in which the patterns are organized are:
• Architectural patterns
• Computational patterns
• Parallel algorithm strategy patterns
• Implementation strategy patterns
• Concurrent execution patterns
Author defined the full range of design patterns that programmers are likely to encounter when designing software for parallel platforms. he grouped patterns into a language to give conceptual framework view for the developers at each layer.
In near future I like to invest some time in exploring the co-ordination patterns as this parallel world make everything run independently and then co-ordination with others on to finish the tasks. Also security play bit more role than usual as different processor communicates with each other. So designing these items carefully are worthwhile.
The author organized the patterns into layered system. The layers in which the patterns are organized are:
• Architectural patterns
• Computational patterns
• Parallel algorithm strategy patterns
• Implementation strategy patterns
• Concurrent execution patterns
Author defined the full range of design patterns that programmers are likely to encounter when designing software for parallel platforms. he grouped patterns into a language to give conceptual framework view for the developers at each layer.
In near future I like to invest some time in exploring the co-ordination patterns as this parallel world make everything run independently and then co-ordination with others on to finish the tasks. Also security play bit more role than usual as different processor communicates with each other. So designing these items carefully are worthwhile.
Thursday, September 24, 2009
Adaptive Object-Model (AOM) Architecture Style
This is a bit long Paper, presents Adaptive Object-model (AOM), which can be thought of it as more flexible than conventional object-oriented design (OOD). Good examples are given and style is explained in details along with advantages and disadvantages.Very interesting concept for OO developers as i am one of them…
In AOM system, classes and their attributes and methods are represented as metadata and this model will be stored in database and system interprets and translates these models. So changing the application or class does not require changing the actual code but just the metadata. Changes to metadata are immediately interpreted and reflected in the running application and doesn’t need to deploy the code changes or make the system offline to release the new version. I think this is a very nice feature compared to conventional OOD systems.
I think this architectural style works great for system which needs flexibility and runtime configuration. I never work on this type model but definitely like to keep it in mind for future, but it was very cool to see the system be automatically changed in production whenever there was a change in the metadata.
It was mentioned in the paper that these type of projects are hard to understand and maintain not completely sure why can’t they be easily understood. Prof. Johnson may reveal the background in the evening class.
In AOM system, classes and their attributes and methods are represented as metadata and this model will be stored in database and system interprets and translates these models. So changing the application or class does not require changing the actual code but just the metadata. Changes to metadata are immediately interpreted and reflected in the running application and doesn’t need to deploy the code changes or make the system offline to release the new version. I think this is a very nice feature compared to conventional OOD systems.
I think this architectural style works great for system which needs flexibility and runtime configuration. I never work on this type model but definitely like to keep it in mind for future, but it was very cool to see the system be automatically changed in production whenever there was a change in the metadata.
It was mentioned in the paper that these type of projects are hard to understand and maintain not completely sure why can’t they be easily understood. Prof. Johnson may reveal the background in the evening class.
Tuesday, September 22, 2009
BA Ch8 : Guardian - A fault-tolerant System
Guardian was the Tandem’s OS, used in the 1970’s. It tried to be fault-tolerant, selling itself as a very reliable system. The core idea was that everything should be duplicated in case one goes down. The T/16 machines had at least two processors, two buses, (often) two disks, etc.
Each process would be duplicated on two processors. On one processor it would be active and on the other it would be passive waiting for the first one to die or give up control. In the reliability world there are basically three ways to recover in the face of failure - check pointing or job replication, or to attempt to repair the state of the execution. For the Guardian they chose to do application-controlled check pointing to allow for recovery. As such each program would be responsible for check pointing its state at various intervals and if a processor goes down the other one would start from the last checkpoint.
In my opinion, Fault-tolerant software is something really hard to achieve but trying to achieve the fault tolerant software is highly desirable in some important application like airplane apps or military apps etc…I don’t have any experience in this area but I like reading this chapter and its interesting to see how they focused on fault-tolerance parameter more than other parameters. I think they did good as this system is developed in 70’s.
Each process would be duplicated on two processors. On one processor it would be active and on the other it would be passive waiting for the first one to die or give up control. In the reliability world there are basically three ways to recover in the face of failure - check pointing or job replication, or to attempt to repair the state of the execution. For the Guardian they chose to do application-controlled check pointing to allow for recovery. As such each program would be responsible for check pointing its state at various intervals and if a processor goes down the other one would start from the last checkpoint.
In my opinion, Fault-tolerant software is something really hard to achieve but trying to achieve the fault tolerant software is highly desirable in some important application like airplane apps or military apps etc…I don’t have any experience in this area but I like reading this chapter and its interesting to see how they focused on fault-tolerance parameter more than other parameters. I think they did good as this system is developed in 70’s.
Big Ball of Mud
This paper definitely is the most interesting of the papers I have read so far in this class which described real world situations of the software field and also seems like very straight talk on how they emerged and what we can do about it. I like reading it and also it has nice relevant pictures with each main topic.
Software field has the notion of architecture is luxury or Architecture is a long-term concern? Can a building construction be started without blue prints of the architecture of the building? Can a person who just knows how to put walls together can start building a house without having the architecture of the house in hand? I am guessing the root cause for this style of thinking in software field is due to ignoring this is also engineering.
Big Ball of Mud - big, ugly systems emerge from throw-away prototypes and quick-and-dirty code that was intended to be used only once and then discarded. However, such code often takes on a life of its own, despite casual structure and poor or non-existent documentation. It works, so why fix it?
One of mud's most effective enemies is sunshine. Subjecting convoluted code to scrutiny can set the stage for its refactoring, repair, and rehabilitation. Code reviews are one mechanism one can use to expose code to daylight.
Throw away code – created for immediate fix for a small problem, or a quick prototype or proof of concept but emerges into actual project. I like the examples presented to show most of us include our experiments in the actual code.
When you build a prototype, there is always the risk that someone will say "that's good enough, ship it". One way to minimize the risk of a prototype being put into production is to write the prototype in using a language or tool that you couldn't possibly use for a production version of your product.
Piecemeal Growth - Master plans are often rigid, misguided and out of date. Users’ needs change with time. Incrementally address forces that encourage change and growth. Allow opportunities for growth to be exploited locally, as they occur refactor unrelentingly.
Keep it working – Maintenance needs have accumulated, but an overhaul is unwise, since you might break the system. Therefore, do what it takes to maintain the software and keep it going. Keep it working.
Layers - Different artifacts change at different rates. Therefore, factor your system so that artifacts that change at similar rates are together.
Sweeping it under the rug - Overgrown, tangled, haphazard spaghetti code is hard to comprehend, repair, or extend, and tends to grow even worse if it is not somehow brought under control. Therefore, if you can’t easily make a mess go away, at least cordon it off. This restricts the disorder to a fixed area, keeps it out of sight, and can set the stage for additional refactoring.
Reconstruction - Your code has declined to the point where it is beyond repair, or even comprehension. Therefore, throw it away and start over.
I like this from the paper –
Kent Beck has observed that the way to build software is to: Make it work. Make it right. Make it fast [Beck 1997]. "Make it work" means that we should focus on functionality up-front, and get something running. "Make it right" means that we should concern ourselves with how to structure the system only after we’ve figured out the pieces we need to solve the problem in the first place. "Make it fast" means that we should be concerned about optimizing performance only after we’ve learned how to solve the problem, and after we’ve discerned an architecture to elegantly encompass this functionality. Once all this has been done, one can consider how to make it cheap
Software field has the notion of architecture is luxury or Architecture is a long-term concern? Can a building construction be started without blue prints of the architecture of the building? Can a person who just knows how to put walls together can start building a house without having the architecture of the house in hand? I am guessing the root cause for this style of thinking in software field is due to ignoring this is also engineering.
Big Ball of Mud - big, ugly systems emerge from throw-away prototypes and quick-and-dirty code that was intended to be used only once and then discarded. However, such code often takes on a life of its own, despite casual structure and poor or non-existent documentation. It works, so why fix it?
One of mud's most effective enemies is sunshine. Subjecting convoluted code to scrutiny can set the stage for its refactoring, repair, and rehabilitation. Code reviews are one mechanism one can use to expose code to daylight.
Throw away code – created for immediate fix for a small problem, or a quick prototype or proof of concept but emerges into actual project. I like the examples presented to show most of us include our experiments in the actual code.
When you build a prototype, there is always the risk that someone will say "that's good enough, ship it". One way to minimize the risk of a prototype being put into production is to write the prototype in using a language or tool that you couldn't possibly use for a production version of your product.
Piecemeal Growth - Master plans are often rigid, misguided and out of date. Users’ needs change with time. Incrementally address forces that encourage change and growth. Allow opportunities for growth to be exploited locally, as they occur refactor unrelentingly.
Keep it working – Maintenance needs have accumulated, but an overhaul is unwise, since you might break the system. Therefore, do what it takes to maintain the software and keep it going. Keep it working.
Layers - Different artifacts change at different rates. Therefore, factor your system so that artifacts that change at similar rates are together.
Sweeping it under the rug - Overgrown, tangled, haphazard spaghetti code is hard to comprehend, repair, or extend, and tends to grow even worse if it is not somehow brought under control. Therefore, if you can’t easily make a mess go away, at least cordon it off. This restricts the disorder to a fixed area, keeps it out of sight, and can set the stage for additional refactoring.
Reconstruction - Your code has declined to the point where it is beyond repair, or even comprehension. Therefore, throw it away and start over.
I like this from the paper –
Kent Beck has observed that the way to build software is to: Make it work. Make it right. Make it fast [Beck 1997]. "Make it work" means that we should focus on functionality up-front, and get something running. "Make it right" means that we should concern ourselves with how to structure the system only after we’ve figured out the pieces we need to solve the problem in the first place. "Make it fast" means that we should be concerned about optimizing performance only after we’ve learned how to solve the problem, and after we’ve discerned an architecture to elegantly encompass this functionality. Once all this has been done, one can consider how to make it cheap
Big Ball of Mud
This paper definitely is the most interesting of the papers I have read so far in this class which described real world situations of the software field and also seems like very straight talk on how they emerged and what we can do about it. I like reading it and also it has nice relevant pictures with each main topic.
Software field has the notion of architecture is luxury or Architecture is a long-term concern? Can a building construction be started without blue prints of the architecture of the building? Can a person who just knows how to put walls together can start building a house without having the architecture of the house in hand? I am guessing the root cause for this style of thinking in software field is due to ignoring this is also engineering.
Big Ball of Mud - big, ugly systems emerge from throw-away prototypes and quick-and-dirty code that was intended to be used only once and then discarded. However, such code often takes on a life of its own, despite casual structure and poor or non-existent documentation. It works, so why fix it?
One of mud's most effective enemies is sunshine. Subjecting convoluted code to scrutiny can set the stage for its refactoring, repair, and rehabilitation. Code reviews are one mechanism one can use to expose code to daylight.
Throw away code – created for immediate fix for a small problem, or a quick prototype or proof of concept but emerges into actual project. I like the examples presented to show most of us include our experiments in the actual code.
When you build a prototype, there is always the risk that someone will say "that's good enough, ship it". One way to minimize the risk of a prototype being put into production is to write the prototype in using a language or tool that you couldn't possibly use for a production version of your product.
Piecemeal Growth - Master plans are often rigid, misguided and out of date. Users’ needs change with time. Incrementally address forces that encourage change and growth. Allow opportunities for growth to be exploited locally, as they occur refactor unrelentingly.
Keep it working – Maintenance needs have accumulated, but an overhaul is unwise, since you might break the system. Therefore, do what it takes to maintain the software and keep it going. Keep it working.
Layers - Different artifacts change at different rates. Therefore, factor your system so that artifacts that change at similar rates are together.
Sweeping it under the rug - Overgrown, tangled, haphazard spaghetti code is hard to comprehend, repair, or extend, and tends to grow even worse if it is not somehow brought under control. Therefore, if you can’t easily make a mess go away, at least cordon it off. This restricts the disorder to a fixed area, keeps it out of sight, and can set the stage for additional refactoring.
Reconstruction - Your code has declined to the point where it is beyond repair, or even comprehension. Therefore, throw it away and start over.
I like this from the paper –
Kent Beck has observed that the way to build software is to: Make it work. Make it right. Make it fast [Beck 1997]. "Make it work" means that we should focus on functionality up-front, and get something running. "Make it right" means that we should concern ourselves with how to structure the system only after we’ve figured out the pieces we need to solve the problem in the first place. "Make it fast" means that we should be concerned about optimizing performance only after we’ve learned how to solve the problem, and after we’ve discerned an architecture to elegantly encompass this functionality. Once all this has been done, one can consider how to make it cheap.
Software field has the notion of architecture is luxury or Architecture is a long-term concern? Can a building construction be started without blue prints of the architecture of the building? Can a person who just knows how to put walls together can start building a house without having the architecture of the house in hand? I am guessing the root cause for this style of thinking in software field is due to ignoring this is also engineering.
Big Ball of Mud - big, ugly systems emerge from throw-away prototypes and quick-and-dirty code that was intended to be used only once and then discarded. However, such code often takes on a life of its own, despite casual structure and poor or non-existent documentation. It works, so why fix it?
One of mud's most effective enemies is sunshine. Subjecting convoluted code to scrutiny can set the stage for its refactoring, repair, and rehabilitation. Code reviews are one mechanism one can use to expose code to daylight.
Throw away code – created for immediate fix for a small problem, or a quick prototype or proof of concept but emerges into actual project. I like the examples presented to show most of us include our experiments in the actual code.
When you build a prototype, there is always the risk that someone will say "that's good enough, ship it". One way to minimize the risk of a prototype being put into production is to write the prototype in using a language or tool that you couldn't possibly use for a production version of your product.
Piecemeal Growth - Master plans are often rigid, misguided and out of date. Users’ needs change with time. Incrementally address forces that encourage change and growth. Allow opportunities for growth to be exploited locally, as they occur refactor unrelentingly.
Keep it working – Maintenance needs have accumulated, but an overhaul is unwise, since you might break the system. Therefore, do what it takes to maintain the software and keep it going. Keep it working.
Layers - Different artifacts change at different rates. Therefore, factor your system so that artifacts that change at similar rates are together.
Sweeping it under the rug - Overgrown, tangled, haphazard spaghetti code is hard to comprehend, repair, or extend, and tends to grow even worse if it is not somehow brought under control. Therefore, if you can’t easily make a mess go away, at least cordon it off. This restricts the disorder to a fixed area, keeps it out of sight, and can set the stage for additional refactoring.
Reconstruction - Your code has declined to the point where it is beyond repair, or even comprehension. Therefore, throw it away and start over.
I like this from the paper –
Kent Beck has observed that the way to build software is to: Make it work. Make it right. Make it fast [Beck 1997]. "Make it work" means that we should focus on functionality up-front, and get something running. "Make it right" means that we should concern ourselves with how to structure the system only after we’ve figured out the pieces we need to solve the problem in the first place. "Make it fast" means that we should be concerned about optimizing performance only after we’ve learned how to solve the problem, and after we’ve discerned an architecture to elegantly encompass this functionality. Once all this has been done, one can consider how to make it cheap.
Thursday, September 17, 2009
Layers
This architectural pattern is very well known pattern to me but reading this paper revealed new thoughts and information. From the paper:
The Layers pattern helps structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction
Developing applications in layers provides an advantage for allowing incremental coding and testing to occur without disturbing other protocols. When thinking about layering, you should consider the following forces:
• Late source code changes should not ripple through the system.
• Interfaces should be stable.
• Parts of the system should be exchangeable.
• Possibility of building other systems at a later date with the same as the system currently being designed.
• Similar responsibilities should be grouped to help understandability and maintainability.
• The system will be built by a team of programmers, and work has to be subdivided along clear boundaries.
Layers pattern is very useful and seems very natural to apply in development. As long as interfaces are stably defined, new layers can be inserted, removed, or combined as necessary. Layering done poorly often results in complications for maintainability, understandability and upgradability etc. One also need to be more carful about deciding how many layers are needed and how design them etc. which are given in this paper.
The Layers pattern helps structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction
Developing applications in layers provides an advantage for allowing incremental coding and testing to occur without disturbing other protocols. When thinking about layering, you should consider the following forces:
• Late source code changes should not ripple through the system.
• Interfaces should be stable.
• Parts of the system should be exchangeable.
• Possibility of building other systems at a later date with the same as the system currently being designed.
• Similar responsibilities should be grouped to help understandability and maintainability.
• The system will be built by a team of programmers, and work has to be subdivided along clear boundaries.
Layers pattern is very useful and seems very natural to apply in development. As long as interfaces are stably defined, new layers can be inserted, removed, or combined as necessary. Layering done poorly often results in complications for maintainability, understandability and upgradability etc. One also need to be more carful about deciding how many layers are needed and how design them etc. which are given in this paper.
BA 7: Xen and Beauty of Virtualization
This is another intresting chapter. I read considerable amount about the virtualization but never really developed or used technology. Xen is a virtualization platform that allows one PC or server to run multiple operating systems simultaneously. This allows the users to do things like running different operating systems from the same machine or to provide one operating system for each application. Since I never used this technology directly, I wonder how the hardware can cope up with software demands. My PC struggles to run cleverly, with single operating system. I can’t imagine hosting multiple on it. If I decided to have sophisticated system I wouldn’t dare to run multiple operating system on it and they may take me where I was with my old one… In work I have seen CPU and RAM spike up when I use 2 or 3 tools with local test server. So, if I decided to run each tool in different OS does that help me gain more CPU or Memory?
So for me virtualization is still virtual. I think, I have to use it to believe that there is certain advantage with respect to performance and be able to run different application on different operating system successfully.
I like the distrust concept that was decried in this chapter. when distrust is built into the architecture, it minimizes the number of trusted components, and this therefore provides security by default. As it virtualizes entire computer itself, any possible problem or attack is isolated within that virtualized computer while the system as a whole works perfectly normal except the problematic virtual computer. I am interested in knowing more of this. Probably, I will try to read more on it later..
Xen is a very good example of successful open source project. It started from a university student and it became a successful project which had great influence to the whole computer industry.
As I juggle between my duties as wife, mom, software engineer and a student……open source industry looks promising…. What I mean is that if I have a great idea there are people out there who can help achieve thoughts to software...
So for me virtualization is still virtual. I think, I have to use it to believe that there is certain advantage with respect to performance and be able to run different application on different operating system successfully.
I like the distrust concept that was decried in this chapter. when distrust is built into the architecture, it minimizes the number of trusted components, and this therefore provides security by default. As it virtualizes entire computer itself, any possible problem or attack is isolated within that virtualized computer while the system as a whole works perfectly normal except the problematic virtual computer. I am interested in knowing more of this. Probably, I will try to read more on it later..
Xen is a very good example of successful open source project. It started from a university student and it became a successful project which had great influence to the whole computer industry.
As I juggle between my duties as wife, mom, software engineer and a student……open source industry looks promising…. What I mean is that if I have a great idea there are people out there who can help achieve thoughts to software...
Tuesday, September 15, 2009
Pipes and Filters:
The Pipes and Filter Architectural Pattern: Divides the task of a system in to sequential processing steps and these are connected through by the data flow through the system – The output data of a one step is input to the subsequent step. Each processing step is implemented by filter component. A filter consumes and delivers the data incrementally (so it delivers output before consuming whole input). Each pipe implements the data flow between adjacent processing steps. Filter components are the processing units of the pipeline.
There two types of filters: passive and active. Passive filters can either have data pushed to them or have data pulled from them. Most commonly, active filters are in a loop pulling its data from and pushing it down the pipeline. An active filter will begin processing on its own as a separate program or thread.
The Pipes and filters pattern is very popular and simple. I think, it’s better to use passive filters when data available asynchronously and Active filters are good when data is available all the time for processing.
There two types of filters: passive and active. Passive filters can either have data pushed to them or have data pulled from them. Most commonly, active filters are in a loop pulling its data from and pushing it down the pipeline. An active filter will begin processing on its own as a separate program or thread.
The Pipes and filters pattern is very popular and simple. I think, it’s better to use passive filters when data available asynchronously and Active filters are good when data is available all the time for processing.
BA Chapter 6 : The Architecture of the Facebook Platform
Very nice chapter. Author chosen a good example application to illustrate how architecture can help to extend a simple social web site to a powerful platform with rich features. Each new change caused architects to change the system using even more powerful design decisions to add the features while keeping the fundamental requirements of data privacy and sites integrity.
This chapter has good amount of details about the Facebook system. It more seems like application design than applications architecture. Since I am also in web/ enterprise applications design and development, I am able to grasp and relate to the concepts but thought it maybe too much for those who are new to these items.
I like the key ides presented in this paper like how the web service hand shake make the data accessible with in the Facebook user’s notion of privacy, how it implemented the external data access pattern, FBML Architecture, how FBML can combine the social data and privacy business logic, FBJS to make app dynamic and yet limits the any violations that may occur if they use general java script.
Here are my answers –
How are social networking sites, like Facebook, helpful to other applications?
I like the comment from the Eric “he who controls the data controls the web” good summarization …. For this question. Other applications who need the data which is available in these social networking sites can help them to get it and use it for their needs.
How / why did Facebook open itself up to 3rd party applications?
Well, give a cent and take a cent saying goes well here I guess. Facebook API, which allowed 3rd party applications to make calls to the social data of a Facebook users. I am guessing, Facebook opening up for query based web services may have lead to more people in putting their own data to Facebook to begin…..
How did FQL help to optimize Facebook service calls?
FQL helped to optimize Facebook service calls by pushing some of the processing for client (who may have to make multiple calls to get various data for different stages of the processing) on to the Facebook servers
Why was FQL particularly of value to developers?
FQL is veryo valuable to developers because it is almost like other well known data query language SQL. So they can easily get data by querying to it.
How did FBML help shape the current environment of third party integration with Facebook?
More and more traffic to the site for sure and more and more outside applications will access the face book’s social data wealth.
Do you think FBJS is a fair compromise to javascript for developers of applications on the Facebook platform? Why or why not?
I believe FBJS is fair. It limits Javascript that may violate the rules of the face book and also make sure to present the developer provided content when it is safe.
What do you think architectures such as the Facebook Platform mean for the future of online computing?
I think, more business approach these social networks to get the data and use it to promote their product and for that they use online business to catch users eye through these sites…again so we see more online computing…
This chapter has good amount of details about the Facebook system. It more seems like application design than applications architecture. Since I am also in web/ enterprise applications design and development, I am able to grasp and relate to the concepts but thought it maybe too much for those who are new to these items.
I like the key ides presented in this paper like how the web service hand shake make the data accessible with in the Facebook user’s notion of privacy, how it implemented the external data access pattern, FBML Architecture, how FBML can combine the social data and privacy business logic, FBJS to make app dynamic and yet limits the any violations that may occur if they use general java script.
Here are my answers –
How are social networking sites, like Facebook, helpful to other applications?
I like the comment from the Eric “he who controls the data controls the web” good summarization …. For this question. Other applications who need the data which is available in these social networking sites can help them to get it and use it for their needs.
How / why did Facebook open itself up to 3rd party applications?
Well, give a cent and take a cent saying goes well here I guess. Facebook API, which allowed 3rd party applications to make calls to the social data of a Facebook users. I am guessing, Facebook opening up for query based web services may have lead to more people in putting their own data to Facebook to begin…..
How did FQL help to optimize Facebook service calls?
FQL helped to optimize Facebook service calls by pushing some of the processing for client (who may have to make multiple calls to get various data for different stages of the processing) on to the Facebook servers
Why was FQL particularly of value to developers?
FQL is veryo valuable to developers because it is almost like other well known data query language SQL. So they can easily get data by querying to it.
How did FBML help shape the current environment of third party integration with Facebook?
More and more traffic to the site for sure and more and more outside applications will access the face book’s social data wealth.
Do you think FBJS is a fair compromise to javascript for developers of applications on the Facebook platform? Why or why not?
I believe FBJS is fair. It limits Javascript that may violate the rules of the face book and also make sure to present the developer provided content when it is safe.
What do you think architectures such as the Facebook Platform mean for the future of online computing?
I think, more business approach these social networks to get the data and use it to promote their product and for that they use online business to catch users eye through these sites…again so we see more online computing…
Wednesday, September 9, 2009
Pattern Language: Excerpts from Christopher Alexander (A timeless way of building)
These 3 chapters are talking about the buildings and their construction process and not so directly related to software architecture or software building but they naturally convenes us that it is our nature to observe a pattern and apply it when ever we needed to achive what ever we are looking to achieve. These chapters are very interesting to read and were given with great but simple examples. Author explained an analogy of how a flower can't be made rather it is generated from a seed. Similarly, The quality in towns and buildings cannot be made but rather generated indirectly by the ordinary actions of the people. Later on, author explains how patterns allow people to build new buildings in unique workable way but resembles similarities in the basics in building structures. This chapter includes an example of how farmer build his barn using / following basic patterns like barn shape , size and how to divide the barn space etc.. (Very interesting)
I like this from book:
"A pattern languages gives each person who uses it, the power to create an infinite verity of new and unique buildings, just as his ordinary language gives him the power to create an infinite variety of sentences."
3rd chapter beginning talks about how natural it is a person to choose a best place to build something to utilize the existing benefits of that place. But this chapter gives some reasoning’s on how to choose and what to keep in mind while choosing it. Example it suggest to keep open the south side of the building to get more light in to the house and asks to build the house around the trees and not to destroy them as they take more time to grow again. This one solely talks about building layout needs and patterns to choose based on different conditions of the area. Example – if it is impossible to get lighting to both sides of the room then suggest having more windows on the side of the room where you get light so that reflection can fill the whole room.
So, based on above I am implying this for software building:
You can’t create a quality solution rather generate it by following patterns and applying them according to needs to achieve required functionality and still create it your own unique way. Make sense!!!! Right? One more thing, this also supports prof. Johnson’s saying “don’t reinvent the wheel but rather reuse it in your own unique way”
ArchJava
ArchJava: Connecting Software Architecture to Implementation by Jonathan Aldrich, Craig Chambers and David Notkin
ArchJava is described as a small, backwards-compatible extension to Java that integrates software architecture specifications into Java implementation code.
The communication integrity that is enforced by Archjava looks like presented to only one or few views of architecture. As we saw in 4+1 or any other architecture style, there are other views which are just as important. I am thinking it may not be a good idea to enforce one and not the others and it may introduce inconsistencies or at least allow them to go undetected.
Overall, I think this type tools may be useful to enforce the design with actual implementation of the application. But need to make sure that it can cover wide range of languages and tools. As industry uses lot of tools and languages to implement a single application(ex: enterprise web application may choose to use J2EE, EJB, Spring, Struts, JSPs, etc…) limitation presented in this paper like only applicable to programs written in a single language and running on a single JVM needs may not help much.
ArchJava is described as a small, backwards-compatible extension to Java that integrates software architecture specifications into Java implementation code.
The communication integrity that is enforced by Archjava looks like presented to only one or few views of architecture. As we saw in 4+1 or any other architecture style, there are other views which are just as important. I am thinking it may not be a good idea to enforce one and not the others and it may introduce inconsistencies or at least allow them to go undetected.
Overall, I think this type tools may be useful to enforce the design with actual implementation of the application. But need to make sure that it can cover wide range of languages and tools. As industry uses lot of tools and languages to implement a single application(ex: enterprise web application may choose to use J2EE, EJB, Spring, Struts, JSPs, etc…) limitation presented in this paper like only applicable to programs written in a single language and running on a single JVM needs may not help much.
Sunday, September 6, 2009
Architectural Blueprints – The 4+1 Views:
Beginning of this paper reminded me of MVC (Model-View-Controller) architecture style. At the end of reading this paper I am convinced that this architecture model can work well for big projects and may not be worth of including this much over head for small / medium size projects.
Here is the brief of this architecture –
Software architecture model proposed in this paper is made up of five main views
- The logical view, which is the object model of the design.
- The process view, which captures the concurrency and synchronization aspects of the design.
- The physical view, which describes the mapping(s) of the software onto the hardware and reflects its distributed aspect.
- The development view, which describes the static organization of the software in its development environment.
- The description of an architecture—the decisions made—can be organized around these four views, and then illustrated by a few selected use cases, or scenarios which become a fifth view.
I like the fact that it is focusing on key elements and key users
- End-user –Functionality
- Programmers - Software management
- System engineers – Topology - Communications
- Integrators – Performance – Scalability
It is interesting to see these views developed. I tried to look back and see how the initial design of Design Town’s architecture views are (pretty interesting, try it out). I think, experience may be required to fully apply the “4+1” strategies in a project.
Beautiful Architecture - First 4 Chapters
I am new to blogging, so I thought I would wait for a week to watch and learn and also do little experiment of seeing how much I can learn just by reading all your blogs. So I did. I was able to grasp first 4 chapters of Beautiful Architecture (by Diomidis Spinellis & Georgios Gousios) by just reading your blogs. I started reading actual book this week. Here is my take on it –
Introduction of the Beautiful Architecture:
This book is compilation of papers written by other authors but each of these chapters has nice co-ordination with others. This book describes different architectures like Enterprise Application Architecture, Resource – Oriented Architecture, End-User Application Architectures etc. Looks like this is a good book suggestion to software Architects who like to read! (I will give my full review at the end of this semesterJ)
Chapter 1: What is Architecture
What is Architecture? Well, definition may depend on what field are we talking about. But besides the any differences, there are many items that are common among the different disciplines. Particularly, architecture can help build the system that meets the needs of its stakeholders, and it can help to manage the complexity of system that needs to be build, planning, building, and maintaining the system. Architecture helps to assure that the building, bridge, or system has the desired properties and behaviors, when it has been built.
Architecture helps teams to focus on functional and non-functional requirements and keeps all on the same page with respect to the system’s building and provides a conceptual integrity of the system.
Principles gathered from “Foreword” by Stephen J. Mellor –
These are universal principles which make an architect beautiful.
One fact in one place: avoid duplicity; common functionality should be factored out into separated modules. Be aware of changes.
Automatic propagation: maintain consistency and correctness; propagation must be carried out automatically at construction time.
Architecture includes construction: architecture must include not only the runtime system but also how it is constructed.
Minimize mechanisms: less code to write, verify, maintain and occupy memory.
Construct engines: extensible systems rely on the construction of engines that are “programmed” by data provided by higher layers and that implement multiple application functions at a time.
O(G), the order of growth: consider the direction of likely growth and account for it.
Resist entropy: beautiful architecture are preserved over time. Changes will be consistent with it and not increase system entropy.
Whenever we are evaluating or designing architecture we should consider these principles to tell if the architecture in question is beautiful or not.
Chapter 2: A Tale of 2 systems
Author presents 2 software systems like a city. One is called Messy Metropolis which is not build based on any structure or order as name says very messy one. Other one is called design town which is structured very carefully.
I feel like this chapter showed extremes of both good and bad systems. But none the less, I also have seen similar to messy metropolis style and design town style. In my view, A system will end up as a Messy metropolis style if it is build to save the money or to meet aggressive dead line or let novice developers develop the system (believe or not , these days, In a software development teams software engineers are out numbered to others). There is this other category where legacy systems started long back as small project and with those old software platforms, but have grown over the years into messy systems. I agree with the author that it was very brave for the organization to take the step of rewriting the application.
Design town system shows how little efforts of planning and foreseeing the system in the long run help to build a beautiful system. The author mentioned great points to consider for making a good architecture. This is very important and useful when building a new system.
Chapter 3: Architecting for Scale
So far in my career, I mostly developed enterprise applications, this chapter is very interesting one for me. It talks about flexibility in scaling the system according to current and future needs. Nice reading of the chapter, find few contradiction with respect to Latency but can’t really comment on it. Gaming is not my schedule in near or far future…
Chapter 4: Making Memories
This chapter talks about the architecture used for photography labs, where pictures are taken in a studio, enhanced and ordered at the studio. They are then sent to a processing center where they are rendered and printed, then sent back to the studio for pickup by the customer.
In designing the new software, the architects solved many problems, including concurrency issues at the studios, compiling the software, making the GUI easy to use and making the most use of the bottleneck - the rendering pipeline. They also recognized the need to make everything easy to upgrade since there are hundreds of distributed sites.
Most of the ideas presented in this chapter like incremental design, code reviews, unit testing etc. seems to be very common to me but reminded me to keep learning them and applying them while I develop applications.
Introduction of the Beautiful Architecture:
This book is compilation of papers written by other authors but each of these chapters has nice co-ordination with others. This book describes different architectures like Enterprise Application Architecture, Resource – Oriented Architecture, End-User Application Architectures etc. Looks like this is a good book suggestion to software Architects who like to read! (I will give my full review at the end of this semesterJ)
Chapter 1: What is Architecture
What is Architecture? Well, definition may depend on what field are we talking about. But besides the any differences, there are many items that are common among the different disciplines. Particularly, architecture can help build the system that meets the needs of its stakeholders, and it can help to manage the complexity of system that needs to be build, planning, building, and maintaining the system. Architecture helps to assure that the building, bridge, or system has the desired properties and behaviors, when it has been built.
Architecture helps teams to focus on functional and non-functional requirements and keeps all on the same page with respect to the system’s building and provides a conceptual integrity of the system.
Principles gathered from “Foreword” by Stephen J. Mellor –
These are universal principles which make an architect beautiful.
One fact in one place: avoid duplicity; common functionality should be factored out into separated modules. Be aware of changes.
Automatic propagation: maintain consistency and correctness; propagation must be carried out automatically at construction time.
Architecture includes construction: architecture must include not only the runtime system but also how it is constructed.
Minimize mechanisms: less code to write, verify, maintain and occupy memory.
Construct engines: extensible systems rely on the construction of engines that are “programmed” by data provided by higher layers and that implement multiple application functions at a time.
O(G), the order of growth: consider the direction of likely growth and account for it.
Resist entropy: beautiful architecture are preserved over time. Changes will be consistent with it and not increase system entropy.
Whenever we are evaluating or designing architecture we should consider these principles to tell if the architecture in question is beautiful or not.
Chapter 2: A Tale of 2 systems
Author presents 2 software systems like a city. One is called Messy Metropolis which is not build based on any structure or order as name says very messy one. Other one is called design town which is structured very carefully.
I feel like this chapter showed extremes of both good and bad systems. But none the less, I also have seen similar to messy metropolis style and design town style. In my view, A system will end up as a Messy metropolis style if it is build to save the money or to meet aggressive dead line or let novice developers develop the system (believe or not , these days, In a software development teams software engineers are out numbered to others). There is this other category where legacy systems started long back as small project and with those old software platforms, but have grown over the years into messy systems. I agree with the author that it was very brave for the organization to take the step of rewriting the application.
Design town system shows how little efforts of planning and foreseeing the system in the long run help to build a beautiful system. The author mentioned great points to consider for making a good architecture. This is very important and useful when building a new system.
Chapter 3: Architecting for Scale
So far in my career, I mostly developed enterprise applications, this chapter is very interesting one for me. It talks about flexibility in scaling the system according to current and future needs. Nice reading of the chapter, find few contradiction with respect to Latency but can’t really comment on it. Gaming is not my schedule in near or far future…
Chapter 4: Making Memories
This chapter talks about the architecture used for photography labs, where pictures are taken in a studio, enhanced and ordered at the studio. They are then sent to a processing center where they are rendered and printed, then sent back to the studio for pickup by the customer.
In designing the new software, the architects solved many problems, including concurrency issues at the studios, compiling the software, making the GUI easy to use and making the most use of the bottleneck - the rendering pipeline. They also recognized the need to make everything easy to upgrade since there are hundreds of distributed sites.
Most of the ideas presented in this chapter like incremental design, code reviews, unit testing etc. seems to be very common to me but reminded me to keep learning them and applying them while I develop applications.
Thursday, August 27, 2009
Tuesday, August 25, 2009
Subscribe to:
Posts (Atom)