Transcript Design Principles
Software Design Fundamentals Design Principles
Slides from Dr. Dewan Tanvir Ahmed
Lecture Objectives
To understand the importance of design in developing quality software To describe the translation from the requirements analysis model to the design model To understand the principles that guide proper design of software 2
Lecture Objectives
Design Principles • • • • • Abstraction Modularity Information Hiding Cohesion Coupling
3
Software Design
General definition of design
“… the process of applying various techniques and principles purpose of defining a device, a process, or a system in to permit its physical realization .” for the sufficient detail
Goal:
To produce a model or representation that will later be built
Engineering or Art?
4
Software Design Model
Functional model Behavioral model Design Information model Data design Architectural design Other requirements Procedural design Code Program modules Test Integrated & validated software 5
Software design process
6
Software architecture
The design process a system and the framework for sub-system control and communication is for identifying the sub-systems making up architectural design
.
The output of this design process is a description of the software architecture.
7
General Design Guidelines
Exhibit
a hierarchical organization
use of control among components that makes intelligent Logically partitioned into components specific tasks and subtasks that perform Distinct representation of data and procedure Lead to interfaces that reduce complexity Derived using a repeatable method driven by information gathered during requirements 9
Data Design
The primary activity during data design is to select logical representations of data objects identified during the requirements definition and specification phase.
Transforms the information domain model created during the analysis into the data structures that will be required to implement SW.
Identify the program modules that operate upon the logical data structures Data design leads to better program structure, effective modularity, & reduced complexity 10
Data Specification Principles
Apply functional analysis principles to data Identify all data structures and associated operations Establish a data dictionary to define data & program design Defer low-level data design decisions Representation of data structure should only be known to modules with direct use of data within the structure Develop a library of useful data structures Language should support abstract data types 11
Architectural Design
Objective is to develop a modular program structure and represent the control relationships between modules Combines program and data structure by defining interfaces that allows data to flow throughout the program “Holistic view” of software 12
Design Principle - Abstraction
It is a means by which one can focus on the important aspects of a problem at a particular level without the hindrance of unnecessary or irrelevant and/or low-level detail.
Abstraction is especially essential in solving complex problems as it enables the problem solver to think in terms of conceptual ideas rather than in terms of their details. Abstraction can be expressed in different ways. [Jeff Kramer] 13
Abstraction in Software Engineering
Requirements Engineering - gather the critical aspects of the environment and required system while neglecting the irrelevant.
Requirements Goals Assumptions Constraints Scope Properties Use Cases?
Requirement Specification 14
Abstraction in Software Engineering?
Design clearfy the software architecture and component functionalities which satisfy functional and non-functional requirements while avoiding unnecessary implementation constraints.
Goals Assumptions Constraints Scope Properties Use Cases?
Requirement Specification User Interface Business Logic Data Layer Software Architecture 15
Design Principle - Modularity
What is Modularity (or Modularisation):
Decomposing large software into a number of smaller as independent as possible components, usually with the goal of placing different functionalities or responsibilities in different components.
A Component – the basic unit of modularisation (also called Modules) is A method A class A package Or other design element 16
Design Principle - Modularity
Easier to build, easier to change, easier to fix ... 17
Design Principle - Modularity
Why Modularity:
Software consists of thousands or millions of lines of code and the complexity can be easily be overwhelming. Modularity allows such complexity to be manageable for purposes of implementation and maintenance.
Where Modularity is needed:
Architectural Design: • Layered software architecture is an example of modularity Independent Design: • Enable the ability to design different components in different ways. 18
Design Principle - Modularity
Where Modularity is needed:
Component Design: • Make sure each component has a single well-defined purpose or function, with few, clear connection (for example, by interfaces) with other components Debugging: • Make bug finding easier as modularity allows bug finding to be with a particular component rather than the whole software Testing: • Modularity makes it possible that the testing can be carried out in a piecemeal fashion – one component at a time. This is crucial important for testing of large and integrated software systems 19
Design Principle - Modularity
Where Modularity is needed:
Independent Implementation and Development : • Make possible to distribute large software development into each individual in a team of people as far as the interface between components are clear and few.
Summary:
In conclusion, modular based design are useful for each phase of software development, from design, implementation, test, to maintenance. The reason behind this is that the as much as possible independence between the different components allows that the software tasks can be done separately to overcome high complexity in software development.
So modularity is one of the key principles in software design 20
Design Principle - Modularity
Balance component size and complexity
The small size components will require a lot of connections between them in total although less complexity in each component The large size components will require less connections in total but more complexity in each component Therefore, a balance of component size is required 21
Design Principle – Information Hiding
How to achieve modularity:
Apply information hiding principle and approach
What is the information hiding
• In modularisation • context: Components hides the internal details and processing from one another In more general context: • grouping and packaging the elements and internal details of an abstraction (a component, an abstract data type, a class or a object etc ) and making those details inaccessible Also called data hiding or encapsulation 22
Design Principle – Information Hiding
23
Design Principle – Information Hiding
Everyday example: Suppose you have to pay the bill of your newspaper subscription to your hawker. You can give your bill in two ways.
1.
Take out your wallet and give the wallet to the hawker so that he can take his bill’s amount out of your wallet. 2.
Take out your wallet, ask the bill amount from the hawker and give him the asked amount.
Which option is better? 24
Design Principle – Information Hiding
Why information hiding in design: each component hides a design decision from the others to achieve Changeability • If a design decision is changed, such as a data structure, changes are confined to as few components as possible whereas the design as a whole can remain intact Independent development • Enable independent development as far as the interfaces between components are simple and well defined. Also access methods are often simpler than access data Comprehensibility • For design, debug, testing and maintenance, it is vital to understand each component independently of others. Information hiding improves our understanding by eliminating confusing from unrelated functions and data. 25
Design Principle – Information Hiding
How to achieve information hiding
Apply the information hiding principle in design • Aiming at the end of the design process, any data structure or file is accessed only via certain well-defined specific methods (interfaces) Separation of interface and implementation • Separating interface and implementation involves defining a component by specifying a public interface, separate from (or hid) the details of how the component is realized.
Choose programming languages support Information hiding • Such as Java, C++, C#, Visual Basic, .Net
26
Characteristics of Good Design Component independence
High cohesion Low coupling Dr. Dewan Tanvir Ahmed
Design Principle – Coupling and Cohesion
What are Coupling
Coupling is a term to describe the interactions between components. The lower coupling, the less interaction (i.e., the more independence ) between components
Design Principle: Minimise Coupling
Coupling connections cause dependencies between components, which in turn, have an impact on system qualities such as maintainability (a modification of a components may require modifications to its connected components) or testability (a fault in one components may cause a failure in a completely different, connected components). Thus, a common design principle is to minimize coupling.
28
Coupling: Degree of dependence among components
No dependencies Loosely coupled-some dependencies Highly coupled-many dependencies High coupling makes modifying parts of the system difficult, e.g., modifying a component affects all the components to which the component is connected. Dr. Dewan Tanvir Ahmed
Design Principle – Coupling and Cohesion
What are Cohesion
Cohesion is a term to describe the interactions within components. The more cohesive a component, the more related the internal parts of the component to each other and to its whole purpose
Design Principle: Maximise Cohesion
A low cohesive design element has been assigned many unrelated responsibilities. Consequently, the design element is more difficult to understand and therefore also harder to maintain and reuse. Design elements with low cohesion should be considered for refactoring, for instance, by extracting parts of the functionality to separate classes with clearly defined responsibilities.
30
Design Principle – Coupling and Cohesion
Everyday Example 31
Design Principle – Coupling and Cohesion
32
Design Principle – Coupling and Cohesion
Relationship between Coupling and Cohesion
Coupling and cohesion are opposite sides in that strong cohesion tends to create weak coupling and vice versa 33
Design Principle – Coupling and Cohesion
Examples of Coupling and Cohesion
High Coupling Low Cohesion Low Coupling High Cohesion Which one is better from a software design point of view and why?
34
Design Principle – Coupling and Cohesion
Types of coupling:
• Content coupling • • • • Common coupling Control coupling Stamp coupling Data coupling 35
Types of Coupling
1. Content Coupling (i.e., modifying data within another component)
– Allowing one component to modify another component data. – – This is very strong coupling as a fault in one component may be caused by another One component references contents of another Example: – Component directly modifies another’s data – Component modifies another’s code, e.g., jumps into the middle of a routine 36
Types of Coupling
1. Content Coupling (i.e., modifying data within another component)
Example: – Part of program handles lookup for customer.
– When customer not found, component adds customer by directly modifying the contents of the data structure containing customer data.
Improvement: – When customer not found, component calls the AddCustomer() method that is responsible for maintaining customer data.
37
Types of Coupling
2. Common Coupling (i.e., shared or global data)
– Several components sharing the same or global data cause strong coupling between the components via data – • Two components share data Global data structures • Common blocks
Usually a poor design choice because
– – Lack of clear responsibility for the data Reduces readability – – – Difficult to determine all the components that affect a data element (reduces maintainability) Difficult to reuse components Reduces ability to control data accesses 38
Types of Coupling
2. Common Coupling (i.e., shared or global data)
– Process control component maintains current data about state of operation. Gets data from multiple sources. Supplies data to multiple sinks. – Each source process writes directly to global data store. Each sink process reads directly from global data store.
Improvement
Data manager component is responsible for data in data store. Processes send data to and request data from data manager.
39
Types of Coupling
Control Coupling (i.e., a method call with a parameter that is a switch)
• Passing parameters to control the activity of another component and allowing one component to control another component behaviour. • Component passes control parameters to coupled components.
May be either good or bad, depending on situation.
• Bad when component must be aware of internal structure and logic of another module • Good if parameters allow factoring and reuse of functionality 40
Types of Coupling
Stamp Coupling
• This is the case where entire data structures are passed to the called component but only some individual fields are used, or • Component passes a data structure to another component that does not have access to the entire structure.
Requires second component to know how to manipulate the data structure (e.g., needs to know about implementation) May be necessary due to efficiency factors: this is a choice made by insightful designer, not lazy programmer. 41
Types of Coupling
Stamp Coupling Example:
The print routine of the customer billing accepts a customer data structure as an argument, parses it, and prints the name, address, and billing information.
Improvement
The print routine takes the customer name, address, and billing information as an argument.
42
Types of Coupling
Data Coupling
– Pass pure data parameters into another component. Often used interaction between components. This is a weak couple and leaves less room for errors – Pass a series stream of data to another component without any transfer of control between components. This is the weakest coupling.
Conclusion
Strong coupling increases dependency and complexity, decreases transparency of components, and leave more room for errors Weak coupling between components is desired as it increases the modularity, is easy to manage, and reduces errors 43
Design Principle – Coupling
The different degree of coupling in order
Content Coupling Common Coupling
High Coupling
Control Coupling
Loose
Stamp Coupling Data Coupling Uncoupled
Low
44
Design Principle – Coupling
Types of Cohesion
• Coincidental Cohesion • • • • • • Logical Cohesion Temporal Cohesion Procedural Cohesion Communication Cohesion Sequential Cohesion Functional Cohesion 45
Design Principle – Coupling and Cohesion
The different degree of cohesion in order
High Cohesion Functional Sequential Communication Procedural Temporal Logical Coincidental Low Cohesion 46
Design Principle – Types of Cohesion
Coincidental Cohesion
– The worst degree of cohesion in which unrelated functions, processes, or data are put into a same component coincidently – Parts of the component are only related by their location in source code – This leads the component without well defined purpose – Example: • Print next line • Reverse string of characters in second argument • • Add 7 to 5th argument Convert 4th argument to float 47
Design Principle – Types of Cohesion
Logical Cohesion
• • • • • Elements of component are related logically and not functionally.
Several logically related elements are in the same component and one of the elements is selected by the client component.
The second worst degree of cohesion where several logically related functions or data elements are placed in the same component such as all output functions to screen, to printer, to fax machine, and to database are placed together but without taking into account the different purposes 48
Design Principle – Types of Cohesion
Logical Cohesion
• Example : A component reads inputs from tape, disk, and network. All the code for these functions are in the same component. Operations are related, but the functions are significantly different.
• Solution/Improvement A device component has a read operation that is overridden by sub-class components. The tape sub-class reads from tape. The disk sub-class reads from disk. The network sub-class reads from the network.
49
Design Principle – Types of Cohesion
Temporal Cohesion
Elements of a component are related by timing. Very weak cohesion in which functions or processes are put into a same component only because they have to be carried out at about the same time These activities are unrelated to one another except that they’re carried out at a particular time. Example: A system initialization routine: this routine contains all of the code for initializing all of the parts of the system. Lots of different activities occur, all at init time.
Improvement:
A system initialization routine sends an initialization message to each component.
Each component initializes itself at component instantiation time.
50
Design Principle – Types of Cohesion
Procedural Cohesion
Weak cohesion in which functions or processes are put into a same component only because they happen in a certain order such as: enter data; check data, and calculation They are related by order of execution rather than by any single problem related function. 51
Design Principle – Types of Cohesion
Communicational Cohesion
Module performs a series of actions related by a sequence of steps to be followed by the product and all actions are performed on the same data Update record in database and send it to the printer.
database.Update (record).
record.Print().
52
Design Principle – Types of Cohesion
Communicational Cohesion
Relative weak cohesion in which functions or processes are put into a same component because they act on the same data such as find title of book; find price of book; find author of book; find publisher of book; find published date of book. These four activities are related because they all work on the same data – book The weakness is that it is narrow on one side (book) and arbitrarily broad on the other (find title, price, author, publisher, date etc) depending on the number of functions in the component. This could lead to duplication or redundant of functions (think about “book” is changed to PC, then all “find” functions needed to be recoded) Dr. Dewan Tanvir Ahmed 53
Design Principle – Types of Cohesion
Sequential Cohesion
Certain cohesion in which the output from one part of a component is input to the next part The output of one component is the input to another.
Occurs naturally in functional programming languages Good situation 54
Design Principle – Types of Cohesion
Functional Cohesion
Every essential element to a single computation is contained in the component.
Best cohesion in which every processing element is essential to the performance of a single function, and
all essential elements
are contained in one component. The functionally cohesive component performs the function for which it is designed, and
only performs that function and nothing else
.
Ideal solution 55
Examples of Cohesion-1
Function A Function B Function D Function C Function E Coincidental Parts unrelated Function A logic Function A’ Function A’’ Logical Similar functions Function A Function B Function C Procedural Related by order of functions Dr. Dewan Tanvir Ahmed Time t 0 Time t 0 + X Time t 0 + 2X Temporal Related by time
Examples of Cohesion-2
Function A Function B Function C Communicational Access same data Function A part 1 Function A part 2 Function A part 3 Functional Ahmed Function A Function B Function C Sequential Output of one is input to another
Design Principle – Cohesion
Conclusion
Cohesion is the measure of the functional relatedness of elements (instructions, data definitions, etc.) within a single component. In a good design, the cohesion of every component is high. Together with coupling, cohesion is one of the good measures of the quality of a design.
58
High-Level (abstract) design Low-Level (detailed) design Software architecture Subsystem decomposition Subsystem dependencies Subsystem interfaces module or class decomposition module or class dependencies module or class interfaces Data structures Algorithms
59
Some Desirable Design Attributes
Hierarchical: A good design should be organized into a well-designed hierarchy of components.
Modular: Separate distinct concerns (data and processing) into distinct containers (i.e., subsystems, modules, and/or classes). Hide implementation details and provide clean, simple interfaces for each container.
60
Some Desirable Design Attributes
Independent: Group similar things together; limit the amount of “special knowledge” that unrelated components may share. If you change your mind about something, the impact will be localized.
61
Some Desirable Design Attributes
Simple Interfaces: Endless flexibility adds complexity. Complex interfaces mean: • hard to understand by users and developers (e.g., Unix man page syndrome) • many possible variations of use • inconvenient to change interface in order to eliminate “bad options”.
You can get away with “flexible interfaces” in a low-level localized setting, but the larger the scale, the simpler the interface should be.
62