( Fundamental design principles continued from previous post...)
DESIGN BY CONTRACT (DBC): This principle talks about how elements of software collaborate with each other. In a typical complex software, first the contracts are defined and then different components of the software that need to talk to each other are defined. Typically the contracts are defined by system architect who understands the entire software system and knows how should each software components interact. In Java programming language, the contracts are nothing but the Interfaces.
Lets see what will be the consequence of not designing by contract. If contracts are not well or completely defined or not defined at all, developer integration is going to be a nightmare and will lead to schedule risk. Because during DIT (Developer Integration Testing), the developers need to talk to all other developers who are developing different components of the same system and correct the contracts. Individually developed components will not collaborate well. This needs to be avoided.
Eiffel Programming Language is one language that follows design by contract principle and a good example for DBC principle, we may want to have a look at this language.Some real time contracts are as follows
1. Device Drivers
2. Standards and Protocols
3. COM (Component Object Model)
4. SOA (Service Oriented Architecture)
A real time example for design by contract is employee and employer systems. Employe signs an agreement before taking up an appointment latter of the employer and both the parties must adhere to what was signed in the agreement in other words a contract.
This principle says "Keep the Software Soft", Have you seen the software system where if you modify a line of code and you assume your modification works well, but in-fact, it has broken several software functionality? If the answer is yes, then probably the software system is not following this principle.This typically happens if software grows over the time, because the software design degrades over the period of time. The principle of Minimizing The Impact Of Change talks about how we can avoid these situations and we are encouraged to apply the following guidelines for minimizing the impact of change
1. Isolate Code: Isolate the code that has the one responsibility, meaning that the code responsible for a given task has to be in one place and should not scattered in several files. Its so obvious that this practice reduces impact of change since any change in that particular task can be done in one place. As par as the impacts are concerned, you need to test only isolated code.
2. Minimize Dependencies: Dependencies are another hurdle in software development. Changing something in software component will require change in its dependent components also. And hence dependencies need to be reduced and a complete functionality needs to be implemented by one component that does not depend on any other for completing the given functionality. In software systems, the dependencies can't be avoided 100%, however the dependencies must be in such a way that modifying a component should not require change in its dependency or recompiling the dependency. An example is that develop reusable core software components and use in required components. the core components are built, tested once and they do not require any change further Maintain unidirectional dependencies and avoid circular ones..
3. Standardize/Define Contracts: Defining contracts is a kind of standardizing how different software components must behave. However tricky part is modifying a contract needs to be done carefully. Do not just add a public method in the interface without giving a thorough thought since you are modifying the initial agreement.
4.Reuse - Don't Reinvent: Reuse as much as possible and avoid duplicates in the software code. Duplicate code always has the change impact since the person who is changing the code tends to forget to change in several other duplicated code.
5. Continuous Verification (Fail Fast): Use assertions, automated tests for continuous verification, Run automated test cases after each change. Another best practice is to use Test Driven Development (TDD) for continuous verification purposes
DESIGN BY CONTRACT (DBC): This principle talks about how elements of software collaborate with each other. In a typical complex software, first the contracts are defined and then different components of the software that need to talk to each other are defined. Typically the contracts are defined by system architect who understands the entire software system and knows how should each software components interact. In Java programming language, the contracts are nothing but the Interfaces.
Lets see what will be the consequence of not designing by contract. If contracts are not well or completely defined or not defined at all, developer integration is going to be a nightmare and will lead to schedule risk. Because during DIT (Developer Integration Testing), the developers need to talk to all other developers who are developing different components of the same system and correct the contracts. Individually developed components will not collaborate well. This needs to be avoided.
Eiffel Programming Language is one language that follows design by contract principle and a good example for DBC principle, we may want to have a look at this language.Some real time contracts are as follows
1. Device Drivers
2. Standards and Protocols
3. COM (Component Object Model)
4. SOA (Service Oriented Architecture)
A real time example for design by contract is employee and employer systems. Employe signs an agreement before taking up an appointment latter of the employer and both the parties must adhere to what was signed in the agreement in other words a contract.
MINIMIZING THE IMPACT OF CHANGE
This principle says "Keep the Software Soft", Have you seen the software system where if you modify a line of code and you assume your modification works well, but in-fact, it has broken several software functionality? If the answer is yes, then probably the software system is not following this principle.This typically happens if software grows over the time, because the software design degrades over the period of time. The principle of Minimizing The Impact Of Change talks about how we can avoid these situations and we are encouraged to apply the following guidelines for minimizing the impact of change
1. Isolate Code: Isolate the code that has the one responsibility, meaning that the code responsible for a given task has to be in one place and should not scattered in several files. Its so obvious that this practice reduces impact of change since any change in that particular task can be done in one place. As par as the impacts are concerned, you need to test only isolated code.
2. Minimize Dependencies: Dependencies are another hurdle in software development. Changing something in software component will require change in its dependent components also. And hence dependencies need to be reduced and a complete functionality needs to be implemented by one component that does not depend on any other for completing the given functionality. In software systems, the dependencies can't be avoided 100%, however the dependencies must be in such a way that modifying a component should not require change in its dependency or recompiling the dependency. An example is that develop reusable core software components and use in required components. the core components are built, tested once and they do not require any change further Maintain unidirectional dependencies and avoid circular ones..
3. Standardize/Define Contracts: Defining contracts is a kind of standardizing how different software components must behave. However tricky part is modifying a contract needs to be done carefully. Do not just add a public method in the interface without giving a thorough thought since you are modifying the initial agreement.
4.Reuse - Don't Reinvent: Reuse as much as possible and avoid duplicates in the software code. Duplicate code always has the change impact since the person who is changing the code tends to forget to change in several other duplicated code.
5. Continuous Verification (Fail Fast): Use assertions, automated tests for continuous verification, Run automated test cases after each change. Another best practice is to use Test Driven Development (TDD) for continuous verification purposes
No comments:
Post a Comment