cas 703 software designkhedri/wp-content/uploads/courses/cas7… · dependency inversion principle...

CAS 703 SoftwareDesign

Dr. R. Khedri

Outline

Preliminaries

Principle of LowCoupling and HighCohesion

DependencyInversion Principle

Other DesignPrinciples forSecurity

CAS 703 Software Design

Dr. Ridha Khedri

Department of Computing and Software, McMaster UniversityCanada L8S 4L7, Hamilton, Ontario

Dr. R. Khedri CAS 703 Software Design


Dr. R. Khedri

Outline

Preliminaries




1 Preliminaries

2 Principle of Low Coupling and High CohesionExample

3 Dependency Inversion Principle

4 Other Design Principles for SecurityPrinciple of Least PrivilegePrinciple of Fail-Safe DefaultsPrinciple of Economy of MechanismPrinciple of Complete MediationPrinciple of Open DesignPrinciple of Separation of PrivilegePrinciple of Least Common MechanismPrinciple of Psychological Acceptability



Dr. R. Khedri

Outline

Preliminaries




An Overview of DesignPrinciplesåPreliminaries

A design process is not to simply identify one possiblesolution for a problem and then furnish the details of it

A good designer has to identify several alternativedesigns for a problem

In the selection process, the designer is guided bydesign principles

These principles build on the ideas of simplicity andrestriction

Simplicity makes the proposed solutions easy tounderstand (Less can go wrong with simple designs)



Dr. R. Khedri

Outline

Preliminaries


Example



An Overview of DesignPrinciplesåPrinciple of Low Coupling and High Cohesion

In general:

Cohesion within a module is the degree to whichcommunication takes place among the module’selements

Coupling describes the degree to which modulesdepend directly on other modules

Effective modularization is accomplished by maximizingcohesion and minimizing coupling

This principle helps to decompose complex tasks intosimpler ones



Dr. R. Khedri

Outline

Preliminaries


Example




Figure: Cohesion and Coupling



Dr. R. Khedri

Outline

Preliminaries


Example




In the comtext of OO Design:

A system with highly inter-dependable classes is veryhard to maintain

A change in one class may result in cascading updatesof other classes

We should avoid tight-coupling of classes (Identifiedusing analysis class diagram)

A pair of classes which has dependency association oneach other is called tightly-coupled

Tight coupling might be removed by introducing newclasses or inheritance



Dr. R. Khedri

Outline

Preliminaries


Example




Figure: Vertical override operation (Used for decoupling)Dr. R. Khedri CAS 703 Software Design


Dr. R. Khedri

Outline

Preliminaries


Example




We should seek:

Less inter-dependency

Easy expansion

Simplicity and elegancy in implementation

good design =⇒ simple ∧ elegant

is equivalent to

¬simple ∨ ¬elegant =⇒ ¬good design



Dr. R. Khedri

Outline

Preliminaries


Example




A cohesive class is one that performs a set of closelyrelated operations

If a class performs more than one non-relatedfunctions, it is said to be lack of cohesion

A lack of cohesion makes the overall structure of thesoftware hard to manage, expand, maintain, and modify

By improving information hiding you will generally beimproving the coupling and cohesion

Information hiding is the hiding of design decisions thatare most likely to change (measured through LowCoupling and High Cohesion)



Dr. R. Khedri

Outline

Preliminaries


Example




Figure: An initial design of a Professor class



Dr. R. Khedri

Outline

Preliminaries


Example




Figure: An improved design of a Professor class



Dr. R. Khedri

Outline

Preliminaries


Example




Low coupled-lhigh cohesion architectures are far easierto modify (changes are more local)

The number of top-level packages in an architectureshould be small

A range of 7 ± 2 is a useful guideline (projects mightvary)

The difference between small and large scale projects isthe amount of nesting of modules or packages

Large scale projects typically organize each top-levelpackage into subpackagesThe 7 ± 2 guideline applies to each of these



Dr. R. Khedri

Outline

Preliminaries


