Upload
judith-thatch
View
222
Download
1
Tags:
Embed Size (px)
Citation preview
Software Engineering, 254451 Slide 1
Chapter 6
Software Design and design methodology
Software Engineering, 254451 Slide 2
Software Design
Deriving a solution which satisfies software requirements
Software Engineering, 254451 Slide 3
Stages of Design
• Problem understanding เข้�าใจปั�ญหา– Look at the problem from different angles to discover the
design requirements.
• Identify one or more solutions หาวิ�ธี�การหนึ่��งหร�อมากกวิ�า– Evaluate possible solutions and choose the most appropriate depending on the
designer's experience and available resources.
• Describe solution abstractions อธี�บายวิ�ธี�– Use graphical, formal or other descriptive notations to
describe the components of the design.
• Repeat process for each identified abstraction ทำ�าซ้ำ��าprocessแต่�ละอ#นึ่until the design is expressed in primitive- fundamental terms.
Software Engineering, 254451 Slide 4
The Design Process
• Any design may be modelled as a directed graph made up of entities with attributes which participate in relationships.
• The system should be described at several different levels of abstraction. อธี�บายระบบออกมาเปั$นึ่ระดั#บ
• Design takes place in overlapping stages. It is artificial to separate it into distinct phases but some separation is usually necessary. ออกแบบล�าดั#บแบบซ้ำ�อนึ่
Software Engineering, 254451 Slide 5
Phases in the Design Process
Architecturaldesign
Abstractspecificatio
n
Interfacedesign
Componentdesign
Datastructuredesign
Algorithmdesign
Systemarchitecture
Softwarespecification
Interfacespecification
Componentspecification
Datastructure
specification
Algorithmspecification
Requirementsspecification
Design activities
Design products
Software Engineering, 254451 Slide 6
Design Phases
• Architectural design: Identify sub-systems. ระบ&sub sys
• Abstract specification: Specify -ก�าหนึ่ดั sub-systems. ก�าหนึ่ดัsub sys
• Interface design: Describe sub-system interfaces. ออกแบบsub interface
• Component design: Decompose sub-systems into components. แต่กระบบออกมา(SA)
• Data structure design: Design data structures to hold problem data. ออกแบบdata (DB)
• Algorithm design: Design algorithms for problem functions.
Software Engineering, 254451 Slide 7
Procedural Abstraction
• The most obvious design methods involve functional decomposition. แต่กออกมาเปั$นึ่ส่�วินึ่ย�อยๆ
• This leads to programs in which procedures represent distinct logical functions in a program.
• Examples of such functions:– “Display menu”– “Get user option”
• This is called procedural abstraction
Software Engineering, 254451 Slide 8
Design
• Computer systems are not monolithic -massive : they are usually composed of multiple, interacting modules.
• Modularity has long been seen as a key to cheap, high quality software.
• The goal of system design is to decode:– What the modules are; ม�โมดั&ลอะไรบ�าง– What the modules should be; โมดั+ลทำ�าอะไร– How the modules interact with one-another ส่ามารถต่�ต่�อก#บดัม
ดั+ลอ��นึ่หร�อไม�
Software Engineering, 254451 Slide 9
Modular programming
• In the early days, modular programming was taken to mean constructing programs out of small pieces: “subroutines”
• But modularity cannot bring benefits unless the modules are – Coherent ซ้ำ��งส่อดัคล�อง , ไม�ข้#ดัแย�งในึ่ต่#วิเอง – Autonomous ซ้ำ��งอย+�ไดั�ดั�วิยต่นึ่เอง , ซ้ำ��งม�อ�ส่ระในึ่การ
เล�อก – Robust
Software Engineering, 254451 Slide 10
Programs as Functions
• Another view is programs as functions:
input output
x f f (x) the program is viewed as a function from a set I of legal inputs to a set O of outputs.
• There are programming languages (ML, Miranda, LISP) that directly support this view of programming
Well-suited to certain application domains - e.g., compilers
Less well-suited to distributed, non-terminating systems - e.g., process control systems, operating systems like WinNT, ATM machines
Software Engineering, 254451 Slide 11
Object-Oriented Design
– The system is viewed as a collection of interacting objects.
– The system state is decentralized and each object manages its own state.
– Objects may be instances of an object class and communicate by exchanging
methods.
Software Engineering, 254451 Slide 12
Five Criteria for Design Methods
• We can identify five criteria to help evaluate modular design methods (Pucc-D):– Modular decomposability;– Modular composability;– Modular understandability;– Modular continuity;– Modular protection.con de (tong-kao-jai) kan pong kun Com
Software Engineering, 254451 Slide 13
Modular Decomposability
• This criterion is met by a design method if the method supports the decomposition of a problem into smaller sub-problems, which can be solved independently.
• In general method will be repetitive: sub-problems will be divided still further
• Top-down design methods fulfil this criterion; stepwise -ทำ�ละชั้#�นึ่ refinement is an example of such method
Software Engineering, 254451 Slide 14
Top-down Design
• In principle, top-down design involves starting
at the uppermost components in the hierarchy and working down the hierarchy level by level.
• In practice, large systems design is never truly top-down. Some branches are designed before others. Designers reuse experience (and sometimes components) during the design process.
Software Engineering, 254451 Slide 15
Hierarchical Design Structure
System level
Sub-systemlevel
Software Engineering, 254451 Slide 16
Modular Composability
• A method satisfies this criterion if it leads to the production of modules that may be freely combined to produce new systems.
• Composability is directly related to the issue of reusability • Note that composability is often at odds โอกาส่ทำ��จะเปั$นึ่ไปัไดั�
with decomposability; top-down design, – for example, tends to produce modules that may not be composed
in the way desired
• This is because top-down design leads to modules which fulfil a specific function, rather than a general one
Software Engineering, 254451 Slide 17
Examples
• The Numerical Algorithm Group (NAG) libraries contain a wide range of routines for solving problems in linear algebra, differential equations, etc.
• The Unix shell provides a facility called a pipe, written “”, whereby – the standard output of one program may be
redirected to the standard input of another; this convention favours composability.
Software Engineering, 254451 Slide 18
Modular Understandability
• A design method satisfies this criterion if it encourages the development of modules which are easily understandable.
• COUNTER EXAMPLE 1. Take a thousand lines program, containing no procedures; it’s just a long list of sequential statements. Divide it into twenty blocks, each fifty statements long; make each block a method.
• COUNTER EXAMPLE 2. “Go to” statements.
Software Engineering, 254451 Slide 19
Understandability
• Related to several component characteristics– Can the component be understood on its own?– Are meaningful names used?– Is the design well-documented?– Are complex algorithms used?
• Informally, high complexity means many relationships between different parts of the design.
Software Engineering, 254451 Slide 20
Modular Continuity
• A method satisfies this criterion if it leads to the production of software such that a small change in the problem specification leads to a change in just one (or a small number of ) modules.
• EXAMPLE. Some projects enforce the rule that no numerical or textual literal should be used in programs: only symbolic constants should be used
• COUNTER EXAMPLE. Static arrays (as opposed to open arrays) make this criterion harder to satisfy.
Software Engineering, 254451 Slide 21
Modular Protection
• A method satisfied this criterion if it yields architectures in which the effect of an abnormal condition at run-time only effects one (or very few) modules
• EXAMPLE. Validating input at source prevents errors from propagating -แพร�พ#นึ่ธี&0 throughout the program.
• COUNTER EXAMPLE. Using int types where subrange or short types are appropriate.
Software Engineering, 254451 Slide 22
Five principles for Good Design
• From the discussion above, we can distil -refine five principles that should be adhered -ย�ดัม#�นึ่ to:– Linguistic modular units; – Few interfaces; ม�ให�นึ่�อย– Small interfaces ม�ให�เล1ก– Explicit interfaces; ชั้#ดัเจนึ่– Information hiding.
Information tee-nae-non(ชั้#ดัเจนึ่) kiew kub Ling – tua-lek (small), mee noi mak (few)
FES- ( interfaces)
Software Engineering, 254451 Slide 23
Linguistic Modular Units
• A programming language (or design language) should support the principle of linguistic modular units:– Modules must correspond to linguistic units in the language used
• EXAMPLE. Java methods and classes• COUNTER EXAMPLE. Subroutines in BASIC are called
by giving a line number where execution is to proceed from; there is no way of telling, just by looking at a section of code, that it is a subroutine.
Software Engineering, 254451 Slide 24
Few Interfaces
• This principle states that the overall number of communication channels between modules should be as small as possible:– Every module should communicate with as few others
as possible.
• So, in the system with n modules, there may be a minimum of n-1 and a maximum of links; your system should stay closer to the minimum
2
)1( nn
Software Engineering, 254451 Slide 25
Few Interfaces
Software Engineering, 254451 Slide 26
Small Interfaces (Loose Coupling)
• This principle states:– If any two modules communicate, they should
exchange as little information as possible. การแลกเปัล��ยนึ่ข้�อม&ลระหวิ�างดัมดั+ลให�นึ่�อย
• COUNTER EXAMPLE. Declaring all instance variables as public!
Software Engineering, 254451 Slide 27
• A measure of the strength of the inter-connections between system components. ควิามส่#มพ#นึ่0ระหวิ�างโมดั+ล
• Loose coupling means component changes are unlikely to affect other components.– Shared variables or control information exchange lead to
tight coupling.– Loose coupling can be achieved by state decentralization
(as in objects) and component communication via parameters or message passing.
Coupling
Software Engineering, 254451 Slide 28
Tight Coupling
Module A Module B
Module C Module D
Shared dataarea
Software Engineering, 254451 Slide 29
Loose Coupling
Module A
A’s data
Module B
B’s data
Module D
D’s data
Module C
C’s data
Software Engineering, 254451 Slide 30
• Object-oriented systems are loosely coupled because there is no shared state and objects communicate using message passing.
• However, an object class is coupled to its super-classes. Changes made to the attributes or operations in a super-class propagate to all sub-classes.
Coupling and Inheritance
Software Engineering, 254451 Slide 31
Reusability
• A major obstacle to the production of cheap quality software is the intractability of the reusability issue.
• Why isn’t writing software more like producing hardware? Why do we start from scratch every time, coding similar problems time after time after time?
• Obstacles:– Economic;
– Organizational;
– Psychological.
Software Engineering, 254451 Slide 32
Stepwise Refinement
• The simplest realistic design method, widely used in practice.
• Not appropriate for large-scale, distributed systems: mainly applicable to the design of methods.
• Basic idea is:– Start with a high-level spec of what a method is to achieve;– Break this down into a small number of problems (usually no
more than 10)– For each of these problems do the same;– Repeat until the sub-problems may be solved immediately.
Software Engineering, 254451 Slide 33
Explicit Interfaces
• If two modules must communicate, they must do it so that we can see it:– If modules A and B communicate, this must be
obvious from the text of A or B or both.
• Why? If we change a module, we need to see what other modules may be affected by these changes.
Software Engineering, 254451 Slide 34
Information Hiding
• This principle states: ข้�อม&ลซ้ำ�อนึ่– All information about a module, (and particularly how the
module does what it does) should be private to the module unless it is specifically declared otherwise.
• Thus each module should have some interface, which is how the world sees it anything beyond that interface should be hidden.
• The default Java rule:– Make everything private
Software Engineering, 254451 Slide 35
Cohesion
A measure of how well a component “fits together”.
• A component should implement a single logical entity or function.
• Cohesion is a desirable design component attribute as when a change has to be made, it is localized in a single cohesive component.
• Various levels of cohesion have been identified. จ�านึ่วินึ่ก�จกรรมภายในึ่โมดั+ล
Software Engineering, 254451 Slide 36
Cohesion Levels
• Coincidental cohesion (weak)– Parts of a component are simply bundled together.
• Logical association (weak)– Components which perform similar functions are
grouped.
• Temporal cohesion (weak)– Components which are activated at the same time
are grouped.
Software Engineering, 254451 Slide 37
Cohesion Levels• Communicational cohesion (medium)
– All the elements of a component operate on the same input or produce the same output.
• Sequential cohesion (medium)– The output for one part of a component is the input to another part.
• Functional cohesion (strong)– Each part of a component is necessary for the execution of a single
function.
• Object cohesion (strong)– Each operation provides functionality which allows object
attributes to be modified or inspected.
Software Engineering, 254451 Slide 38
Cohesion as a Design Attribute
• Not well-defined. Often difficult to classify cohesion.
• Inheriting attributes from super-classes weakens cohesion.– To understand a component, the super-classes
as well as the component class must be examined.
– Object class browsers assist with this process.
Software Engineering, 254451 Slide 39
Assignment
• 2 students in the Group Project work out for each Design
• 4 designs have to be done (explain next)• Report (Final Revision from 4 Designs)
- abstract (why design for each work)- conclusion and further work (mistake, development, suggestion)
• Presentation
Software Engineering, 254451 Slide 40
Entity-Relationship
Diagram
Data FlowDiagram
State-TransitionDiagram
Data Dictionary
Process Specification (PSPEC)
Control Specification (CSPEC)
Data Object Description
THE ANALYSIS MODEL
proceduraldesign
interfacedesign
architecturaldesign
datadesign
THE DESIGN MODEL
Software Engineering, 254451 Slide 41
Assignment in Design Methodology
• Procedural Design
• Interface design
• Architecture Design
• Data Design
Software Engineering, 254451 Slide 42
1. Procedural Design
• Procedural Abstraction +Stepwise Refinement (pseudo code)
• Modularity (Modular Design)
• Software Procedure
Software Engineering, 254451 Slide 43
Software Procedural Design
เนึ่�นึ่รายละเอ�ยดัในึ่การปัระมวิลผลแต่�ละโมดั+ล• ล�าดั#บเหต่&การณ์0• จ&ดัต่#ดัส่�นึ่ใจ• การทำ�างานึ่ซ้ำ��า• โครงส่ร�างข้�อม+ล
Software Engineering, 254451 Slide 44
ModuleA
Software Engineering, 254451 Slide 45
ModuleA
Software Engineering, 254451 Slide 46
เปั$นึ่การค�ดัแยกรายละเอ�ยดัข้องปั�ญหาออกเปั$นึ่ระดั#บทำ��ชั้#ดัเจนึ่
Procedural Abstraction
Software Engineering, 254451 Slide 47
“Enter” 1. เดั�นึ่ไปัทำ��ปัระต่+ 2 . ย��นึ่ม�อไปัทำ��ล+กบ�ดั 3 . หม&นึ่ล+กบ�ดั 4 . ดั�งปัระต่+ 5 . เดั�นึ่เข้�าปัระต่+
Procedural Abstraction
Software Engineering, 254451 Slide 48
•งานึ่ร#บข้�อม+ลส่�วินึ่ส่+ง , ฐานึ่• งานึ่ต่รวิจเชั้1คข้�อม+ล
เทำ�าก#บศู+นึ่ย0 หร�อต่�ดัลบหร�อไม�• งานึ่ค�านึ่วิณ์ต่ามส่+ต่ร• งานึ่แส่ดังผล
Abstraction ระดั#บทำ��2
ซ้ำอฟต่0แวิร0ค�านึ่วิณ์หาพ��นึ่ทำ��ข้องส่ามเหล��ยม
Software Engineering, 254451 Slide 49
Stepwise Refinement
• ออกแบบในึ่ล#กษณ์ะ Top-down• ข้ยายรายละเอ�ยดัเปั$นึ่ล�าดั#บข้#�นึ่
(Hierarchy)
Software Engineering, 254451 Slide 50
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
Stepwise Refinement
Software Engineering, 254451 Slide 51
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Program
Software Engineering, 254451 Slide 52
Modularity
การแบ�งซ้ำอฟต่0แวิร0ออกเปั$นึ่ส่�วินึ่ๆ เร�ยกวิ�า Mudule
• ชั้��อ• องค0ปัระกอบ
Software Engineering, 254451 Slide 53
ควิามเปั$นึ่อ�ส่ระ
โมดั+ล
Modular Design
Software Engineering, 254451 Slide 54
Modular Types
• Sequence Module• Increment Module• Parallel Module
Software Engineering, 254451 Slide 55
Sequence Module
• Subroutine• Function• Procedure
Software Engineering, 254451 Slide 56
2. Architecture Design
• Software Architecture
- system as a whole, e.g. figure of Client/Server
• Hierarchy Design
- Control Hierarchy
Software Engineering, 254451 Slide 57
Software Architecture Design
• the hierarchical structure of module• the structure of data
Software Engineering, 254451 Slide 58
P1P2
P3P4
P5
S1 S4 S
5
S2
S3
Software Engineering, 254451 Slide 59
S5
S4
S3
S2
S1
S3
S2
S1
P
Software Engineering, 254451 Slide 60
Control Hierarchy
จ#ดัล�าดั#บข้องโมดั+ลต่�างๆในึ่โปัรแกรมให�อย+�ในึ่ล#กษณ์ะข้องการควิบค&มทำ��เปั$นึ่ล�าดั#บ(Hierarchy of control)
“Program Structure”
Software Engineering, 254451 Slide 61
M
n
o
p
q
f g
h
a
d
e
l m
b
c
i j
k
r
Fan
- Fan out
Width
Depth
- in
Software Engineering, 254451 Slide 62
- Fan out
Width
Depth
- Fan in
จ�านึ่วินึ่ระดั#บ (level ) ข้องการควิบค&ม(control)
ควิามกวิ�าง,ส่�วินึ่ทำ��ม�ระยะกวิ�างมากทำ��ส่&ดัจ�านึ่วินึ่โมดั+ลทำ��ถ+กควิบค&มโดัยต่รงโดัยโมดั+ลหนึ่��งๆจ�านึ่วินึ่โมดั+ลทำ��ควิบค&มโมดั+ลหนึ่��งๆ
Software Engineering, 254451 Slide 63
M is Superordinate to a , b , c
h is Subordinate to e
Software Engineering, 254451 Slide 64
3. Interface Design (GUI)
– WIMP (Windows, Icons, Mouse and Pointing device)
has conceptual structure representing screen of functions, which is implemented using control screen and interface structure called WIMP
– Human machine interface (HMI) are intelligent operator interface terminals, which allow the user to interact with an HMI unit and use it to control other devices.
Effectiveness? Efficiency? Satisfaction?
Software Engineering, 254451 Slide 65
Graphic User Interface (GUI)
Software Engineering, 254451 Slide 66
HMI
Software Engineering, 254451 Slide 67
Software Engineering, 254451 Slide 68
Interface Design
Software Engineering, 254451 Slide 69
4. Data Design
• Data Abstraction
• Data relational system (Figure of each Table links one to another)
• Data Entity/Data Structure
Software Engineering, 254451 Slide 70
“Paycheck” 1. ชั้��อผ+�ส่# �งจ�าย 2. จ�านึ่วินึ่เง�นึ่ 3. วิ#นึ่ , เดั�อนึ่ , ปั; 4. ธีนึ่าคารทำ��จ�าย
ฯลฯ
Data Abstraction
Software Engineering, 254451 Slide 71
Data Structure
อธี�บายถ�งควิามส่#มพ#นึ่ธี0ทำางต่รรกะข้องข้�อม+ลในึ่ระบบ
Software Engineering, 254451 Slide 72
โครงส่ร�างข้�อม+ลม�ผลกระทำบโดัยต่รงต่�อโครงส่ร�างข้องระบบ • การเข้�าถ�งข้�อม+ล
• การปัระมวิลผล• วิ�ธี�การ ฯลฯ
Software Engineering, 254451 Slide 73
Data Design/Selection
Baptism1.parish_code 2 date 3 forename 4 sex 5 father_forename 6 mother_forename 7 surname 8 residence 9 illegitimacy 10 ill_fathers_sname 11 ill_fathers_occupation 12 ill_fathers_residence 13 date_of_birth 14 age 15 alternate_sname
Marriage1 parish_code 2 date 3 groom_fname 4 groom_sname 5 groom_status 6 groom_occupation 7 groom_resid 8 groom_age 10 bride_fname 11 bride_sname 12 bride_status 13 bride_resid 14 bride_age
Burial1 parish_code 2 date 3 forename 4 surname 5 sex 6 status 7 residence 8 relationship 9 illegitimacy 10 kin_fname_1 11 kin_fname_2 12 kin_sname 13 kin_occupation 14 kin_res 15 date_of_death 16 age
Software Engineering, 254451 Slide 74
Example of Baptism link Marriage
Software Engineering, 254451 Slide 75
Example of linkage e.g. baptism to marriage linkage as a query prototype:
Software Engineering, 254451 Slide 76
• Cohesion• Coupling
มาต่รวิ#ดัค&ณ์ภาพข้องควิามเปั$นึ่อ�ส่ระ
Software Engineering, 254451 Slide 77
ผ+�ออกแบบควิรหล�กเล��ยง
• Low Cohesion Spectrum• High Coupling Spectrum