Design Concepts and Principles

Slides:



Advertisements
Similar presentations
Chapter 12 User Interface Design
Advertisements

Design Concepts and Principles
Chapter 13 Design Concepts and Principles
Design Phase What’s design?
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Chapter 14: Design Method --- data and architectural design Design -- A multistep process in which representations of data structure, program structure,
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Chapter 10: Architectural Design
1 User Interface Design CIS 375 Bruce R. Maxim UM-Dearborn.
Performing User Interface Design
Design, goal of design, design process in SE context, Process of design – Quality guidelines and attributes Evolution of software design process – Procedural,
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
CS-499G 8/17/ Design Concepts and Principles.
Architectural Design.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Chapter 10 Architectural Design
Design Concepts "You can use an eraser on the drafting table or a sledge hammer on the construction site." Frank Lloyd Wright.
1 Chapter 14 Architectural Design. 2 Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a.
1 COSC 4406 Software Engineering COSC 4406 Software Engineering Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Nipissing University, 100.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.1.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
1 Chapter 14 Architectural Design 2 Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a.
Lecture 9: Chapter 9 Architectural Design
1 Chapter 15 User Interface Design. 2 Interface Design Easy to use? Easy to understand? Easy to learn?
SOFTWARE DESIGN.
SOFTWARE DESIGN Design Concepts Design is a meaningful engineering representation of something that is to be built It can be traced to a customer’s requirements.
Chapter 13 Architectural Design
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Design Concepts and Principles Instructor: Dr. Jerry Gao.
Chapter 13 Design Concepts and Principles Software Engineering: A Practitioner's Approach, 5/e.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
ARCHITECTURAL DESIGN. Why is Architecture Important? Representations of software architecture are an enabler for communication between all parties (stakeholders)
Structured Design (Yourdon) ( based on Pressman’s Chapter 14 – 5th edition or Chapter th edition) copyright © 1996, 2001, 2005 R.S. Pressman &
1 COSC 4406 Software Engineering COSC 4406 Software Engineering Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Nipissing University, 100.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10a:
1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Chapter 5:User Interface Design Concepts Of UI Interface Model Internal an External Design Evaluation Interaction Information Display Software.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Architectural Design Introduction Design has been described as a multistep process in which representations of data and program structure,
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Chapter : 9 Architectural Design
Component-Level Design and User Interface Design Departemen Ilmu Komputer IPB 2009.
February 19, February 19, 2016February 19, 2016February 19, 2016 Azusa, CA Sheldon X. Liang Ph. D. Software Engineering in CS at APU Azusa Pacific.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 10b: Architectural Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 10b:
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Chapter 9 Architectural Design. Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a software.
Design Engineering 1. Analysis  Design 2 Characteristics of good design 3 The design must implement all of the explicit requirements contained in the.
Architectural Design.
Lecture 9- Design Concepts and Principles
Software Quality Engineering
Software Engineering: A Practitioner’s Approach, 6/e Chapter 12 User Interface Design copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
CHAPTER 2 CREATING AN ARCHITECTURAL DESIGN.
Chapter 15 User Interface Design
Chapter 9 Architectural Design
Design Model Like a Pyramid Component Level Design i n t e r f a c d s
Lecture 9- Design Concepts and Principles
Chapter 9 Design Engineering
Design Engineering.
Chapter 9 Architectural Design.
Interface Design Easy to learn? Easy to use? Easy to understand?
Software Engineering: A Practitioner’s Approach, 6/e Chapter 10 Architectural Design copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For.
DESIGN CONCEPTS AND PRINCIPLES
Presentation transcript:

Design Concepts and Principles Lecture 6 Design Concepts and Principles

Analysis to Design PSPEC ERD DFD STD CSPEC THE DESIGN MODEL Data Object Description PSPEC component (procedural) design ERD DFD Data Dictionary i n t e r f a c e d e s i g n a r c h i t e c t u r a l d e s i g n STD d a t a d e s i g n CSPEC THE DESIGN MODEL THE ANALYSIS MODEL

Where Do We Begin? Spec Prototype Design modelling

Design Principles [Dav95] 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” between the software and the problem as it exists in the real world. The design should exhibit uniformity and integration.

