1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 11b: Component-Level Design Software Engineering: A Practitioner’s Approach, 6/e Chapter.

Slides:



Advertisements
Similar presentations
Chapter 13 Design Concepts and Principles
Advertisements

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.
CS /32 Illinois Institute of Technology CS487 Software Engineering Component Level Design & Design Documentation Instructor: David A. Lash.
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Detailed Design Kenneth M. Anderson Lecture 21
Component-Level 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.
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.
Detail Design Extending UML and Object Design. Object 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.
1 Chapter 16 Component-Level Design. 2 Component-Level Design  the closest design activity to coding  the approach:  review the design description.
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.
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.
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.
Design Concepts "You can use an eraser on the drafting table or a sledge hammer on the construction site." Frank Lloyd Wright.
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.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Coming up: Software Engineering: A Practitioner’s Approach, 6/e Chapter 5 Practice: A Generic View copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
© 2011 Pearson Addison-Wesley. All rights reserved. Addison Wesley is an imprint of Stewart Venit ~ Elizabeth Drake Developing a Program.
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 11 Component-Level Design. 2 What is a Component? OMG Unified Modeling Language Specification [OMG01] defines a component as “… a modular, deployable,
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.
9-1 © Prentice Hall, 2007 Chapter 9: Analysis Classes Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 7: Requirements Engineering Software Engineering: A Practitioner’s Approach, 6/e.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/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.
Programming Techniques Lecture 10 Component-Level Design Based on: Software Engineering, A Practitioner’s Approach, 6/e, R.S. Pressman Software Engineering.
1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach,
CS 8532: Adv. Software Eng. – Spring 2009 Dr. Hisham Haddad Chapter 11 CS 8532: Advanced Software Engineering Dr. Hisham Haddad Class will start momentarily.
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 Software Engineering: A Practitioner’s Approach, 6/e Chapter 9: Design Engineering Software Engineering: A Practitioner’s Approach, 6/e Chapter.
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 16 Component-Level Design. 2 Component-Level Design  the closest design activity to coding  the approach: review the design description for.
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.
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.
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.
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.
CMPSC 16 Problem Solving with Computers I Spring 2014 Instructor: Tevfik Bultan Lecture 4: Introduction to C: Control Flow.
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 Engineering 1. Analysis  Design 2 Characteristics of good design 3 The design must implement all of the explicit requirements contained in the.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.1.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Analysis Classes Unit 5.
Software Engineering: A Practitioner’s Approach, 6/e Chapter 18 Analysis Modeling for WebApps copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
Component-Level Design
Software Engineering: A Practitioner’s Approach, 6/e Chapter 9 Design Engineering copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For.
Software Engineering: A Practitioner’s Approach, 6/e Chapter 18 Analysis Modeling for WebApps copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
Software Engineering: A Practitioner’s Approach, 6/e Chapter 11 Component-Level Design copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
Chapter 10 Component-Level Design
Component-Level Design
Problem Solving Techniques
Component-Level Design
Chapter 16 Component-Level Design
Software Engineering: A Practitioner’s Approach, 6/e Chapter 3 Prescriptive Process Models copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
Component-Level Design
Chapter 9 Design Engineering
COSC 4406 Software Engineering
Presentation transcript:

1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 11b: Component-Level Design Software Engineering: A Practitioner’s Approach, 6/e Chapter 11b: Component-Level Design copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.

2 Object Constraint Language (OCL) complements UML by allowing a software engineer to use a formal grammar and syntax to construct unambiguous statements about various design model elements complements UML by allowing a software engineer to use a formal grammar and syntax to construct unambiguous statements about various design model elements simplest OCL language statements are constructed in four parts: simplest OCL language statements are constructed in four parts: (1) a context that defines the limited situation in which the statement is valid; (1) a context that defines the limited situation in which the statement is valid; (2) a property that represents some characteristics of the context (e.g., if the context is a class, a property might be an attribute) (2) a property that represents some characteristics of the context (e.g., if the context is a class, a property might be an attribute) (3) an operation (e.g., arithmetic, set-oriented) that manipulates or qualifies a property, and (3) an operation (e.g., arithmetic, set-oriented) that manipulates or qualifies a property, and (4) keywords (e.g., if, then, else, and, or, not, implies) that are used to specify conditional expressions. (4) keywords (e.g., if, then, else, and, or, not, implies) that are used to specify conditional expressions.

3 OCL Example context PrintJob::validate(upperCostBound : Integer, custDeliveryReq : Integer) Integer) pre: upperCostBound > 0 pre: upperCostBound > 0 and custDeliveryReq > 0 and custDeliveryReq > 0 and self.jobAuthorization = 'no' and self.jobAuthorization = 'no' post: if self.totalJobCost <= upperCostBound post: if self.totalJobCost <= upperCostBound and self.deliveryDate <= custDeliveryReq and self.deliveryDate <= custDeliveryReq then then self.jobAuthorization = 'yes' self.jobAuthorization = 'yes' endif endif

4 Algorithm Design the closest design activity to coding the closest design activity to coding the approach: the approach: review the design description for the component review the design description for the component use stepwise refinement to develop algorithm use stepwise refinement to develop algorithm use structured programming to implement procedural logic use structured programming to implement procedural logic use ‘formal methods’ to prove logic use ‘formal methods’ to prove logic

5 Stepwise Refinement 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; take key out; find correct key; find correct key; insert in lock; insert in lock; endif pull/push door move out of way; end repeat

6 Algorithm Design Model represents the algorithm at a level of detail that can be reviewed for quality represents the algorithm at a level of detail that can be reviewed for quality options: options: graphical (e.g. flowchart, box diagram) graphical (e.g. flowchart, box diagram) pseudocode (e.g., PDL)... choice of many pseudocode (e.g., PDL)... choice of many programming language programming language decision table decision table conduct walkthrough to assess quality conduct walkthrough to assess quality

7 Structured Programming for Procedural Design uses a limited set of logical constructs: sequence conditional — if-then-else, select-case — if-then-else, select-case loops — do-while, repeat until — do-while, repeat until leads to more readable, testable code important for achieving high quality, but not enough can be used in conjunction with ‘proof of correctness’

8 A Structured Procedural Design

9 Decision Table

10 Program Design Language (PDL)

11 Why Design Language?