Comments on: Manage Relationships http://www.kirkk.com/modularity/2009/12/manage-relationships/ Patterns of Modular Architecture Mon, 24 May 2010 11:03:24 -0600 http://wordpress.org/?v=2.8.6 hourly 1 By: Pratik Das http://www.kirkk.com/modularity/2009/12/manage-relationships/comment-page-1/#comment-20 Pratik Das Tue, 11 May 2010 11:40:43 +0000 http://www.kirkk.com/modularity/?p=138#comment-20 While reading through the draft on "ManageRelationships – Design module relationships", I came across the following observations: 1. The concepts of module, component, subsystem and sometimes class seem to be interspersed. Will it not appropriate to clearly define these concepts beforehand? 2. Figure 1 could have been explained with more comments/legends on the diagram instead of the text. That would have made it easier to understand. Why not take help of lollypop style interfaces (UML 2.0) on the components to show provider and consumer interfaces. 3. After the text you can represent your guidelines/postulates in a table with various tradeoffs. Please look at this paragraph: "Defining component relationships also serves as a system of checks and balances against a system’s logical structure. When layering a system, it’s important that each layer has a clearly defined set of responsibilities. Layering components guarantees consistent responsibilities within each layer. Only importing those classes from dependent components ensures I’m well aware of the ramification of change. These relationships enforce architecture, and any new relationship created between two previously independent components should be given serious consideration." From component relationships suddenly the layering concept comes up. Why not discuss layering first followed by assigning components/responsibilities to the layers before discussing component relationships before taking a peek inside the components. These are few of my observations based on reading this draft alone. While reading through the draft on “ManageRelationships – Design module relationships”, I came across the following observations:
1. The concepts of module, component, subsystem and sometimes class seem to be interspersed. Will it not appropriate to clearly define these concepts beforehand?
2. Figure 1 could have been explained with more comments/legends on the diagram instead of the text. That would have made it easier to understand. Why not take help of lollypop style interfaces (UML 2.0) on the components to show provider and consumer interfaces.
3. After the text you can represent your guidelines/postulates in a table with various tradeoffs.

Please look at this paragraph:
“Defining component relationships also serves as a system of checks and balances against a system’s logical structure. When layering a system, it’s important that each layer has a clearly defined set of responsibilities. Layering components guarantees consistent responsibilities within each layer. Only importing those classes from dependent components ensures I’m well aware of the ramification of change. These relationships enforce architecture, and any new relationship created between two previously independent components should be given serious consideration.”

From component relationships suddenly the layering concept comes up. Why not discuss layering first followed by assigning components/responsibilities to the layers before discussing component relationships before taking a peek inside the components.

These are few of my observations based on reading this draft alone.

]]>