SFWR ENG 3A04: Software Design II · principle Dependency Inversion Principle Law of Demeter Other...

SFWR ENG 3A04:Software Design II

Dr. R. Khedri

OutlineSFWR ENG 3A04: Software Design II

Dr. Ridha Khedri

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

Term 1

Acknowledgments: Material based on Software Architecture Design by Tao et al. (Chapter 4)

Dr. R. Khedri SFWR ENG 3A04: Software Design II


Dr. R. Khedri

Outline

Part I: Review ofPrevious Lecture

Part II: Today’sLecture

Outline of Part I

1 OO Analysis and DesignOO AnalysisOO Design

2 Questions???



Dr. R. Khedri

Outline

Part I: Review ofPrevious Lecture

Part II: Today’sLecture

Outline of Part II

3 Overview

4 Principle of Low Coupling and High Cohesion

5 Open-Closed Principle

6 Liskov substitution principle

7 Dependency Inversion Principle

8 Law of Demeter

9 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

OO Analysis andDesign

Questions???Part I

Review of Previous Lecture



Dr. R. Khedri

Overview

Principle of LowCoupling and HighCohesion

Open-ClosedPrinciple

Liskov substitutionprinciple

DependencyInversion Principle

Law of Demeter

Other DesignPrinciples forSecurity

Part II

Today’s Lecture



Dr. R. Khedri

Overview





Law of Demeter


General Design Principles Overview

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

Overview





Law of Demeter


General Design Principles Principle of LowCoupling 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

Overview





Law of Demeter


General Design Principles

Figure: Cohesion and Coupling



Dr. R. Khedri

Overview





Law of Demeter



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

Overview





Law of Demeter



Figure: Vertical override operation (Used for decoupling)Dr. R. Khedri SFWR ENG 3A04: Software Design II


Dr. R. Khedri

Overview





Law of Demeter



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

Overview





Law of Demeter



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

Overview





Law of Demeter



Figure: An initial design of a Professor class



Dr. R. Khedri

Overview





Law of Demeter



Figure: An improved design of a Professor class



Dr. R. Khedri

Overview





Law of Demeter



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

Overview





Law of Demeter



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

Overview





Law of Demeter



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 SFWR ENG 3A04: Software Design II


Dr. R. Khedri

Overview





Law of Demeter



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

Overview





Law of Demeter


General Design Principles Open-ClosedPrinciple

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

Overview





Law of Demeter



Figure: Registering Website Members (Rigid)



Dr. R. Khedri

Overview





Law of Demeter



Figure: Registering Website Members (Flexible)



Dr. R. Khedri

Overview





Law of Demeter



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

Overview





Law of Demeter


General Design Principles Liskov substitutionprinciple

Principle (Liskov substitution principle )

Let q(x) be a property provable about objects x of type T .Then q(y) should be true for objects y of type S where S isa subtype of T .



Dr. R. Khedri

Overview





Law of Demeter


General Design Principles DependencyInversion 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

Overview





Law of Demeter


General Design Principles DependencyInversion Principle

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

Overview





Law of Demeter


General Design Principles InterfaceSegregation Principle

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

Overview





Law of Demeter


General Design Principles Law of Demeter

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

Overview





Law of Demeter


General Design Principles Law of Demeter

A A

B BC C

D DE E

F F

G1

G2

G1 refinement G2

refinement: connectivity of G2is in pure form in G1Allows extra connectivity.

Figure: Re-structuring



Dr. R. Khedri

Overview





Law of Demeter


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

General Design Principles Other DesignPrinciples for Security

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

Overview





Law of Demeter











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

Overview





Law of Demeter











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

Overview





Law of Demeter











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

Overview





Law of Demeter











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

Overview





Law of Demeter











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

Overview





Law of Demeter











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

Overview





Law of Demeter











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

Overview





Law of Demeter











SFWR ENG 3A04: Software Design II · principle Dependency Inversion Principle Law of Demeter Other...

Documents

Transcript of SFWR ENG 3A04: Software Design II · principle Dependency Inversion Principle Law of Demeter Other...