Separation of concerns: Difference between revisions

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
VisualWikitext
imported>OrinZ
m diagram removed (sorry, just the most offensively worthless diagram)
 
 
Line 1: Line 1:
{{Short description|Design principle for computer programming}}
{{Short description|Design principle for computer programming}}


In [[computer science]], '''separation of concerns''' (sometimes abbreviated as '''SoC''') is a design principle for separating a [[computer program]] into distinct sections. Each section addresses a separate ''[[concern (computer science)|concern]]'', a set of information that affects the code of a computer program. A concern can be as general as "the details of the hardware for an application", or as specific as "the name of which class to [[Instance (computer science)|instantiate]]". A program that embodies SoC well is called a [[modularity (programming)|modular]]<ref name=laplante>{{cite book|last=Laplante|first=Phillip|title=What Every Engineer Should Know About Software Engineering|year=2007|publisher=CRC Press|isbn=978-0-8493-7228-5|url=https://books.google.com/books?id=pFHYk0KWAEgC&q=%22separation+of+concerns%22&pg=PA85}}</ref> program. Modularity, and hence separation of concerns, is achieved by [[Encapsulation (computer science)|encapsulating]] information inside a section of code that has a well-defined interface. Encapsulation is a means of [[information hiding]].<ref name=mitchell>{{cite book|last=Mitchell|first=R. J.|title=Managing Complexity in Software Engineering|year=1990|publisher=IEE|isbn=0-86341-171-1|page=5|url=https://books.google.com/books?id=uXtHeZt8ZowC&q=%22separation+of+concerns%22&pg=PA5}}</ref> Layered designs or packaging by feature in information systems are another embodiment of separation of concerns (e.g., presentation layer, business logic layer, data access layer, persistence layer).<ref name=microsoft>{{cite book|title=Microsoft Application Architecture Guide|year=2009|publisher=Microsoft Press|isbn=978-0-7356-2710-9|url=https://books.google.com/books?id=D9on897Ep7AC&q=%22separation+of+concerns%22+%22layered+design%22&pg=PT54}}</ref>
In [[computer science]], '''separation of concerns''' ('''SoC''') is a software engineering principle that allows software engineers to deal with one aspect of a problem so that they can concentrate on each individually. Concerns can be separated in various ways. Separation of concerns in terms of time is the underlying motivation of software development lifecycle methods.<ref name=":0">{{Cite book |last=Ghezzi |first=Carlo |title=Fundamentals of software engineering |last2=Jazayeri |first2=Mehdi |last3=Mandrioli |first3=Dino |date=2003 |publisher=Prentice Hall |isbn=978-0-13-305699-0 |edition=2. ed., [Nachdr.] |location=Upper Saddle River, NJ}}</ref>


Separation of concerns results in more degrees of freedom for some aspect of the program's design, deployment, or usage. Common among these is increased freedom for simplification and maintenance of code. When concerns are well-separated, there are more opportunities for module upgrade, reuse, and independent development. Hiding the implementation details of modules behind an interface enables improving or modifying a single concern's section of code without having to know the details of other sections and without having to make corresponding changes to those other sections. Modules can also expose different versions of an interface, which increases the freedom to upgrade a complex system in piecemeal fashion without interim loss of functionality.<ref name="phdfrey">{{cite thesis|last=Frey|first=Tim|date=26 June 2013 |title=Hypermodelling - Next Level Software Engineering with Data Warehouses |url=https://wwwiti.cs.uni-magdeburg.de/iti_db/publikationen/ps/auto/phdFrey13.pdf|degree=PhD |location=Magdeburg |access-date=27 March 2025}}</ref>
[[Edsger W. Dijkstra]] in his 1974 paper ''"On the Role of Scientific Thought"'',<ref name=":1" /> coined the term ''separation of concerns'' in relation to software qualities such as '''correctness''' and '''efficiency'''.


Separation of concerns is a form of [[Abstraction_(computer_science)|abstraction]]. As with most abstractions, separating concerns means adding additional code interfaces, generally creating more code to be executed. The extra code can result in higher computation costs in some cases, but in other cases also can lead to reuse of more optimized code. So despite the many benefits of well-separated concerns, there may be an associated execution penalty.<ref name="phdfrey"/>
[[Carlo Ghezzi]] in his book "Fundamentals of software engineering"<ref name=":0" /> promotes Separation Of Concerns as the primary way to tackle the inherited complexity in software production.


== Implementation ==
[[Philippe Kruchten]] in his article "Architectural Blueprints—The “4+1” View Model of Software Architecture"<ref>{{Cite journal |last=Kruchten |first=P.B. |date=1995 |title=The 4+1 View Model of architecture |url=https://doi.org/10.1109/52.469759 |journal=IEEE Software |volume=12 |issue=6 |pages=42–50 |doi=10.1109/52.469759 |issn=0740-7459|arxiv=2006.04975 }}</ref> used a model composed of five main views to address large architectures, essentially this is a view-based separation of concerns, where each view focus on a different aspect of the architecture.
The mechanisms for modular or object-oriented programming that are provided by a [[programming language]] are mechanisms that allow developers to provide SoC.<ref name=richard>{{cite CiteSeerX |last=Painter|first=Robert Richard|title=Software Plans: Multi-Dimensional Fine-Grained Separation of Concerns| year=2006 |citeseerx = 10.1.1.110.9227}}</ref> For example, [[object-oriented programming]] languages such as [[C Sharp (programming language)|C#]], [[C++]], [[Delphi (programming language)|Delphi]], and [[Java (programming language)|Java]] can separate concerns into [[Object (computer science)|objects]], and architectural [[Design pattern (computer science)|design patterns]] like [[model–view–controller|MVC]] or [[model–view–presenter|MVP]] can [[separation of content and presentation|separate presentation and the data-processing (model) from content]]. [[Service-orientation|Service-oriented design]] can separate concerns into [[Service (Systems Architecture)|services]]. [[Procedural programming]] languages such as [[C (programming language)|C]] and [[Pascal (programming language)|Pascal]] can separate concerns into [[procedure (computer science)|procedure]]s or [[Subroutines|functions]]. [[Aspect-oriented programming]] languages can separate concerns into [[aspect (computer science)|aspects]] and [[Object (computer science)|objects]].


Separation of concerns is an important design principle in many other areas as well, such as [[urban planning]], [[architecture]] and [[information design]].<ref name=garofalo>{{cite book|last=Garofalo|first=Raffaele|title=Building Enterprise Applications with Windows Presentation Foundation and the Model View ViewModel Pattern|year=2011|publisher=Microsoft Press|isbn=978-0-7356-5092-3|page=18|url=https://books.google.com/books?id=6WJ5oQT0dcUC&q=%22separation+of+concerns%22+%22urban+planning%22&pg=PA18}}</ref> The goal is to more effectively understand, design, and manage complex interdependent systems, so that functions can be reused, optimized independently of other functions, and insulated from the potential failure of other functions.
According to [[Carlo Ghezzi]], the main benefit of software [[Modular programming|modularity]] is that it allows the application of the separation of concerns principle to system components, or "modules." Module details can be addressed in isolation; furthermore, module integration is treated as a separate concern that deals with the overall characteristics of software modules and their relationships.


Common examples include separating a space into rooms, so that activity in one room does not affect people in other rooms, and keeping the stove on one circuit and the lights on another, so that overload by the stove does not turn the lights off. The example with rooms shows encapsulation, where information inside one room, such as how messy it is, is not available to the other rooms, except through the interface, which is the door. The example with circuits demonstrates that activity inside one module, which is a circuit with consumers of electricity attached, does not affect activity in a different module, so each module is not concerned with what happens in the other.
Laplante, Phillip also mentioned that separation of concerns can be applied in software design, coding, time, and software qualities.<ref name="laplante">{{cite book |last=Laplante |first=Phillip |url=https://books.google.com/books?id=pFHYk0KWAEgC&q=%22separation+of+concerns%22&pg=PA85 |title=What Every Engineer Should Know About Software Engineering |publisher=CRC Press |year=2007 |isbn=978-0-8493-7228-5}}</ref>
 
The ''[[Independent Variation Principle]]'' (IVP), an actionable 2025 formalization of separation of concerns for software design, expresses this as: "separate elements that vary independently; unify elements that vary dependently."<ref>{{cite journal |last=Loth |first=Yannick |year=2025 |title=The Independent Variation Principle: A Unifying Meta-Principle for Software Architecture |url=https://doi.org/10.5281/zenodo.17677316 |doi=10.5281/zenodo.17677316 |publisher=Zenodo}}</ref> When applying the IVP to a system, [[Edsger W. Dijkstra]]'s ''aspect'', or ''concern'', which should be studied in isolation, is all the knowledge which is subject to a single change driver (equivalent to [[Robert Cecil Martin]]'s "reason to change" in the [[SOLID#Single responsibility principle|Single responsibility principle]] and [[Package Architecture#Common Closure Principle|Common Closure Principle]]) and which is relevant to implement the system's functionality and qualities (non-functional requirements). The IVP operationalizes [[Carlo Ghezzi]]'s conclusion on modules by providing clear guidance to define causal module boundaries aligned with the organisation's decisional structure.


== Origin ==
== Origin ==
The term ''separation of concerns'' was probably coined by [[Edsger W. Dijkstra]] in his 1974 paper "On the role of scientific thought".<ref>{{Cite book | last = Dijkstra | first = Edsger W | author-link = Edsger W. Dijkstra | contribution = On the role of scientific thought | contribution-url = https://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html | title = Selected writings on Computing: A Personal Perspective | year = 1982 | pages = [https://archive.org/details/selectedwritings0000dijk/page/60 60–66] | publisher = Springer-Verlag | place = New York, NY, US | isbn = 0-387-90652-5 | url = https://archive.org/details/selectedwritings0000dijk/page/60 }}</ref>
The term ''separation of concerns'' was probably coined by [[Edsger W. Dijkstra]] in his 1974 paper "On the role of scientific thought".<ref name=":1">{{Cite book | last = Dijkstra | first = Edsger W | author-link = Edsger W. Dijkstra | contribution = On the role of scientific thought | contribution-url = https://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html | title = Selected writings on Computing: A Personal Perspective | year = 1982 | pages = [https://archive.org/details/selectedwritings0000dijk/page/60 60–66] | publisher = Springer-Verlag | place = New York, NY, US | isbn = 0-387-90652-5 | url = https://archive.org/details/selectedwritings0000dijk/page/60 }}</ref>
{{quote |Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained—on the contrary!—by tackling these various aspects simultaneously. It is what I sometimes have called "the separation of concerns", which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by "focusing one's attention upon some aspect": it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.}}
{{blockquote |Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained—on the contrary!—by tackling these various aspects simultaneously. It is what I sometimes have called "the separation of concerns", which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by "focusing one's attention upon some aspect": it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.}}


Fifteen years later, it was evident the term {{em|separation of concerns}} was becoming an accepted idea. In 1989, Chris Reade wrote a book titled ''Elements of Functional Programming''<ref>{{cite book | last = Reade | first = Chris | author-link = Chris Reade | title = Elements of Functional Programming | publisher = Addison-Wesley Longman | year = 1989 | location = Boston, MA, US | isbn = 0-201-12915-9 | url-access = registration | url = https://archive.org/details/elementsoffuncti00read }}</ref> that describes separation of concerns:
Fifteen years later, it was evident the term {{em|separation of concerns}} was becoming an accepted idea. In 1989, Chris Reade wrote a book titled ''Elements of Functional Programming''<ref>{{cite book | last = Reade | first = Chris | author-link = Chris Reade | title = Elements of Functional Programming | publisher = Addison-Wesley Longman | year = 1989 | location = Boston, MA, US | isbn = 0-201-12915-9 | url-access = registration | url = https://archive.org/details/elementsoffuncti00read }}</ref> that describes SoC:
{{quote |The programmer is having to do several things at the same time, namely,
{{blockquote |The programmer is having to do several things at the same time, namely,
# describe what is to be computed;
# describe what is to be computed;
# organise the computation sequencing into small steps;
# organise the computation sequencing into small steps;
# organise memory management during the computation.}}
# organise memory management during the computation.}}
Reade continues to say,
Reade continues to say,
{{quote |Ideally, the programmer should be able to concentrate on the first of the three tasks (describing what is to be computed) without being distracted by the other two, more administrative, tasks. Clearly, administration is important, but by separating it from the main task we are likely to get more reliable results and we can ease the programming problem by automating much of the administration.
{{blockquote |Ideally, the programmer should be able to concentrate on the first of the three tasks (describing what is to be computed) without being distracted by the other two, more administrative, tasks. Clearly, administration is important, but by separating it from the main task we are likely to get more reliable results and we can ease the programming problem by automating much of the administration.


The separation of concerns has other advantages as well. For example, program proving becomes much more feasible when details of sequencing and memory management are absent from the program. Furthermore, descriptions of what is to be computed should be free of such detailed step-by-step descriptions of how to do it, if they are to be evaluated with different machine architectures. Sequences of small changes to a data object held in a store may be an inappropriate description of how to compute something when a highly parallel machine is being used with thousands of processors distributed throughout the machine and local rather than global storage facilities.
SoC has other advantages. For example, program proving becomes much more feasible when details of sequencing and memory management are absent from the program. Furthermore, descriptions of what is to be computed should be free of such detailed step-by-step descriptions of how to do it, if they are to be evaluated with different machine architectures. Sequences of small changes to a data object held in a store may be an inappropriate description of how to compute something when a highly parallel machine is being used with thousands of processors distributed throughout the machine and local rather than global storage facilities.


Automating the administrative aspects means that the language implementor has to deal with them, but he/she has far more opportunity to make use of very different computation mechanisms with different machine architectures.}}
Automating the administrative aspects means that the language implementor has to deal with them, but he/she has far more opportunity to make use of very different computation mechanisms with different machine architectures.}}
Line 33: Line 34:


=== Internet protocol stack ===
=== Internet protocol stack ===
Separation of concerns is crucial to the design of the Internet. In the [[Internet protocol suite]], great efforts have been made to separate concerns into well-defined [[OSI model|layers]]. This allows protocol designers to focus on the concerns in one layer, and ignore the other layers. The Application Layer protocol [[Simple Mail Transfer Protocol|SMTP]], for example, is concerned about all the details of conducting an email session over a reliable transport service (usually [[Transmission Control Protocol|TCP]]), but not in the least concerned about how the transport service makes that service reliable. Similarly, TCP is not concerned about the routing of data packets, which is handled at the [[Internet layer]].
SoC is crucial to the design of the Internet. In the [[Internet protocol suite]], great efforts have been made to separate concerns into well-defined [[OSI model|layers]]. This allows protocol designers to focus on the concerns in one layer, and ignore the other layers. The Application Layer protocol [[Simple Mail Transfer Protocol|SMTP]], for example, is concerned about all the details of conducting an email session over a reliable transport service (usually [[Transmission Control Protocol|TCP]]), but not in the least concerned about how the transport service makes that service reliable. Similarly, TCP is not concerned about the routing of data packets, which is handled at the [[Internet layer]].


=== HTML, CSS, JavaScript ===
=== HTML, CSS, JavaScript ===
Line 39: Line 40:


=== Subject-oriented programming ===
=== Subject-oriented programming ===
[[Subject-oriented programming]] allows separate concerns to be addressed as separate software constructs, each on an equal footing with the others. Each concern provides its own class-structure into which the objects in common are organized, and contributes state and methods to the composite result where they cut across one another. Correspondence rules describe how the classes and methods in the various concerns are related to each other at points where they interact, allowing composite behavior for a method to be derived from several concerns. [[Subject-oriented programming#Multi-dimensional separation of concerns|Multi-dimensional separation of concerns]] allows the analysis and composition of concerns to be manipulated as a multi-dimensional "matrix" in which each concern provides a dimension in which different points of choice are enumerated, with the cells of the matrix occupied by the appropriate software artifacts.
[[Subject-oriented programming]] allows separate concerns to be addressed as separate software constructs, each on an equal footing with the others. Each concern provides its own class-structure into which the objects in common are organized, and contributes state and methods to the composite result where they cut across one another. Correspondence rules describe how the classes and methods in the various concerns are related to each other at points where they interact, allowing composite behavior for a method to be derived from several concerns. [[Subject-oriented programming#Multi-dimensional separation of concerns|Multi-dimensional SoC]] allows the analysis and composition of concerns to be manipulated as a multi-dimensional "matrix" in which each concern provides a dimension in which different points of choice are enumerated, with the cells of the matrix occupied by the appropriate software artifacts.


=== Aspect-oriented programming ===
=== Aspect-oriented programming ===
Line 53: Line 54:


=== Levels of analysis in artificial intelligence ===
=== Levels of analysis in artificial intelligence ===
In [[cognitive science]] and [[artificial intelligence]], it is common to refer to David Marr's [[David Marr (neuroscientist)#Levels_of_analysis|levels of analysis]]. At any given time, a researcher may be focusing on (1) what some aspect of intelligence needs to compute, (2) what algorithm it employs, or (3) how that algorithm is implemented in hardware. This separation of concerns is similar to the [[interface (computing)|interface]]/implementation distinction in software and hardware engineering.
In [[cognitive science]] and [[artificial intelligence]], it is common to refer to David Marr's [[David Marr (neuroscientist)#Levels of analysis|levels of analysis]]. At any given time, a researcher may be focusing on what some aspect of intelligence needs to compute, what algorithm it employs, or how that algorithm is implemented in hardware. This separation of concerns is similar to the interface/implementation distinction in software and hardware engineering.
 
=== Normalized systems ===
 
In [[normalized system]]s separation of concerns is one of the four guiding principles. Adhering to this principle is one of the tools that helps reduce the combinatorial effects that, over time, get introduced in software that is being maintained. In normalized systems separation of concerns is actively supported by the tools.
 
=== SoC via partial classes ===
Separation of concerns can be implemented and enforced via [[partial class]]es.<ref>
{{cite web
| url=http://ptsoft.net/tdd/papers/TDIAS06_HyperNet__MDSOC_support_for_NET.pdf
|title=Hyper/Net: MDSoC Support for .NET
| author=Tiago Dias
| date=October 2006
| access-date=2007-09-25
| work=DSOA 2006
}}
</ref>
 
==== SoC via partial classes in Ruby ====
;bear_hunting.rb
<syntaxhighlight lang="ruby">
class Bear
  def hunt
    forest.select(&:food?)
  end
end
</syntaxhighlight>
;bear_eating.rb
<syntaxhighlight lang="ruby">
class Bear
  def eat(food)
    raise "#{food} is not edible!" unless food.respond_to? :nutrition_value
    food.nutrition_value
  end
end
</syntaxhighlight>
;bear_hunger.rb
<syntaxhighlight lang="ruby">
class Bear
  attr_accessor :hunger
  def monitor_hunger
    if hunger > 50
      food = hunt
      hunger -= eat(food)
    end
  end
end
</syntaxhighlight>


== See also ==
== See also ==
Line 122: Line 76:
* [http://trese.cs.utwente.nl/taosad/separation_of_concerns.htm TAOSAD] {{Webarchive|url=https://web.archive.org/web/20161219013600/http://trese.cs.utwente.nl/taosad/separation_of_concerns.htm |date=2016-12-19 }}
* [http://trese.cs.utwente.nl/taosad/separation_of_concerns.htm TAOSAD] {{Webarchive|url=https://web.archive.org/web/20161219013600/http://trese.cs.utwente.nl/taosad/separation_of_concerns.htm |date=2016-12-19 }}
* [http://www.comp.lancs.ac.uk/computing/users/marash/aopws2001/ Tutorial and Workshop on Aspect-Oriented Programming and Separation of Concerns] {{Webarchive|url=https://web.archive.org/web/20080516050058/http://www.comp.lancs.ac.uk/computing/users/marash/aopws2001/ |date=2008-05-16 }}
* [http://www.comp.lancs.ac.uk/computing/users/marash/aopws2001/ Tutorial and Workshop on Aspect-Oriented Programming and Separation of Concerns] {{Webarchive|url=https://web.archive.org/web/20080516050058/http://www.comp.lancs.ac.uk/computing/users/marash/aopws2001/ |date=2008-05-16 }}
{{Programming paradigms navbox}}


[[Category:Programming principles]]
[[Category:Programming principles]]
[[Category:Reductionism]]
[[Category:Reductionism]]

Latest revision as of 01:45, 1 January 2026

Template:Short description

In computer science, separation of concerns (SoC) is a software engineering principle that allows software engineers to deal with one aspect of a problem so that they can concentrate on each individually. Concerns can be separated in various ways. Separation of concerns in terms of time is the underlying motivation of software development lifecycle methods.[1]

Edsger W. Dijkstra in his 1974 paper "On the Role of Scientific Thought",[2] coined the term separation of concerns in relation to software qualities such as correctness and efficiency.

Carlo Ghezzi in his book "Fundamentals of software engineering"[1] promotes Separation Of Concerns as the primary way to tackle the inherited complexity in software production.

Philippe Kruchten in his article "Architectural Blueprints—The “4+1” View Model of Software Architecture"[3] used a model composed of five main views to address large architectures, essentially this is a view-based separation of concerns, where each view focus on a different aspect of the architecture.

According to Carlo Ghezzi, the main benefit of software modularity is that it allows the application of the separation of concerns principle to system components, or "modules." Module details can be addressed in isolation; furthermore, module integration is treated as a separate concern that deals with the overall characteristics of software modules and their relationships.

Laplante, Phillip also mentioned that separation of concerns can be applied in software design, coding, time, and software qualities.[4]

The Independent Variation Principle (IVP), an actionable 2025 formalization of separation of concerns for software design, expresses this as: "separate elements that vary independently; unify elements that vary dependently."[5] When applying the IVP to a system, Edsger W. Dijkstra's aspect, or concern, which should be studied in isolation, is all the knowledge which is subject to a single change driver (equivalent to Robert Cecil Martin's "reason to change" in the Single responsibility principle and Common Closure Principle) and which is relevant to implement the system's functionality and qualities (non-functional requirements). The IVP operationalizes Carlo Ghezzi's conclusion on modules by providing clear guidance to define causal module boundaries aligned with the organisation's decisional structure.

Origin

The term separation of concerns was probably coined by Edsger W. Dijkstra in his 1974 paper "On the role of scientific thought".[2]

<templatestyles src="Template:Blockquote/styles.css" />

Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained—on the contrary!—by tackling these various aspects simultaneously. It is what I sometimes have called "the separation of concerns", which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by "focusing one's attention upon some aspect": it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.

Script error: No such module "Check for unknown parameters".

Fifteen years later, it was evident the term Template:Em was becoming an accepted idea. In 1989, Chris Reade wrote a book titled Elements of Functional Programming[6] that describes SoC:

<templatestyles src="Template:Blockquote/styles.css" />

The programmer is having to do several things at the same time, namely,

  1. describe what is to be computed;
  2. organise the computation sequencing into small steps;
  3. organise memory management during the computation.

Script error: No such module "Check for unknown parameters".

Reade continues to say,

<templatestyles src="Template:Blockquote/styles.css" />

Ideally, the programmer should be able to concentrate on the first of the three tasks (describing what is to be computed) without being distracted by the other two, more administrative, tasks. Clearly, administration is important, but by separating it from the main task we are likely to get more reliable results and we can ease the programming problem by automating much of the administration.

SoC has other advantages. For example, program proving becomes much more feasible when details of sequencing and memory management are absent from the program. Furthermore, descriptions of what is to be computed should be free of such detailed step-by-step descriptions of how to do it, if they are to be evaluated with different machine architectures. Sequences of small changes to a data object held in a store may be an inappropriate description of how to compute something when a highly parallel machine is being used with thousands of processors distributed throughout the machine and local rather than global storage facilities.

Automating the administrative aspects means that the language implementor has to deal with them, but he/she has far more opportunity to make use of very different computation mechanisms with different machine architectures.

Script error: No such module "Check for unknown parameters".

Examples

Internet protocol stack

SoC is crucial to the design of the Internet. In the Internet protocol suite, great efforts have been made to separate concerns into well-defined layers. This allows protocol designers to focus on the concerns in one layer, and ignore the other layers. The Application Layer protocol SMTP, for example, is concerned about all the details of conducting an email session over a reliable transport service (usually TCP), but not in the least concerned about how the transport service makes that service reliable. Similarly, TCP is not concerned about the routing of data packets, which is handled at the Internet layer.

HTML, CSS, JavaScript

HTML, CSS, and JavaScript are complementary languages used in the development of web pages and websites. HTML is mainly used for organization of webpage content, CSS is used for definition of content presentation style, and JavaScript defines how the content interacts and behaves with the user. Historically, this was not the case: prior to the introduction of CSS, HTML performed both duties of defining semantics and style.

Subject-oriented programming

Subject-oriented programming allows separate concerns to be addressed as separate software constructs, each on an equal footing with the others. Each concern provides its own class-structure into which the objects in common are organized, and contributes state and methods to the composite result where they cut across one another. Correspondence rules describe how the classes and methods in the various concerns are related to each other at points where they interact, allowing composite behavior for a method to be derived from several concerns. Multi-dimensional SoC allows the analysis and composition of concerns to be manipulated as a multi-dimensional "matrix" in which each concern provides a dimension in which different points of choice are enumerated, with the cells of the matrix occupied by the appropriate software artifacts.

Aspect-oriented programming

Aspect-oriented programming allows cross-cutting concerns to be addressed as primary concerns. For example, most programs require some form of security and logging. Security and logging are often secondary concerns, whereas the primary concern is often on accomplishing business goals. However, when designing a program, its security must be built into the design from the beginning instead of being treated as a secondary concern. Applying security afterwards often results in an insufficient security model that leaves too many gaps for future attacks. This may be solved with aspect-oriented programming. For example, an aspect may be written to enforce that calls to a certain API are always logged, or that errors are always logged when an exception is thrown, regardless of whether the program's procedural code handles the exception or propagates it.[7]

Levels of analysis in artificial intelligence

In cognitive science and artificial intelligence, it is common to refer to David Marr's levels of analysis. At any given time, a researcher may be focusing on what some aspect of intelligence needs to compute, what algorithm it employs, or how that algorithm is implemented in hardware. This separation of concerns is similar to the interface/implementation distinction in software and hardware engineering.

See also

<templatestyles src="Div col/styles.css"/>

Script error: No such module "Check for unknown parameters".

References

<templatestyles src="Reflist/styles.css" />

  1. ↑ a b Script error: No such module "citation/CS1".
  2. ↑ a b Script error: No such module "citation/CS1".
  3. ↑ Script error: No such module "Citation/CS1".
  4. ↑ Script error: No such module "citation/CS1".
  5. ↑ Script error: No such module "Citation/CS1".
  6. ↑ Script error: No such module "citation/CS1".
  7. ↑ Script error: No such module "citation/CS1".

Script error: No such module "Check for unknown parameters".

External links

Template:Programming paradigms navbox

Retrieved from "http://debianws.lexgopc.com/wiki143/index.php?title=Separation_of_concerns&oldid=4583672"