Presentation is loading. Please wait.

Presentation is loading. Please wait.

Software Engineering, 254451 Slide 1 Chapter 6 Software Design and design methodology.

Similar presentations


Presentation on theme: "Software Engineering, 254451 Slide 1 Chapter 6 Software Design and design methodology."— Presentation transcript:

1 Software Engineering, Slide 1 Chapter 6 Software Design and design methodology

2 Software Engineering, Slide 2 Software Design Deriving a solution which satisfies software requirements

3 Software Engineering, 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.

4 Software Engineering, 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. ออกแบบลำดับแบบซ้อน

5 Software Engineering, Slide 5 Phases in the Design Process

6 Software Engineering, 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.

7 Software Engineering, 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

8 Software Engineering, 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 สามารถติต่อกับดม ดูลอื่นหรือไม่

9 Software Engineering, 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

10 Software Engineering, 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

11 Software Engineering, 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.

12 Software Engineering, 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

13 Software Engineering, 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

14 Software Engineering, 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.

15 Software Engineering, Slide 15 Hierarchical Design Structure

16 Software Engineering, 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

17 Software Engineering, 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.

18 Software Engineering, 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.

19 Software Engineering, 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.

20 Software Engineering, 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.

21 Software Engineering, 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 - แพร่พันธุ์ throughout the program. COUNTER EXAMPLE. Using int types where subrange or short types are appropriate.

22 Software Engineering, 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 มีให้เล็ก –Explicit interfaces; ชัดเจน –Information hiding. Information tee-nae-non( ชัดเจน ) kiew kub Ling – tua-lek (small), mee noi mak (few) FES- ( inter f ac es )

23 Software Engineering, 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.

24 Software Engineering, 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

25 Software Engineering, Slide 25 Few Interfaces

26 Software Engineering, 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!

27 Software Engineering, Slide 27 A measure of the strength of the inter-connections between system components. ความสัมพัน์ระหว่าง โมดูล 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

28 Software Engineering, Slide 28 Tight Coupling

29 Software Engineering, Slide 29 Loose Coupling

30 Software Engineering, 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

31 Software Engineering, 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.

32 Software Engineering, 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.

33 Software Engineering, 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.

34 Software Engineering, 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

35 Software Engineering, 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. จำนวนกิจกรรมภายในโมดูล

36 Software Engineering, 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.

37 Software Engineering, 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.

38 Software Engineering, 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.

39 Software Engineering, 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

40 Software Engineering, Slide 40

41 Software Engineering, Slide 41 Assignment in Design Methodology Procedural Design Interface design Architecture Design Data Design

42 Software Engineering, Slide Procedural Design Procedural Abstraction +Stepwise Refinement (pseudo code) Modularity (Modular Design) Software Procedure

43 Software Engineering, Slide 43 Software Procedural Design เน้นรายละเอียดในการประมวลผลแต่ละโมดูล ลำดับเหตุการณ์ จุดตัดสินใจ การทำงานซ้ำ โครงสร้างข้อมูล

44 Software Engineering, Slide 44 Modu le A

45 Software Engineering, Slide 45 Module A

46 Software Engineering, Slide 46 เป็นการคิดแยกรายละเอียดของปัญหา ออกเป็นระดับที่ชัดเจน Procedural Abstraction

47 Software Engineering, Slide 47 “Enter” 1. เดินไปที่ประตู 2. ยื่นมือไปที่ลูกบิด 3. หมุนลูกบิด 4. ดึงประตู 5. เดินเข้าประตู Procedural Abstraction

48 Software Engineering, Slide 48 งานรับข้อมูลส่วนสูง, ฐาน งานตรวจเช็คข้อมูล เท่ากับศูนย์ หรือติดลบหรือไม่ งานคำนวณตามสูตร งานแสดงผล Abstraction ระดับที่ 2 ซอฟต์แวร์คำนวณหาพื้นที่ของสามเหลี่ยม

