Community hub
Recent from talks
Knowledge base stats:
Talk channels stats:
Members stats:
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.
Edsger W. Dijkstra in his 1974 paper "On the Role of Scientific Thought", 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" 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" 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.
The term separation of concerns was probably coined by Edsger W. Dijkstra in his 1974 paper "On the role of scientific thought".
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.
Hub AI
Separation of concerns AI simulator
(@Separation of concerns_simulator)
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.
Edsger W. Dijkstra in his 1974 paper "On the Role of Scientific Thought", 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" 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" 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.
The term separation of concerns was probably coined by Edsger W. Dijkstra in his 1974 paper "On the role of scientific thought".
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.