Date post: | 11-Dec-2015 |
Category: |
Documents |
Upload: | jamar-speed |
View: | 219 times |
Download: | 2 times |
Lecture 6:Lecture 6: Software Design Software Design (Part I)(Part I)
Dr Valentina PlekhanovaDr Valentina Plekhanova
University of Sunderland, UKUniversity of Sunderland, UK
http://www.cet.sunderland.ac.uk/~cs0vpl/SE-Com185.htmhttp://www.cet.sunderland.ac.uk/~cs0vpl/SE-Com185.htm
Lecture 6 Valentina Plekhanova 2
Design Process: DefinitionDesign Process: Definition The next step after requirements analysis and
specification is software designsoftware design. “DesignDesign is the creative process of transforming
the problem into a solution; the description of a solution is also called designdesign.” [Pfleeger, 1998]
DesignDesign is a process of constructing preliminary is a process of constructing preliminary models for producing an expected models for producing an expected product/software/program. product/software/program.
Design processDesign process defines several models of the systems at different levels of abstraction.
Lecture 6 Valentina Plekhanova 3
Principles of Software Design: Principles of Software Design: Abstraction and DecompositionAbstraction and Decomposition AbstractionAbstraction is an expression that shows the
most important information of the program without telling its implementation details.
DecompositionDecomposition is a way to divide a big task into small tasks, and to develop details of an abstraction. The benefit of decomposition is to reduce the complexity of programs.
Lecture 6 Valentina Plekhanova 4
Principles of Software Design: Principles of Software Design: Decomposition and ModularityDecomposition and Modularity Every design method involves some kind of
decomposition: starting with a high levelhigh level depiction of the system’s key elements and creating lower levellower level looks at how the system’s features and functions will fit together [Pfleeger, 1998].
ModularityModularity is a property that a program consists of many independent modules. A modulemodule is a modest-sized component that performs independently specific functions.
Lecture 6 Valentina Plekhanova 5
Principles of Software Design: Principles of Software Design: Encapsulation & Information HidingEncapsulation & Information Hiding EncapsulationEncapsulation is the grouping of related
ideas into one unit, which can thereafter be referred to by a single name.
Information hidingInformation hiding is the use of encapsulation to restrict from external visibility certain information or implementation decisions that are internal to the encapsulation structure.
Lecture 6 Valentina Plekhanova 6
Design Levels & Design MethodsDesign Levels & Design Methods Design -> Abstract Design & Detailed DesignDesign -> Abstract Design & Detailed Design Abstract DesignAbstract Design: different methods can be
used, e.g. top down design, modular design, structured design, etc.
Detailed DesignDetailed Design, e.g. high level design, low level design.
Lecture 6 Valentina Plekhanova 7
Conceptual Design & Technical DesignConceptual Design & Technical Design This stage is concerned with planning how to
build the software itself. Conceptual designConceptual design tells the customer exactly
what the system will do (i.e. WhatWhat? – conceptual design concentrates on the system’s functions).
Technical designTechnical design allows system builders to understand the actual hardware and software needed to solve the customers’ problem (i.e. HowHow? – technical design describes the form the system will take) [Pfleeger, 1998]
Lecture 6 Valentina Plekhanova 8
ArchitectureArchitecture Architecture Architecture associates the system
capabilities identified in the requirements specification with the system components that will implement them.
ComponentsComponents are usually modules, and the architecture also describes the interconnections among them.
Lecture 6 Valentina Plekhanova 9
CohesionCohesion CohesionCohesion is an internal property of a module -
level of relationships between elements of the module.
We say that a module has high cohesionhigh cohesion if all of its elements (e.g. procedures, statements) are related strongly in a logical way.
They cooperate to achieve a common goal, which is the function of the module.
Lecture 6 Valentina Plekhanova 10
CouplingCoupling CouplingCoupling characterises interrelationship
among modules in a software, i.e. represents a module’s relationship to other modules.
With low coupling we can analyse, modify, test, and reuse modules separately.
Lecture 6 Valentina Plekhanova 11
Cohesion and CouplingCohesion and Coupling CohesionCohesion and CouplingCoupling are used for
measurement of independence of elements/modules in a design, i.e. assessment of design quality [Yourdon and Constantine, 1978]
The goal of software engineergoal of software engineer is to design the modules with high cohesion and low coupling.
Lecture 6 Valentina Plekhanova 12
Design MethodsDesign Methods Top down designTop down design Bottom up designBottom up design Modular designModular design Structured designStructured design Object oriented designObject oriented design
Lecture 6 Valentina Plekhanova 13
Top-down DesignTop-down Design Top-down design supports the abstract and
decomposition principle. By this design method, a system is first
abstracted as a high level unit (e.g. module, process, procedure, function), and then decomposed into low level units, possibly integrated together using some constructs.
Lecture 6 Valentina Plekhanova 14
Top-down Software DesignTop-down Software Design We begin by considering the problem to be
computerised as a whole and identify its major components.
For each component we then do the same – identify what its major sub-components are
Each of the sub-components can then be broken down into its sub-components and so on, until we reach a level whereby the individual pieces can be understood and designed without any difficulty.
Lecture 6 Valentina Plekhanova 15
Top-down DesignTop-down Design This process of top-down designtop-down design (also
called stepwise refinementstepwise refinement) is a way to manage complexity.
We are able to create user-defined functions and general procedures to carry out subtasks.
Lecture 6 Valentina Plekhanova 16
Top-down Design:Top-down Design: Reasons for Use Reasons for Use Systemic way of breaking a large
system/problem into the smaller manageable parts.
Easier to understand the system/problem. Easier to test these smaller parts.
Lecture 6 Valentina Plekhanova 17
Top-down Design: An ExampleTop-down Design: An Example
Project
Task 1 Task 3 Task 4Task 2
Subtask 1.1 Subtask 2.1 Subtask 2.2 Subtask 4.1 Subtask 4.2 Subtask 4.3
Subtask 2.2.1 Subtask 4.2.1
Subtask 4.2.1.1
Lecture 6 Valentina Plekhanova 18
Object-Oriented DesignObject-Oriented Design Object-oriented designObject-oriented design is a way of designing a
program system by focusing on the design of objects and their integration.
An objectAn object is an encapsulation of attributes and operations (or methods); it takes inputs and performs some functions. In fact, an object is a In fact, an object is a kind of module.kind of module.
An object-oriented program can be regarded as a network of objects that interact with each other by means of sending and receiving messages (which are similar to calling methods in Java).
Lecture 6 Valentina Plekhanova 19
Design LevelsDesign Levels High Level DesignHigh Level Design Low Level DesignLow Level Design
Lecture 6 Valentina Plekhanova 20
High-level DesignHigh-level Design One way to represent high-level designhigh-level design is
to use a hierarchical structure chart where each box on the chart represents a component or subtask of the program.
A high-level algorithm may be presented either in pseudocodepseudocode or with structure structure chartscharts, and it should be language independent.
Lecture 6 Valentina Plekhanova 21
High Level Design: Structure ChartHigh Level Design: Structure Chart
A
DA
B
C
Lecture 6 Valentina Plekhanova 22
High Level DesignHigh Level Design High level design documents such as High level design documents such as
structure charts structure charts showshow: : the overall system designthe overall system design how the program is decomposed into separate how the program is decomposed into separate
modulesmodules which modules call which other oneswhich modules call which other ones how they communicate via datahow they communicate via data
Lecture 6 Valentina Plekhanova 23
High Level DesignHigh Level Design they do they do notnot show:show: the order in which the modules are calledthe order in which the modules are called the number of times they are called if it’s more the number of times they are called if it’s more
than oncethan once the condition(s) determining optional/conditional the condition(s) determining optional/conditional
invocationinvocation the internal workings of the modulesthe internal workings of the modules
Lecture 6 Valentina Plekhanova 24
High-level DesignHigh-level Design High-level program design involves the
identification of components of our program - task, subtasks and decisions about how information flows between them.
We need to make decisions about the type of data to be used, names for variables and where to declare them (local, form-level, module or global variables), and what type of data structures and external data storage requirements are required.
Lecture 6 Valentina Plekhanova 25
High-level DesignHigh-level Design At the end of high-level design we will have decided the
forms, objects, procedures and functions needed and where code needs to be added to carry out the work of the program.
All of these decisions may take several passes through the design process, each time round, adding more detail.
It is a process of spiralling down from the requirement level to the code level - though at this stage we do not have to worry about the details of the low-level code for the procedures and functions.
Lecture 6 Valentina Plekhanova 26
High-level Design: High-level Design: RepresentationRepresentation We can represent out high-level design
decisions by the use of a structure chart which act as a 'picture' of all the software 'parts' making up the program.
Additional information can be placed on a structure chart to show the flow of data between the different parts.
Lecture 6 Valentina Plekhanova 27
High-level Design: High-level Design: An ExampleAn Example
Project (a,b,e,r, z, x,…)
Task 1 (a,b,c,d)
a,ba,b
c,dc,d
Subtask 1.1
Task 2 (e,r,t,y,p)
e,re,r
Subtask 2.1 (t,y,p,w)
t,y,pt,y,p
Function 2.1.Aw
Lecture 6 Valentina Plekhanova 28
Week 8:Week 8: 24.04.2003-28.04.2003 24.04.2003-28.04.2003Project Control SessionProject Control Session Tutorial Time: 10 minutes for each Team Tutorial Time: 10 minutes for each Team Students will present project file, particularly
ScheduleSchedule, plus any project documentationdocumentation. Students will describe where they are in the
project and any problems encountered. During the discussion reviewers will ask to see
evidence of deliverables for any tasks that are complete to determine whether they have in fact been done.