Separation of concerns
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">Template:Cite book</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.
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.
Philippe Kruchten in his article "Architectural Blueprints—The “4+1” View Model of Software Architecture"<ref>Template:Cite journal</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.
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.<ref name="laplante">Template:Cite book</ref>
Origin
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">Template:Cite book</ref> Template:Blockquote
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<ref>Template:Cite book</ref> that describes SoC: Template:Blockquote Reade continues to say, Template:Blockquote
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.<ref> Template:Cite web </ref>
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
- Abstraction principle (programming)
- Aspect-oriented software development
- Concern (computer science)
- Coupling (computer science)
- Holism
- Modular design
- Modular programming
- Template:Section link
- Single-responsibility principle