Discovering the Top-Level System Diagram

Discovering the Top-Level System Diagram

Postby Cuchulainn » Thu Sep 20, 2007 10:16 pm

This is the most difficult part of the s/w process. Using OO at this stage is too fine-grained. That's why we have to go to the 70's.
User avatar
Cuchulainn
 
Posts: 669
Joined: Mon Dec 18, 2006 2:48 pm
Location: Amsterdam, the Netherlands

Postby Cuchulainn » Thu Sep 20, 2007 10:18 pm

Single Responsibility Principle (Cohesion)



http://en.wikipedia.org/wiki/Single_res ... _principle



In computer science, the single responsibility principle was introduced by Tom DeMarco in his book Structured Analysis and Systems Specification, Yourdon Press Computing Series, 1979. It states that every object should have a single responsibility, and that all its services should be narrowly aligned with that responsibility. The principle forms part of cohesion, a concept widely used in software development.



Last edited by Cuchulainn on Thu Sep 20, 2007 10:21 pm, edited 1 time in total.
User avatar
Cuchulainn
 
Posts: 669
Joined: Mon Dec 18, 2006 2:48 pm
Location: Amsterdam, the Netherlands

Postby Cuchulainn » Thu Sep 20, 2007 10:19 pm

The Parnas Decomposition Principle



http://sunnyday.mit.edu/16.355/parnas-criteria.html



We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. Since, in most cases, design decisions transcend time of execution, modules will not correspond to steps in the processing. To achieve an efficient implementation we must abandon the assumption that a module is one or more subroutines, and instead allow subroutines and programs to be assembled collections of code from various modules.



User avatar
Cuchulainn
 
Posts: 669
Joined: Mon Dec 18, 2006 2:48 pm
Location: Amsterdam, the Netherlands

Postby mabel » Wed Feb 02, 2011 3:01 pm

Mr. Cuchulainn,



You are right here. This is really most important point in a software process. Not only OO but few little things are also complicated and can create process in-correction. SRP itself creates many issues which requires to be resolved correctly.
mabel
 
Posts: 3
Joined: Fri Jan 28, 2011 10:57 am


Return to Design Patterns

Who is online

Users browsing this forum: No registered users and 1 guest

cron