Design Principles [Dav95] The design should be structured to accommodate change. The design should be structured to degrade gently, even when aberrant 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.

Fundamental Concepts abstraction—data, procedure, control refinement—elaboration of detail for all abstractions modularity—compartmentalization of data and function architecture—overall structure of the software Structural properties Extra-structural properties Styles and patterns procedure—the algorithms that achieve function hiding—controlled interfaces

Data Abstraction door manufacturer model number type swing direction inserts lights type number weight opening mechanism implemented as a data structure

Procedural Abstraction open details of enter algorithm implemented with a "knowledge" of the object that is associated with enter

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

Modularity: Trade-offs What is the "right" number of modules for a specific software design? module development cost cost of software module integration cost optimal number number of modules of modules

Functional Independence COHESION - the degree to which a module performs one and only one function. COUPLING - the degree to which a module is “connected” to other modules in the system. HIGH Independent Communication, Procedural Coincidentally, logically, temporal Compiler/OS Content External, Common Control Data, Stamp LOW

Architecture “The overall structure of the software and the ways in which that structure provides conceptual integrity for a system.” [SHA95a] Structural properties: defines the components of a system (e.g., modules, objects, filters) and the manner in which those components are packaged and interact with one another. Extra-functional properties: address how the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other system characteristics. Families of related systems: draw upon repeatable patterns that are commonly encountered in the design of families of similar systems.

Information Hiding module clients • algorithm controlled interface • data structure • details of external interface • resource allocation policy clients "secret" a specific design decision

Architectural Design

Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a software engineer to: analyze the effectiveness of the design in meeting its stated requirements, consider architectural alternatives at a stage when making design changes is still relatively easy, and reduce the risks associated with the construction of the software.

Data Design refine data objects and develop a set of data abstractions implement data object attributes as one or more data structures review data structures to ensure that appropriate relationships have been established simplify data structures as required

Component Level Data Design Apply systematic analysis principles to function and behavior to data. Identify all data structures and the operations to be performed on them Establish a data dictionary. Defer low level data design decisions. Reveal data structure representation only to those modules that must make direct use of its content. Develop a library of useful data structures and the operations that may be applied to them Abstract data types should be supported.