49 Software Engineering, Slide 49 Stepwise Refinement ออกแบบในลักษณะ Top-down ขยายรายละเอียดเป็นลำดับขั้น (Hierarchy)

50 Software Engineering, Slide 50 open walk to door; reach for knob; open door; walk through; close door. repeat until door opens turn knob clockwise; if knob doesn't turn, then take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat Stepwise Refinement

51 Software Engineering, Slide 51 xxx xx Progra m

52 Software Engineering, Slide 52 Modularity การแบ่งซอฟต์แวร์ออกเป็นส่วนๆ เรียกว่า Mudule ชื่อ องค์ประกอบ

53 Software Engineering, Slide 53 ความเป็นอิสระ โมดูล Modular Design

54 Software Engineering, Slide 54 Modular Types Sequence Module Increment Module Parallel Module

55 Software Engineering, Slide 55 Sequence Module Subroutine Function Procedure

56 Software Engineering, Slide Architecture Design Software Architecture - system as a whole, e.g. figure of Client/Server Hierarchy Design - Control Hierarchy

57 Software Engineering, Slide 57 Software Architecture Design the hierarchical structure of module the structure of data

58 Software Engineering, Slide 58 P1P1 P2P2 P3P3 P4P4 P5P5 S1S1 S4S4 S5S5 S2S2 S3S3

59 Software Engineering, Slide 59 S5S5 S4S4 S3S3 S2S2 S1S1 S3S3 S2S2 S1S1 P

60 Software Engineering, Slide 60 Control Hierarchy จัดลำดับของโมดูลต่างๆในโปรแกรมให้ อยู่ในลักษณะของการควบคุมที่เป็นลำดับ (Hierarchy of control) “Program Structure”

61 Software Engineering, Slide 61 M n o p q f g h a d e lm b c i j k r Fan Fan- out Width Depth - in

62 Software Engineering, Slide 62 Fan- out Width Depth Fan - in จำนวนระดับ (level) ของการควบคุม (control) ความกว้าง, ส่วนที่มีระยะกว้างมากที่สุด จำนวนโมดูลที่ถูกควบคุมโดยตรงโดย โมดูลหนึ่งๆ จำนวนโมดูลที่ควบคุมโมดูลหนึ่งๆ

63 Software Engineering, Slide 63 M is Superordinate to a, b, c h is Subordinate to e

64 Software Engineering, Slide 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?

65 Software Engineering, Slide 65 Graphic User Interface (GUI)

66 Software Engineering, Slide 66 HMI

67 Software Engineering, Slide 67

68 Software Engineering, Slide 68 Interface Design

69 Software Engineering, Slide Data Design Data Abstraction Data relational system (Figure of each Table links one to another) Data Entity/Data Structure

70 Software Engineering, Slide 70 “Paycheck” 1. ชื่อผู้สั่งจ่าย 2. จำนวนเงิน 3. วัน, เดือน, ปี 4. ธนาคารที่จ่าย ฯลฯ Data Abstraction

71 Software Engineering, Slide 71 Data Structure อธิบายถึงความสัมพันธ์ทางตรรกะ ของข้อมูลในระบบ

72 Software Engineering, Slide 72 โครงสร้างข้อมูล มีผลกระทบโดยตรงต่อโครงสร้างของ ระบบ การเข้าถึงข้อมูล การประมวลผล วิธีการ ฯลฯ

73 Software Engineering, Slide 73 Data Design/Selection Baptism 1.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 Marriage 1 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 Burial 1 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

74 Software Engineering, Slide 74 Example of Baptism link Marriage

75 Software Engineering, Slide 75 Example of linkage e.g. baptism to marriage linkage as a query prototype:

76 Software Engineering, Slide 76 Cohesion Coupling มาตรวัดคุณภาพของความเป็นอิสระ

77 Software Engineering, Slide 77 ผู้ออกแบบควรหลีกเลี่ยง Low Cohesion Spectrum High Coupling Spectrum


Download ppt "Software Engineering, 254451 Slide 1 Chapter 6 Software Design and design methodology."

Similar presentations


Ads by Google