Example




One possible architecture for the most common video gamesconsists of four packages.

The environment in which the game takes place (areas,connections, etc.)

The mechanism controlling the game (encounters,reactions to events, etc.)

The participants in the game (player and foreigncharacters, etc.)

The artifacts involved in the game (swords, books,shields, etc.)

Each of these modules is quite cohesive



Dr. R. Khedri

Outline

Preliminaries


Example




Consider how to decompose the design of a personal financeapplication

Accounts (checking, savings, etc.)

Bill paying (electronic, by check, etc.)

Reports (total assets, liabilities, etc.)

Loans (car, education, house, etc.)

Investments (stocks, bonds, commodities, etc.)

Weaknesses: Little cohesion in the Accounts module

Great deal of coupling among these 5 partsDr. R. Khedri CAS 703 Software Design


Dr. R. Khedri

Outline

Preliminaries


Example




An alternative architecture

Assets (checking accounts, stocks, bonds, etc.)

Sources (employers, rental income, etc.)

Suppliers (landlord, loans, utilities, etc.)

Interfaces (user interface, communications interface,reporting, etc.)

To understand which architecture options are better:experimental and investigative activity (try alternatives,modify them, and retry)

Should be done at a high level (expensive at low level)



Dr. R. Khedri

Outline

Preliminaries


Example




The principle urges 00 designers to meet two criteria:

Open to extension: the system can be extended tomeet new requirements.

Closed to modification: the existing implementationand code should not be modified as a result of systemexpansion

We should try our best to minimise the violation of thisprinciple so that the reusability of the software can bemaximised

Technical approach for achieving Open-Closed Principleis the abstraction via inheritance and polymorphism



Dr. R. Khedri

Outline

Preliminaries


Example




Figure: Registering Website Members (Rigid)



Dr. R. Khedri

Outline

Preliminaries


Example




Figure: Registering Website Members (Flexible)



Dr. R. Khedri

Outline

Preliminaries


Example




Figure: Call Manager manages a Call abstract class



Dr. R. Khedri

Outline

Preliminaries


Example




The Open-Closed Principle has many interestingimplications

Separation of interface and implementation

Keep attributes private

Minimize the use of global variables

There are many other important 00 design principles



Dr. R. Khedri

Outline

Preliminaries


Example




åExample

Figure: Inheritance relationship



Dr. R. Khedri

Outline

Preliminaries


Example




åExample

Figure: Composition vs. inheritance



Dr. R. Khedri

Outline

Preliminaries


Example




åExample

Figure: A refined design of the previous example



Dr. R. Khedri

Outline

Preliminaries




An Overview of DesignPrinciplesåDependency Inversion Principle

Principle (Dependency Inversion Principle (DIP) /Inversionof Control)

High level modules should not depend upon low levelmodules. Both should depend upon abstractions.Abstractions should not depend upon details. Details shoulddepend upon abstractions.

This defines a very powerful rule for designing andprogramming: Design to an interface, not animplementation



Dr. R. Khedri

Outline

Preliminaries





Principle (Dependency Inversion Principle (DIP) /Inversionof Control (2))

Packages that are maximally stable should be maximallyabstract. Instable packages should be concrete. Theabstraction of a package should be in proportion to itsstability.

In a sense, it follows what has been referred to as theHollywood Principle: don’t call us, we will call you



Dr. R. Khedri

Outline

Preliminaries





Principle (Interface Segregation Principle)

Clients should not be forced to depend upon interfaces thatthey do not use.

It says: if there are two non-cohesive functionalities,keep them separate

This avoids design of fat interfaces, and provides aclear design to the user (client)

Break the functionalities into atomic interfaces thatcan be then individually accessed by the user



Dr. R. Khedri

Outline

Preliminaries





Principle (Law of Demeter)

Each unit should have only limited knowledge about otherunits: only units ”closely” related to the current unit.

It is a style rule for building systems

”Only talk to your immediate friends” is the motto

