Woody Case

) Reuse-Release Equivalence (REP)

REP is a design principle. Abhijit Nadgouda(2006) states that "The granule of reuse is the granule of release. Only components that are released through a tracking system can be effectively reused. This granule is the package".

Every code should come or release in complete and black-box package which can be reused but can't be changed. It encourages the principle of grouping together all the classes in a single package which inherit same changes.

Common-Closure Principle (CCP)

CCP is also a design principle which emphasizes mainly on maintainability rather than usability. This principle states that all the classes that inherits same changes should be packaged in a single package so that if some changes are made to a package then it should affect all the classes in that package.

Common-Reuse Principle (CRP)

CRP is also a design principle which stresses on the importance of a package. It states that if a person reuses any one class of a package then it can reuse all f them. It states that reusability of one class is difficult without all others.

Interface Segregation Principle: The interface-segregation principle (ISP) is one of the five important principles of Object-Oriented Design which is similar to the High Cohesion Principle of GRASP. It is a software development principle which is used for clean development and intends to make software easy-to-change. ISP keeps a system decoupled and thus easier to re-factor, change, and redeploy. ISP splits interfaces which are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. In a nutshell, no client should be forced to depend on methods it does not use. Such shrunken interfaces are also called role interfaces.

Stable-Dependencies Principle (SDP)

It is based on the understanding that code has volatility, and that changes ripple through a system

along dependency lines. From the point-of-view of volatility, dependency is transitive.

If the majority of the system's classes are dependent upon a volatile bit of code, then we can expect a high

frequency of system breakage and rippling changes. If, instead, a system depends on nonvolatile code,

then breakage should not ripple through the system very often at all. Some modules should change

frequently, and should be volatile. Other modules are essential core abstractions and should not change

very often.

Therefore the package dependency graph should flow from instable