Presentation is loading. Please wait.

Presentation is loading. Please wait.

A Brief Introduction to Software Design and Design Quality By Laura Leventhal.

Similar presentations


Presentation on theme: "A Brief Introduction to Software Design and Design Quality By Laura Leventhal."— Presentation transcript:

1 A Brief Introduction to Software Design and Design Quality By Laura Leventhal

2 Reference Chapter 11Chapter 11

3 Design of Interface We have already seen that design of user interfaces involves –Design of Interaction –Design of the software to run the Interaction (Design of Interface)

4 Design of Interface – A Software Design Problem Design of Interface is a software design problem. We assess software quality in the same way that we assess the quality of any other software. Because the design of the interface is intended to support user interactions, we can observe that the design of the software is similar to the design of real-time software. –Concerned with building software that has functional independence, encapsulation and data hiding, reuse PLUS –Concern for the states that the software must be able to support

5 Goals of Software Design To produce a model which will later be built To propose a solution to the problem to minimize cost of development and maintenance To keep parts small and separately solvable To keep parts small and separately correctable

6 What is to be designed during Software Design? High level design –System architecture - the product architecture –Class relationships - data architecture –Messaging architecture Low level design –Classes –Operations (member functions, class services) –Attributes (data members) –State behaviors

7 Software Design Quality A software design is of high quality if… –It is a solution to the problem that was defined in the requirements specification. –It promotes functional independence Low intermodular dependency High intramodule cohesion –Promotes encapsulation and data hiding –Promotes software reuse

8 Measuring Functional Independence Qualitative measures of functional independence –Coupling (measure of intermodular dependency) –Cohesion (measure of internal strength of module)

9 Coupling Low coupling between modules is desirable. High coupling is not as good. Example of low coupling –Two modules that communicate by passed parameters Example of high coupling –Module A changes the code within Module B

10 Cohesion High cohesion is good. Low cohesion is bad. Module A is highly cohesive if all of the elements are focused on a single task. Module B has low cohesion if several functions are within the same module. So for example a module that groups several input functions, just because they involve inputs would have relatively low cohesion.

11 OO Coupling and Cohesion? Page-Jones has noted that coupling and cohesion are defined at the code and subroutine level. He suggests that it also makes sense to consider class cohesion and class coupling –Class cohesion level is an indication of how well the operations of the class are focused on one job. –Class coupling is an indication of how tightly bound two classes are.

12 Encapsulation Encapsulation is the grouping of related ideas into one unit which can thereafter be referred to by a single name The idea is that the interface is a protective boundary between that which is encapsulated and that which is outside. –Subroutine is an example of encapsulation –Classes are a more extreme example of encapsulation. Encapsulation promotes functional independence

13 Information (Data) Hiding Data Hiding is a by-product of encapsulation. –You may view an encapsulated unit from the inside or the outside. –Only data needed to perform a function is made available to the function. –Data hiding is the use of encapsulation to restrict the external visibility of implementation decisions that are internal to the encapsulation structure. In some regard, encapsulation and data hiding is a way to promote low coupling.

14 Software Reuse Viewed as essential to improving productivity Implication for design is that functionality should be as broad as possible Classes may even need extra methods Note that this goal may be in conflict with other software design goals such as loose coupling.

15 OO Philosophy and Design Quality OO should promote –Functional independence, at least between classes. The designer is challenged to insure high cohesion and low coupling within the member functions of classes. –Encapsulation and data hiding –Software reuse.


Download ppt "A Brief Introduction to Software Design and Design Quality By Laura Leventhal."

Similar presentations


Ads by Google