itSpice
Subscribe:       RSS    Twitter    EMail
 




Enter your email address:

Delivered by FeedBurner











Separation of concerns – An Architectural View

by Vijay Sasi

Separation of concerns is a concept in software engineering refers to identification and addressing the concerns of functional goals, components, integration, implementation, developer roles and aspects of software programme. The implementation of SoC invloves Modularising and decomposing the software into pieces which are meant for the concerns to be addressed. Here the concern is a feature, objective, behavior, focus or a significant piece of interest in the system to be dealt with.

It may sound vague and little confusing, but it is based on the simple principle “Divide and gain”. If you look at any design principle the common thing epicted is to keep and address the concerns effectively by treating them as it require some individual and definite solution. In general, the whole idea is to make the software easier to understand, design and manage complex interdependent systems.

In Real time software design, this is an important objective to be fulfilled. So the reason you see ‘n’ tier architectures and layered designs. Layering helps achieve separation of concerns, making applications more modular by grouping the components that does similar things.

All the design and programming methodologies help the designers and developers to benefit from the SoC. For example

  • Procedural languages such as C and Pascal can separate concerns into procedures.
  • Object oriented design is providing the principles like encapsulation to improve the SoC.
  • Object-oriented languages like Java separate concerns into objects.
  • The design pattern like MVC can separate content from presentation and data processing (model) from content.
  • Service-oriented design can separate concerns into services.
  • Aspect-oriented programming languages can separate concerns into aspects and objects.
  • Event-Driven design can separate concerns into events.

So the goal is while designing the software systems, the individual units of the system can be given a focus independently rather than doing with the overlapping functionality. The immediate outcome of a module (separated concern) which does not cause other subsystems to fail or hold up, thus increasing productivity and speeding the development of other modules. I personally think that any subsystem or component which is not given a focus on its own effectiveness will be a disruption to any mission-critical application rather being a good piece of software.

This is applicable for developers with different skill sets working on an application development. For example consider any MVC framework development. A web developer in your team will be better choice for the front-end development rather letting a middleware person to work on web page development. And the integration at any level is done by contract.

In any ideal application development team will comprise all the necessary skill set required for the development and harnessing their skills to get the better solution and treatment to any concern. And this is not just for software systems and it is applicable for any business or application infrastructure. In conclusion, Separation of concerns allows individual modules in a software system to be rightly understood, effectively developed, better tested and optimised for its execution.

Let me know me what you think.

[rating:85/100]


Tags: [ , , , ]


Related Posts


Comments