Software Design - Cohesion
The term "software engineering" was coined 42 years ago.
Software Engineering is defined as the systematic approach to development, operation, maintenance, and retirement of software (IEEE). Another definition is the practical application of scientific (systematized body of) knowledge and construction of computer programs and associated documentation required to develop, operate and maintain them (Boehm)
One of the areas of software engineering that foster quality to a software product is design. Software design is the place where we can access models, diagrams of a logical product for quality. Adhering to industry accepted design practices is a must in order to produce quality software products.
It is good to adhere to sound software design guides like cohesion. Software engineers who wanted to write quality software uses proven principles for software design. The idea of cohesion and coupling in software design has been around for decades. It has been measured as a quality metric for software (Testing theory and quality assurance - a whole different area of software engineering). I am currently designing a software module and process that will be used by two separate business areas in my company. Applying the principle of software cohesion, a simple test for cohesion is to ask yourself "What does this software module do ?" If your answer contains an "and" it means that it is doing two or more things. What would be the downside of a process that do two or more things? It will be a harder to understand and therefore a little harder to maintain. If your module or process does only one thing. It will be much easier to understand and maintain.
As a counter argument if i need to change a common element for my two processes then i will need to change it in two places (e.g. if both process uses a date format YYYY/MM/DD now i wanted to use MM/DD/YYYY). Which one will be easier to change, a big process that is a little more complicated because it does two things or two small straight to the point process that does one thing ? I will always go for the two small processes because it will be much easier to test.
Software Engineering is defined as the systematic approach to development, operation, maintenance, and retirement of software (IEEE). Another definition is the practical application of scientific (systematized body of) knowledge and construction of computer programs and associated documentation required to develop, operate and maintain them (Boehm)
One of the areas of software engineering that foster quality to a software product is design. Software design is the place where we can access models, diagrams of a logical product for quality. Adhering to industry accepted design practices is a must in order to produce quality software products.
It is good to adhere to sound software design guides like cohesion. Software engineers who wanted to write quality software uses proven principles for software design. The idea of cohesion and coupling in software design has been around for decades. It has been measured as a quality metric for software (Testing theory and quality assurance - a whole different area of software engineering). I am currently designing a software module and process that will be used by two separate business areas in my company. Applying the principle of software cohesion, a simple test for cohesion is to ask yourself "What does this software module do ?" If your answer contains an "and" it means that it is doing two or more things. What would be the downside of a process that do two or more things? It will be a harder to understand and therefore a little harder to maintain. If your module or process does only one thing. It will be much easier to understand and maintain.
As a counter argument if i need to change a common element for my two processes then i will need to change it in two places (e.g. if both process uses a date format YYYY/MM/DD now i wanted to use MM/DD/YYYY). Which one will be easier to change, a big process that is a little more complicated because it does two things or two small straight to the point process that does one thing ? I will always go for the two small processes because it will be much easier to test.
Comments