CSC/ECE 517 Fall 2007/wiki3 3 33: Difference between revisions
| Line 5: | Line 5: | ||
Separation of responsibility (abbreviated as SoR) is also known as seperation of concern (SoC. SoR and SoC will be used interchangably from this point on). In the field of software engineering, this concept probably finds its root in one paper from Dijsktra in the year 1974. Since then SoR became a well accepted concept that helps programmers in designing, implementing and many other aspects of software development. | Separation of responsibility (abbreviated as SoR) is also known as seperation of concern (SoC. SoR and SoC will be used interchangably from this point on). In the field of software engineering, this concept probably finds its root in one paper from Dijsktra in the year 1974. Since then SoR became a well accepted concept that helps programmers in designing, implementing and many other aspects of software development. | ||
The essence of the SoR concept is that one foucs on doing one thing and do it well, with out being entangled or distracted by other entity. | The essence of the SoR concept is that one foucs on doing one thing and do it well, with out being entangled or distracted by other entity. To elaborate, it is well known that developing a fully functional software in time and meet the needs of clients is challenging due to the intricate nature of the process. Often, software developing requires a group of team developers to cooperate on a project. By effectively seperate out non or minimally overlapped concerns (or tasks, even domains), developers are able to concentrate on just one part of the system, instead of having to worry about all other miniture details. In this way, the integrated system achieve the modulizing effect and is therefore more maintainable. In addition to the benifit of increased maintainability, SoR promotes program extensibility and flexibility. In field of software engineering, the needs of client are characterized by constant changing and modification. By separating an entire system into smaller, "independent" pieces, developers can add, update, delete these parts of the system without dramaticly affect the other parts. This makes modifying the program and adding more functionalities to it far more effecient and easier. Without having SoR, even one small change can trigger a cascading effect that spread to the entire system. Trying to figure out what is going wrong, in this case, will be a nightmare. | ||
To elaborate, it is well known that developing a fully functional software in time and meet the needs of clients is challenging due to the intricate nature of the process. Often, software developing requires a group of team developers to cooperate on a project. By effectively seperate out non or minimally overlapped concerns (or tasks, even domains), developers are able to concentrate on just one part of the system, instead of having to worry about all other miniture details. In this way, the integrated system achieve the modulizing effect and is therefore more maintainable. In addition to the benifit of increased maintainability, SoR promotes program extensibility and flexibility. In field of software engineering, the needs of client are characterized by constant changing and modification. By separating an entire system into smaller, "independent" pieces, developers can add, update, delete these parts of the system without | |||
==Related principles== | ==Related principles== | ||
Revision as of 16:38, 18 November 2007
Topic - Separation of Responsibility
Take the principle of Separation of Responsibility and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.'
Concepts
Separation of responsibility (abbreviated as SoR) is also known as seperation of concern (SoC. SoR and SoC will be used interchangably from this point on). In the field of software engineering, this concept probably finds its root in one paper from Dijsktra in the year 1974. Since then SoR became a well accepted concept that helps programmers in designing, implementing and many other aspects of software development.
The essence of the SoR concept is that one foucs on doing one thing and do it well, with out being entangled or distracted by other entity. To elaborate, it is well known that developing a fully functional software in time and meet the needs of clients is challenging due to the intricate nature of the process. Often, software developing requires a group of team developers to cooperate on a project. By effectively seperate out non or minimally overlapped concerns (or tasks, even domains), developers are able to concentrate on just one part of the system, instead of having to worry about all other miniture details. In this way, the integrated system achieve the modulizing effect and is therefore more maintainable. In addition to the benifit of increased maintainability, SoR promotes program extensibility and flexibility. In field of software engineering, the needs of client are characterized by constant changing and modification. By separating an entire system into smaller, "independent" pieces, developers can add, update, delete these parts of the system without dramaticly affect the other parts. This makes modifying the program and adding more functionalities to it far more effecient and easier. Without having SoR, even one small change can trigger a cascading effect that spread to the entire system. Trying to figure out what is going wrong, in this case, will be a nightmare.
Related principles
class level separation of responsibility
project/architecture level separation of responsibility
MVC
Aspect-oriented programming
References
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/MVC.htm
http://en.wikipedia.org/wiki/Separation_of_concerns