CSEB233: Fundamentals of Software Engineering Introduction to Software & Software Engineering.
CSEB233 Fundamentals of Software Engineering
description
Transcript of CSEB233 Fundamentals of Software Engineering
CSEB233 Fundamentals of Software Engineering
Module 4: Software Design
Badariah Solemon 2011
Objectives
• To explain set of design principles, concepts, and practices.
• To describe four design models required for a complete design specification: data design, architectural design, user interface design, and component-level design.
• To introduce design support tools and evaluation.
• To introduce design specification document.Badariah Solemon 2011
What is Design?• Design creates a representation or model
of the software • but unlike the analysis model, the design
model provides detail about:» software architecture, » data structures, » interfaces, and» components that are necessary to implement the
system.
• Why is it important? Because the model can be assessed for quality and
improved before code is generated, tests are conducted, and more users are involved.
Badariah Solemon 2011
Analysis Models Design Model
Analysis Model
use-cases - text use-case diagrams activity diagrams swim lane diagrams
data flow diagrams control-flow diagrams processing narratives
f low-oriented elements
behavioralelements
class-basedelements
scenario-basedelements
class diagrams analysis packages CRC models collaboration diagrams
state diagrams sequence diagrams
Data/ Class Design
Architectural Design
Interface Design
Component- Level Design
Design Model
The four design models:
Each of the elements of the analysis/requirements model provides information that is necessary to create the design models required for a complete design specification. Badariah Solemon 2011
Characteristics of Good Design
According to McGlaughlin(1991): Must implement all of the explicit requirements
contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer.
Must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software.
Should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.
Badariah Solemon 2011
Design PrinciplesAccording Davis(1995 ): The design process should not suffer from
‘tunnel vision.’ The design should be traceable to the analysis
model. The design should not reinvent the wheel. The design should “minimize the intellectual
distance” [DAV95] between the software and the problem as it exists in the real world.
The design should exhibit uniformity and integration.
Badariah Solemon 2011
Design Principle:
Badariah Solemon 2011
• The design process should not suffer from ‘tunnel vision.’
• The design should not reinvent the wheel.– Reinventing the wheel is a phrase that means to
duplicate a basic method that has already previously been created or optimized by others.
Design Principles (cnt’d) The design should be structured to
accommodate change. The design should be structured to degrade
gently, even when irregular data, events, or operating conditions are encountered.
Design is not coding, coding is not design. The design should be assessed for quality as it is
being created, not after the fact. The design should be reviewed to minimize
conceptual (semantic) errors.
Badariah Solemon 2011
Generic Task Set for Design Refer to the “Task Set” in page 222.
Badariah Solemon 2011
Design Concepts Fundamental design concepts that span both
traditional and OO software development include:
1) Abstraction 2) Architecture3) Patterns4) Separation of concerns5) Modularity6) Information hiding7) Functional Independence8) Refinement9) Aspects10) Refactoring11) OO Design concepts12) Design classes
Badariah Solemon 2011
Abstraction
• Designers should work to derive both procedural and data abstractions that serve the problem.
• Procedural abstraction – sequence of instructions that have a specific and limited function
• Data abstractions – a named collection of data that describes a data object
Badariah Solemon 2011
Abstraction (cnt’d)
Badariah Solemon 2011
door
manufacturer model number type swing direction weight
door
manufacturer model number type swing direction weight
implemented as a data structure
door
details of enter algorithm
door
details of enter algorithm
implemented with a "knowledge" of the object that is associated with “enter”
Abstraction (cnt’d)
Data abstraction refers to, providing only essential features by hiding its background details.
class result
{
int marks;
float percentage;
char name[20];
void input();
void output();
}
main()
{
bank b1;
b1.input();
b1.output();
}
b1 is an object calling input and output member functions, but that code is invisible to the object b1.
Badariah Solemon 2011
Architecture
• Is concerned on:– describing the fundamental organization of the system, – identifying its various components and their relationships
to each other, and – the environment in order to meet the system's quality
goals.
• Also, describe the overall structure of the software : – organization of program modules, – the manner in which these modules interact, and– the structure of data used by the components.
Badariah Solemon 2011
Patterns
• Online pattern searching:– http://inventors.about.com/gi/dynamic/offsite.ht
m?site=http%3A%2F%Fpatents.uspto.gov%2Fpatft%2Findex.html
• Under Quick Search, try to search pattern no. 7669112.
• You will get ‘automated spell analysis’ pattern.
Badariah Solemon 2011
Separation of Concerns
• Actually, it is a rule of thumb to define how modules should be separated to each other: – different or unrelated concerns should be restricted to
different modules.• Suggests that any complex problem can be easily
handled if it is sub-divided into pieces that can be solved independently.
• Why? So that a problem takes less time and effort to solve.
• Is manifested in other design concepts: modularity, aspects, functional independence and refinement.
Badariah Solemon 2011
Modularity
• When software is divided into components (modules).
• Modularize a design: – To ease the planning for implementation (coding, – To define and deliver software increments,– To easily accommodate changes,– To efficiently test and debug program, and– To conduct long-term maintenance without
serious side effects Badariah Solemon 2011
Modularity : Example
• x
Badariah Solemon 2011
#include <stdio.h>main() { …
printf(“This program draws a rectangle”);…
}
#include <stdio.h>void print_menu(void);main() { …
print_menu();…
} /* end main */
void print_menu(void) {
printf(“This program draws a rectangle”);
} /* end function */
Without Module
With Module
vs.
Information Hiding
• Suggests that modules should be specified and designed so that information (data structures and algorithm) contain within a module is inaccessible to other modules that have no need for such information.
• Implies that effective modularity can be achieved by defining a set of independent modules that communicate with one another only necessary information.
Badariah Solemon 2011
Information Hiding (cnt’d)
• Serves as an effective criterion for dividing any piece of equipment, software or hardware, into modules of functionality.
• Provides flexibility. – This flexibility allows a programmer to modify functionality of a
computer program during normal evolution as the computer program is changed to better fit the needs of users.
– When a computer program is well designed decomposing the source code solution into modules using the principle of information hiding, evolutionary changes are much easier because the changes typically are local rather than global changes.
Badariah Solemon 2011
Information Hiding: Example
• Suppose we have a Time class that counts the time of day:class Time
{
public:
void Display();
private:
int ticks;
};
• The Display() member function prints the current time onscreen. This member function is accessible to all. It's therefore declared public.
• By contrast, the data member ticks is declared private. Therefore, external users can't access it.
Badariah Solemon 2011
Information Hiding: Example (cnt’d)
• Regardless of how Display() extracts the current timestamp from ticks, users can be sure that it will "do the right thing" and display the correct time onscreen.
Badariah Solemon 2011
Functional Independence
• Achieved by developing independent modules – each module address a specific subset of requirements.
• Is assessed using cohesion and coupling.• Cohesion - is an indication of the relative functional
strength of a module.– a cohesive module should (ideally) do just one thing.
• Coupling - is an indication of the relative interdependence among modules.– depends on the interface complexity between modules, the
point at which entry or reference is made to a module, and what data pass across the interface.
Badariah Solemon 2011
Functional Independence (cnt’d)
• This class lacks cohesion:public class CashRegister{public void enterPayment(int dollars, int quarters, int dimes, int nickels, int pennies). . .public static final double NICKEL_VALUE = 0.05;public static final double DIME_VALUE = 0.1;public static final double QUARTER_VALUE = 0.25;. . .}
Badariah Solemon 2011
Functional Independence (cnt’d)
• The CashRegister, as described above, involves two concepts: cash register and coin
• Solution: Make two classes:public class Coin{public Coin(double aValue, String aName){ . . . }public double getValue(){ . . . }. . .}
public class CashRegister{public void enterPayment(int coinCount, Coin coinType) { . . . }. . .}
Badariah Solemon 2011
Functional Independence (cnt’d)
• Coupling:
Badariah Solemon 2011
Refinement
Badariah Solemon 2011
open
walk to door;reach for knob;
open door;
walk through;close door.
repeat until door opensturn knob clockwise;if knob doesn't turn, then
take key out; find correct key; insert in lock;endifpull/push doormove out of way;end repeat
Refactoring
• According to Fowler (1999):– "Refactoring is the process of changing a software system in such a
way that it does not alter the external behavior of the code [design] yet improves its internal structure.”
• When software is refactored, the existing design is examined for – redundancy– unused design elements– inefficient or unnecessary algorithms– poorly constructed or inappropriate data structures– or any other design failure that can be corrected to yield a better
design. Badariah Solemon 2011
Design Model Elements1. Data/Class Design
Class diagrams transformed into the design class realization and the data structures required to implement the software.
2. Architectural Design Provides high-level overview of the system with
detailed descriptions to be given by other design elements.
Defines the relationship between major structural elements of the software, the architectural styles and design patterns that can be used to achieve the requirements of the system and the constraints that affect the way in which the architecture can be implemented.
Badariah Solemon 2011
Design Models (cnt’d)3. Interface Design
Describes how the software communicates with systems that interoperate with it, and with human who use it.
4. Component-Level Design Defines the data structures, algorithms,
interface characteristics, and communication mechanisms allocated to each software component or module.
Badariah Solemon 2011
Data/Class Design Elements
example: High-level DFD
Source: http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_9
Badariah Solemon 2011
Data/Class Design Elements (cnt’d)
example: ERD
Source: http://www.svgopen.org/2003/papers/SvgInterfaceElectricalSwitching/index.html
Badariah Solemon 2011
Data/Class Design Elements (cnt’d)
example: Class Diagram
Source: http://www.agiledata.org/essays/objectOrientation101.html
Badariah Solemon 2011
Architectural Design Elements
The architectural model [Sha96] is derived from three sources: – information about the application domain for the software
to be built; – specific requirements model elements such as data flow
diagrams or analysis classes, their relationships and collaborations for the problem at hand, and
– the availability of architectural patterns (Chapter 12) and styles (Chapter 9).
Badariah Solemon 2011
Architectural Design Elements (cnt’d)
Example: architecture diagram
Source: http://blog.tmcnet.com/blog/tom-keating/2004/10/index.asp?page=7Badariah Solemon 2011
Architectural Design Elements (cnt’d)
Example: Architectural styles
Source: x
Badariah Solemon 2011
Interface Design Elements
• External interfaces to other systems, devices, networks or other producers or consumers of information
Badariah Solemon 2011
ControlPanel
LCDdisplay LEDindicators keyPadCharacteristics speaker wirelessInterface
readKeyStroke() decodeKey() displayStatus() lightLEDs() sendControlMsg()
Figure 9.6 UML interface representation for ControlPanel
KeyPad
readKeystroke() decodeKey()
<<interface>>
WirelessPDA
KeyPad
MobilePhone
Interface Design Elements (cnt’d)
• The user interface (UI)
Badariah Solemon 2011
Component Design Elements
Source: http://edn.embarcadero.com/article/31863#component-and-deployment-diagransBadariah Solemon 2011
• UML Component Diagram
Design Support Tools All aspects of the software engineering can be
supported by software tools: from project management software through tools for
business and functional analysis, system design, code storage, compilers, translation tools, test software, and so on.
• However, tools that are concerned with analysis and design, and with using design information to create parts (or all) of the software product, are most frequently thought of as CASE tools.
• List of CASE tools: http://www.unl.csi.cuny.edu/faqs/software-enginering/tools.html
Badariah Solemon 2011
CASE Tool: Example
Source: http://www.ibm.com/developerworks/rational/library/10/whats-new-in-rational-software-architect-8/index.html Badariah Solemon 2011
• IBM Rational Software Architect
CASE Tool: Example (cnt’d)
Source: http://www.sparxsystems.com/images/screenshots/platforms/databasemodeling_tn.jpg Badariah Solemon 2011
• Database Modeling: Enterprise Architect by Sparx Systems Pty Ltd.
Design Evaluation "A good software design minimizes the time
required to create, modify, and maintain the software while achieving run-time performance.“ (Shore and Chromatic, 2007)
According to Elssamadisy (2007):1) Design quality is people-sensitive.
For instance, design quality is dependent upon the programmers writing and maintaining the code.
2) Design quality is change-specific. There are two general ways to make designs of higher
quality with respect to this aspect: 1. generalizing from the tools like design patterns, and 2. using tests and refactoring as change-enablers.
Badariah Solemon 2011
Design Evaluation (cnt’d)3) Modification and maintenance time are more
important than creation time. Because:
1. time spent in maintenance is much more than creation time of a software, and
2. in iterative development, modification happens during the initial creation of the software.
4) Design quality is unpredictable. Because quality is really dependant on the team
developing the software. As the team changes, or evolves, then the design quality also evolves.
You really only know how good a design is by it standing the test of time and modifications.
Badariah Solemon 2011
Design Evaluation (cnt’d)
• Points to ponder: to maintain the quality of the design,
we must maintain the theory of the design as the programming team evolves,
That design quality is tied to the people who are building and maintaining the software(Shore and Chromatic, 2007).
Badariah Solemon 2011
Design Specification IEEE Standard for Information Technology -
Systems Design - Software Design Descriptions (IEEE 1016-2009) an improved version of the 1998 version.
This standard specifies an organizational structure for a software design description (SDD).
An SDD is a document used to specify system architecture and application design in a software related project.
Provides a generic template for an SDD.
Badariah Solemon 2011
SDD: Examples
• Refer to http://www.cs.uofs.edu/~dmartin/exsesrm.htm#_Toc514249734
• Refer to SDDSample.doc
Badariah Solemon 2011
Summary• This module has:
– Introduced set of design principles, concepts, and practices.
– Described four design models required for a complete design specification: data design, architectural design, user interface design, and component-level design.
– Introduced design support tools and evaluation.– Introduced design specification document (SDD).
Badariah Solemon 2011
References
• Pressman, R. (2003). Software Engineering: A Practitioner's Approach. 6th & 5th edition. New York: McGraw-Hill.
• Somerville I. (2001). Software Engineering. 6th edition. Addison Wesley • http://www.allinterview.com/showanswers/66313.html• http://www.augustana.ab.ca/~mohrj/courses/2006.winter/csc120/
slides/ch09/ch09.html• http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=78 • Shore, J. and Chromatic, (2007). The Art of Agile Development. O'Reilly
Media.• Elssamadisy, A. (2007). Defining Design Quality.
http://www.infoq.com/news/2007/04/defining-design-quality
Badariah Solemon 2011