Break the functionalities into atomic interfaces thatcan be then individually accessed by the user

A method should have limited knowledge of an objectmodel



Dr. R. Khedri

Outline

Preliminaries




Principle of LeastPrivilege

Principle of Fail-SafeDefaults

Principle of Economyof Mechanism

Principle of CompleteMediation

Principle of OpenDesign

Principle of Separationof Privilege

Principle of LeastCommon Mechanism

Principle ofPsychologicalAcceptability

An Overview of DesignPrinciplesåOther Design Principles for Security

åPrinciple of Least Privilege

Principle (Least Privilege)

The principle of least privilege states that a subject shouldbe given only those privileges that it needs in order tocomplete its task.

If a subject does not need an access right, the subjectshould not have that right

This is analogue to the ”need to know” rule



Dr. R. Khedri

Outline

Preliminaries













åPrinciple of Fail-Safe Defaults

Principle (Fail-Safe Defaults)

The principle of fail-safe defaults states that, unless asubject is given explicit access to an object, it should bedenied access to that object.

This is security version of this principleThis principle assumes that the default access to anobject is none

If the subject is unable to complete its action or task, itshould undo those changes it made in the security stateof the system before it terminates

Even if the program fails, the system is still safe



Dr. R. Khedri

Outline

Preliminaries













åPrinciple of Economy of Mechanism

Principle (Economy of Mechanism)

The principle of economy of mechanism states that securitymechanisms should be as simple as possible.

If a design and implementation are simple, fewerpossibilities exist for errors

This principle simplifies the design and implementationof security mechanisms

Simple design =⇒ less assumptions =⇒ less risks

Simple design =⇒ simpler testing



Dr. R. Khedri

Outline

Preliminaries













åPrinciple of Complete Mediation

Principle (Complete Mediation )

The principle of complete mediation requires that allaccesses to objects be checked to ensure that they areallowed.

This principle restricts the caching of information

When a subject attempts to read an object, theoperating system should mediate the action(determines if he is allowed + provides the resources )

If the subject tries to read the object again, the systemshould check that the subject is still allowed to readthe object



Dr. R. Khedri

Outline

Preliminaries













åPrinciple of Open Design

Principle (Open Design )

The principle of open design states that the security of amechanism should not depend on the secrecy of its designor implementation.

This principle suggests that complexity does not addsecurity

If the strength of the program’s security depends on theignorance of the user, a knowledgeable user can defeatthat security mechanism (”security through obscurity”)This is especially true of cryptographic software andsystems (algorithms kept secret)Keeping cryptographic keys and passwords secret doesnot violate this principle



Dr. R. Khedri

Outline

Preliminaries













åPrinciple of Separation of Privilege

Principle (Separation of Privilege)

The principle of separation of privilege states that a systemshould not grant permission based on a single condition.

This principle is restrictive because it limits access tosystem entities

This principle is equivalent to the separation of dutyprinciple

Systems and programs granting access to resourcesshould do so only when more than one condition is met



Dr. R. Khedri

Outline

Preliminaries













åPrinciple of Least Common Mechanism

Principle (Least Common Mechanism)

The principle of least common mechanism states thatmechanisms used to access resources should not be shared.

Sharing resources provides a channel along whichinformation can be transmitted, and so such sharingshould be minimized

This principle is restrictive because it limits sharing



Dr. R. Khedri

Outline

Preliminaries













åPrinciple of Psychological Acceptability

Principle (Psychological Acceptability )

The principle of psychological acceptability states thatsecurity mechanisms should not make the resource moredifficult to access than if the security mechanisms were notpresent.

It recognizes the human element in security

Configuring and executing a program should be as easyand as intuitive as possible

In practice, the principle of psychological acceptabilityis interpreted to mean that the security mechanismmay add some extra burden, but that burden must beboth minimal and reasonable



Dr. R. Khedri

Outline

Preliminaries













cas 703 software designkhedri/wp-content/uploads/courses/cas7… · dependency inversion principle...

Documents