770 likes | 891 Views
Chapter 6. Software Design and design methodology. Software Design. Deriving a solution which satisfies software requirements. Stages of Design. Problem understanding เข้าใจปัญหา Look at the problem from different angles to discover the design requirements.
E N D
Chapter 6 Software Design and design methodology
Software Design Deriving a solution which satisfies software requirements
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.
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. ออกแบบลำดับแบบซ้อน
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.
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
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สามารถติต่อกับดมดูลอื่นหรือไม่
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
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 Less well-suited to distributed, non-terminating systems - e.g., process control systems, operating systems like WinNT, ATM machines Well-suited to certain application domains - e.g., compilers
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.
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. conde (tong-kao-jai) kan pong kunCom
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
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.
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
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.
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.
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.
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.
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.
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- ( interfaces)
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.
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
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!
Coupling • 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 and Inheritance 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.
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.
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.
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.
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
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. จำนวนกิจกรรมภายในโมดูล
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.
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.
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.
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
Assignment in Design Methodology • Procedural Design • Interface design • Architecture Design • Data Design
1. Procedural Design • Procedural Abstraction +Stepwise Refinement (pseudo code) • Modularity (Modular Design) • Software Procedure
Software Procedural Design เน้นรายละเอียดในการประมวลผลแต่ละโมดูล ลำดับเหตุการณ์ จุดตัดสินใจ การทำงานซ้ำ โครงสร้างข้อมูล
Module A
Module A
Procedural Abstraction เป็นการคิดแยกรายละเอียดของปัญหา ออกเป็นระดับที่ชัดเจน
Procedural Abstraction “Enter” 1. เดินไปที่ประตู 2. ยื่นมือไปที่ลูกบิด 3. หมุนลูกบิด 4. ดึงประตู 5. เดินเข้าประตู
ซอฟต์แวร์คำนวณหาพื้นที่ของสามเหลี่ยม ซอฟต์แวร์คำนวณหาพื้นที่ของสามเหลี่ยม Abstraction ระดับที่ 2 • งานรับข้อมูลส่วนสูง, ฐาน • งานตรวจเช็คข้อมูล เท่ากับศูนย์ หรือติดลบหรือไม่ • งานคำนวณตามสูตร • งานแสดงผล
Stepwise Refinement • ออกแบบในลักษณะ Top-down • ขยายรายละเอียดเป็นลำดับขั้น (Hierarchy)
Stepwise Refinement open walk to door; reach for knob; open door; repeat until door opens turn knob clockwise; walk through; if knob doesn't turn, then close door. take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat