construction design principles in software engineering

• It is good for the module because modification of module internals from outside module is prohibited.
• This protects the module from damage by errant external code, makes module repair and enhancement simpler, and makes module reuse easier.

How it is Good for Rest of the Program?

• It enforces discipline in the use of the module.
• The internal details of a module need not be understood to use it, thus reducing complexity and making programming much easier.
• The interface to the module is fixed and stable, making it easier to understand and use, and easy to replace with an equivalent module if necessary.
• Perhaps most important, the module may be repaired without fear of breaking the rest of the program, a boon during development and maintenance.

Principle of Least Privilege.

Information hiding is about a module restricting access to the details of the internal processing. A complementary principle is that a module should not have access to resources that it doesn’t need to accomplish it’s goals.

Principle of Least Privilege:-

Modules should not have access to unneeded resources.

In the worst case, a module with access to unneeded resources can be the source of serious problems such as security breaches.

some of the examples of principle of least privilege include.

• Modules that import packages or modules they don’t need.
• Modules with unneeded access to file systems, databases, or other computers.
• Source code that includes unneeded header files.
• Operations with parameters for passing data thy don’t need.

Principle of Coupling

Coupling is the major of what extant a module is dependent on another module. Pairs of modules that communicate in less desirable ways, are strongly coupled or tightly coupled, pairs that communicate only a little and in desirable ways are weakly coupled, and pairs that don’t communicate at all are not coupled or decoupled.

Strongly coupled modules are hardly to change independently because much consideration must be given to the data going out to, and coming in from, other modules.

Strongly coupled are hard to understand, explain and document because they can’t really be considered independently of the modules to which they are coupled.

Finally, strongly coupled modules are harder to test, debug, and maintain because they can’t be treated in isolation. Correction or enhancement is thus a bigger and more difficult. Modularity is enhanced when coupling is minimized.

So the principle of coupling is Module Coupling should be minimized.

There must always be some degree of module coupling. If every module in a system were completely decoupled from every other module, then no modules would communicate at all and the system couldn’t work.

The trick is to come up with modules that communicate as little as possible and communicate in ways that do not bind them unnecessarily to one another.

Principle of cohesion

Cohesion is the degree to which a module’s parts are related to one another. Cohesive modules hold data on a single topic or related topics, perform a single job, carry out a responsibility, and have a clear role.

Cohesive modules have parts that “belong together”. A module all of whose parts are strongly related is said to be cohesive, or to have cohesion; a module without strongly related parts is non-cohesive.

Besides the obvious benefits to understandability that high module cohesion brings, it is also beneficial because changes to highly cohesive module. Thus highly cohesive modules are easier to code, test, debug and maintain. They are also easier to explain and document.

This leads to the principle of cohesion.

Module cohesion should be maximized.

the principle of cohesion is fits well with the principle of coupling: a highly cohesive module should be able to do most of it’s work on its own, so communication with other modules will be minimized, thus reducing coupling.

Implementability Principles

Software development is expensive. and usually done on a budget and a schedule. Designs that are easier to implement will usually be cheaper and faster to implement as well. Implementability principles help achieve overall design economy by providing criteria for judging whether a design can be built as easily and, cheaply and quickly as possible.

• Principle of simplicity.
• Principle of Designing with Reuse.

Simpler designs can usually be created, documented, coded, tested, and debugged faster and are generally less error-prone to start with. Hence, it is clear that simplicity is a major contributor to design implementability, leading to the Principle of Simplicity

Simpler Designs are better.

People drawn to software development tend to enjoy the challenge of solving problems. Unfortunately, fascination with complexity leads some designers to make their creations more complex than necessary.

Several legitimate concerns, like efficiency and reusability, can also lead designers into the trap of making overly complex designs.

An argument for the more complex solution on the grounds of efficiency is baseless because, the more complex solution is indeed more (time) efficient, but if performance is not a problem, then simpler solution is the best.

Software reuse is the use of existing knowledge or artifacts to build new software products. Items reused during software development may range from project plans through product requirements, design components, code components, test plans, and test cases, Anything that can be reused is termed as asset.

Reuse has great productivity and quality benefits, and software design offers many opportunities for software reuse. There are two aspects of reuse that figure in software design:

• Designers can use existing assets — this is called Design with Reuse.
• Designers can create work products intended for reuse — this is called Design for Reuse.

The first of these aspects of reuse has a great effect on design implementability, leading to the Principle of Designing with Reuse.

Systems should be designed to reuse existing assets as much as possible.

Although quality and productivity gains come from designing with reuse, this can only be done if reusable assets are available. Hence, an investment must first be made in designing for reuse.

Aesthetic Principles

In many other design disciplines, beauty is the main goal of design. Hence, the aesthetic principles are important in software designs.

Any design that satisfies requirements and conforms to design constraints gets done what needs to be done, so for a given problem, any any adequate design is as powerful as any other.

But a simpler design will be better. This is why power must be combined with simplicity.

The most beautiful designs are those in which extremely simple mechanisms are able to accomplish a great deal.

For example Quicksort is a very simple algorithm that is among the fastest algorithms that sort by comparing and exchanging values — this makes it beautiful. The principle of Beauty generalize this observations.

Beautiful (Simple and Powerful) designs are better.

There is some question whether beauty is simply a combination of simplicity and power, or whether some other factors are present.

Some designs are simple and quite powerful yet seem crude. Beauty has been an object of philosophical investigation of millennia, and the nature of beauty is still an open question.

Originally published at https://www.csmates.com.