Architectural Styles Data-centered architectures Each style describes a system category that encompasses: (1) a set of components (e.g., a database, computational modules) that perform a function required by a system, (2) a set of connectors that enable “communication, coordination and cooperation” among components, (3) constraints that define how components can be integrated to form the system, and (4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts. Data-centered architectures Data flow architectures Call and return architectures Object-oriented architectures Layered architectures

Data-Centered Architecture Client software Client software Client software Client software Data store (repository or blackboard) Client software Client software Client software Client software

Data Flow Architecture filter pipes (a) pipes and filters (b) batch sequential

Call and Return Architecture main program/subprogram remote procedure call

Layered Architecture components user interface layer application layer utility layer core layer

Analyzing Architectural Design Collect scenarios. Elicit requirements, constraints, and environment description. Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements: module, process and data flow views Evaluate quality attributes by considered each attribute in isolation. Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5.

An Architectural Design Method customer requirements "four bedrooms, three baths, lots of glass ..." architectural design

Deriving Program Architecture

Partitioning the Architecture “horizontal” and “vertical” partitioning are required

Horizontal Partitioning define separate branches of the module hierarchy for each major function use control modules to coordinate communication between functions function 1 function 3 function 2

Vertical Partitioning: Factoring design so that decision making and work are stratified decision making modules should reside at the top of the architecture workers decision-makers

Why Partitioned Architecture? results in software that is easier to test leads to software that is easier to maintain results in propagation of fewer side effects results in software that is easier to extend

Structured Design objective: to derive a program architecture that is partitioned approach: the DFD is mapped into a program architecture the PSPEC and STD are used to indicate the content of each module notation: structure chart

Flow Characteristics Transform flow Transaction flow transaction action paths transaction transaction centre

General Mapping Approach isolate incoming and outgoing flow boundaries; for transaction flows, isolate the transaction center working from the boundary outward, map DFD transforms into corresponding modules add control modules as required refine the resultant program structure using effective modularity concepts

Transform Mapping

Factoring

First Level Factoring main program controller output input processing

Second Level Mapping

Transaction Flow T incoming flow action path

Transaction Example fixture fixture setting servos commands operator process fixture setting report robot control fixture servos display screen robot control software in reality, other would also be shown assembly record

Refining the Analysis Model 1. write an English language processing narrative for the level 01 flow model 2. apply noun/verb parse to isolate processes, data items, store and entities 3. develop level 02 and 03 flow models 4. create corresponding data dictionary entries 5. refine flow models as appropriate ... now, we're ready to begin design!

Deriving Level 1 narrative for " process operator commands“ after noun-verb parse Process operator command software reads operator commands from the cell operator. An error message is displayed for invalid commands. The command type is determined for valid commands and appropriate action is taken. When fixture commands are encountered, fixture status is analysed and a fixture setting is output to the fixture servos. When a report is selected, the assembly record file is read and a report is generated and displayed on the operator display screen. When robot control switches are selected, control values are sent to the robot control system.

Level 1 Data Flow Diagram operator commands Error msg status fixture servos read operator commands fixture setting valid command analyse fixture fixture status determine command select report type report generate control display report robot screen send control assembly value record robot control system robot control

Level 2 Data Flow Diagram read command produce error msg validate determine type fixture status setting format record calculate output values report assembly invalid command error msg robot control send control value start /stop combined raw setting fixture setting

Transaction Mapping Principles isolate the incoming flow path define each of the action paths by looking for the "spokes of the wheel" assess the flow on each action path define the dispatch and control structure map each action path flow individually

Transaction Mapping

Isolate Flow Paths error msg produce error msg format read command produce error msg validate determine type fixture status setting format record calculate output values report assembly invalid command error msg robot control send control value start /stop combined raw setting fixture setting

Map the Flow Model process operator commands command input controller read validate produce error message determine type fixture status report generation send control value each of the action paths must be expanded further

Refining the Structure Chart

Interface Design Inter-modular interface design driven by data flow between modules External interface design driven by interface between applications driven by interface between software and non-human producers and/or consumers of information Human-computer interface design driven by the communication between human and machine

User Interface Design

Interface Design Easy to learn? Easy to use? Easy to understand?

Interface Design Typical Design Errors lack of consistency too much memorization no guidance / help no context sensitivity poor response unfriendly

Golden Rules Place the user in control Reduce the user’s memory load Make the interface consistent

Place the User in Control Define interaction modes in a way that does not force a user into unnecessary or undesired actions. Provide for flexible interaction. Allow user interaction to be interruptible and undoable. Streamline interaction as skill levels advance and allow the interaction to be customized. Hide technical internals from the casual user. Design for direct interaction with objects that appear on the screen.

Reduce the User’s Memory Load Reduce demand on short-term memory. Establish meaningful defaults. Define shortcuts that are intuitive. The visual layout of the interface should be based on a real world metaphor. Disclose information in a progressive fashion.

Make the Interface Consistent Allow the user to put the current task into a meaningful context. Maintain consistency across a family of applications. If past interactive models have created user expectations, do not make changes unless there is a compelling reason to do so.

User Interface Design Models System perception — the user’s mental image of what the interface is User model — a profile of all end users of the system System image — the “presentation” of the system projected by the complete interface Design model — data, architectural, interface and procedural representations of the software

User Interface Design Process

Task Analysis and Modeling All human tasks required to do the job (of the interface) are defined and classified Objects (to be manipulated) and actions (functions applied to objects) are identified for each task Tasks are refined iteratively until the job is completely defined

Interface Design Activities Establish the goals and intentions for each task. Map each goal/intention to a sequence of specific actions. Specify the action sequence of tasks and subtasks, also called a user scenario, as it will be executed at the interface level. Indicate the state of the system, i.e., What does the interface look like at the time that a user scenario is performed? Define control mechanisms, i.e., The objects and actions available to the user to alter the system state. Show how control mechanisms affect the state of the system. Indicate how the user interprets the state of the system from information provided through the interface.

Design Evaluation Cycle