Component-Level Design based on Chapter 11 - Software Engineering: A Practitioner’s Approach, 6/e copyright © 1996, 2001, 2005 R.S.
Download ReportTranscript Component-Level Design based on Chapter 11 - Software Engineering: A Practitioner’s Approach, 6/e copyright © 1996, 2001, 2005 R.S.
Component-Level Design based on Chapter 11 - Software Engineering: A Practitioner’s Approach, 6/e 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. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1 What is a Component? OMG Unified Modeling Language Specification [OMG01] defines a component as “… a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.” OO view: a component contains a set of collaborating classes Conventional view: logic, the internal data structures that are required to implement the processing logic, and an interface that enables the component to be invoked and data to be passed to it. What would be an example? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2 OO Component a n a l y si s c l a ss Pri n t Jo b What are the differences? n u m b e rOf Pa g e s n u m b e rOf Si d e s p a p e rTy p e m agnif ic at ion p ro d u c t i o n Fe a t u re s d e si g n c o m p o n e n t c o m p u t e Jo b Co st( ) p a ssJo b t o Pri n t e r( ) c o m p u t e Jo b Pri n t Jo b i n i t i a t e Jo b Interface=method? < < in t er f ace> > co m p u t eJo b comput ePageCost ( ) comput ePaper Cost ( ) comput ePr odCost ( ) comput eTot alJobCost ( ) < < in t er f ace> > in it iat eJo b buildWor kOr der ( ) checkPr ior it y ( ) passJobt o Pr oduct ion( ) elaborat ed des ign c las s Print J ob number Of Pages number Of Sides paper Type paper Weight paper Size paper Color magnif icat ion color Requir ement s pr oduct ionFeat ur es collat ionOpt ions bindingOpt ions cover St ock bleed pr ior it y t ot alJobCost OO view: a component contains a set of collaborating classes WOnumber comput ePageCost ( ) comput ePaper Cost ( ) comput ePr odCost ( ) comput eTot alJobCost ( ) buildWor kOr der ( ) checkPr ior it y ( ) passJobt o Pr oduct ion( ) These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3 Conventional Component design component getJobData ComputePageCost accessCostsDB Conventional elaborat ed module PageCost in: numberPages in: numberDocs in: sides= 1 , 2 in: color=1 , 2 , 3 , 4 in: page size = A, B, C, B out : page cost in: j ob size in: color=1 , 2 , 3 , 4 in: pageSize = A, B, C, B out : BPC out : SF g e t Jo b Dat a ( n u m b e rPag e s, n u m b e rDo cs, sid e s, co lo r, p ag e Size , p ag e Co st ) acce ssCo st sDB (j o b Size , co lo r, p ag e Size , BPC, SF) co m p u t e Pag e Co st( ) view: logic, the internal data structures that are required to implement the processing logic, and an interface that enables the component to be invoked and data to be passed to it. j o b size ( JS) = n u m b e rPag e s * n u m b e rDo cs; lo o ku p b ase p ag e co st ( BPC) --> acce ssCo st sDB ( JS, co lo r) ; lo o ku p size fact o r ( SF) --> acce ssCo st DB ( JS, co lo r, size ) j o b co m p le xit y fact o r ( JCF) = 1 + [ ( sid e s-1 ) * sid e Co st + SF] p ag ewith co st =Software BPC * JCF Engineering: conjunction These courseware materials are to be used in A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4 Cohesion Conventional view: the “single-mindedness” of a module OO view: a component or class encapsulates only attributes and operations that are closely related to one another Levels of cohesion Functional, Layer, Communicational, Sequential, Procedural, Temporal, utility Coupling Conventional view: OO view: conventional The degree to which a component is connected to other components and to the external world OO view: a component contains a set of collaborating classes a qualitative measure of the degree to which classes are connected to one another Level of coupling Content, Common, Control, Stamp, Data, Routine call, Type use, Inclusion or import, External These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5 Component Level Design Step 1. Identify all design classes that correspond to the problem domain, infrastructure domain. Step 2. Elaborate all design classes (not acquired as reusable components). Step 2a. Specify message details when classes or component collaborate. Step 2b. Identify appropriate interfaces for each component. Step 2c. Elaborate attributes and define data types and data structures. Step 2d. Describe processing flow within each operation in detail. What operation? Step 3. Describe persistent data sources (databases and files) and identify the classes required to manage them. Step 4. Develop and elaborate behavioral representations for a class or component. Step 5. Elaborate deployment diagrams to provide additional implementation detail. Step 6. Factor every component-level design representation and always consider alternatives. Is your design the best? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6 Activity Diagram v alidat e at t ribut es input ac c es s PaperDB (weight ) ret urns bas eCos t perPage paperCos t perPage = bas eCos t perPage s iz e = B paperCos t perPage = paperCos t perPage * 1 . 2 s iz e = C paperCos t perPage = paperCos t perPage * 1 . 4 s iz e = D paperCos t perPage = paperCos t perPage * 1 . 6 c olor is c us t om What is this about wrt. Component-level design? What would be behavioral wrt. Component-level design? paperCos t perPage = paperCos t perPage * 1 . 1 4 c olor is s t andard ret urns ( paperCos t perPage ) These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7 Statechart b eh avio r w it h in t h e st at e b u ild in g Jo b Dat a d at aIn p u t In co mp let e buildingJobDat a ent ry/ readJobDat a () exit / displayJobDat a () do/ checkConsist ency() include/ dat aInput d at aIn p u t Co mp let ed [ all d at a it ems co n sist en t ] / d isp layUserOp t io n s comput ingJobCost ent ry/ comput eJob exit / save t ot alJobCost What is this about wrt. Component-level design? j o b Co st Accep t ed [ cu st o mer is au t h o rized ] / g et Elect ro n icSig n at u re f ormingJob ent ry/ buildJob exit / save WOnumber do/ How does this differ from AD wrt. Component-level design? submit t ingJob ent ry/ submit Job exit / init iat eJob do/ place on JobQueue j o b Su b mit t ed[ all au t h o rizat io n s acq u ired ] / These courseware materials are to be used in pconjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided rin t Wo rkOrd er with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8 Collaboration Diagram :ProductionJob 1: buildJob ( WOnumber ) 2: submitJob ( WOnumber ) What is this about wrt. Component-level design? :WorkOrder :JobQueue These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9 Refactoring computeJob PrintJob initiateJob WorkOrder <<interface>> initiateJob ap p ro p riat e at t rib u t e s getJobDescriiption buildWorkOrder () buildJob p assJo b To Pro d u ct io n ( ) ProductionJob submitJob JobQueue ap p ro p riat e at t rib u t e s checkPriority () These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10 Algorithm Design the closest design activity to coding the approach: review the design description for the component use stepwise refinement to develop algorithm use structured programming to implement procedural logic use ‘formal methods’ to prove logic These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11 Stepwise Refinement Recall: 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 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12 Algorithm Design Model represents the algorithm at a level of detail that can be reviewed for quality At which level? Component or Class? options: graphical (e.g. flowchart, box diagram) pseudocode (e.g., PDL) ... choice of many programming language(?) decision table conduct walkthrough to assess quality Is UML inadequate? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13 Structured Programming for Procedural Design uses a limited set of logical constructs: “go-to” considered ??? sequence conditional— if-then-else, select-case loops— do-while, repeat until leads to more readable, testable code can be used in conjunction with ‘proof of correctness’ What’s more to Structured Programming than the above? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14 A Structured Procedural Design add a condition Z, if true, exit the program a x1 b x2 x3 d f e c Can you add something to make this “unstructured?? x4 g x5 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15 Decision Tables: Another Ambiguity Test [Chung, RE Lecture Notes] Natural Language “The system shall report to the operator all faults that originate in critical functions or that occur during execution of a critical sequence and for which there is no fault recovery response.” (adapted from the specifications for the international space station) A decision table originate in critical functions F T F T F T F T Occur during critical sequence F F T T F F T T No fault recovery response F F F F T T T T Report to operator??? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 16 Decision Table Rule s Condit ions regular cust omer 1 T 2 3 4 T T gold cust omer F 6 T silver cust omer special discount 5 T F T T T F T Rule s no discount apply 8 percent discount apply 15 percent discount apply addit ional x percent discount These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17 Program Design Language (PDL) if condition x then process a; else process b; endif if-then-else PDL easy to combine with source code machine readable, no need for graphics input graphics can be generated from PDL enables declaration of data as well as procedure easier to maintain These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 18 Omitted Slides These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 19 Basic Design Principles The Open-Closed Principle (OCP). “A module [component] should be open for extension but closed for modification. The Liskov Substitution Principle (LSP). “Subclasses should be substitutable for their base classes. Dependency Inversion Principle (DIP). “Depend on abstractions. Do not depend on concretions.” The Interface Segregation Principle (ISP). “Many client-specific interfaces are better than one general purpose interface. The Release Reuse Equivalency Principle (REP). “The granule of reuse is the granule of release.” The Common Closure Principle (CCP). “Classes that change together belong together.” The Common Reuse Principle (CRP). “Classes that aren’t reused together should not be grouped together.” Source: Martin, R., “Design Principles and Design Patterns,” downloaded from http:www.objectmentor.com, 2000. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 20 Design Guidelines Components Interfaces Naming conventions should be established for components that are specified as part of the architectural model and then refined and elaborated as part of the component-level model Interfaces provide important information about communication and collaboration Dependencies and Inheritance it is a good idea to model dependencies from left to right and inheritance from bottom (derived classes) to top (base classes). These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 21 Collaboration Diagram :ProductionJob 1: buildJob ( WOnumber ) 2: submitJob ( WOnumber ) :WorkOrder :JobQueue These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 22 Refactoring computeJob PrintJob initiateJob WorkOrder <<interface>> initiateJob ap p ro p riat e at t rib u t e s getJobDescriiption buildWorkOrder () buildJob p assJo b To Pro d u ct io n ( ) ProductionJob submitJob JobQueue ap p ro p riat e at t rib u t e s checkPriority () These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 23 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 simplest OCL language statements are constructed in four parts: (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) (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. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 24 OCL Example context PrintJob::validate(upperCostBound : Integer, custDeliveryReq : Integer) pre: upperCostBound > 0 and custDeliveryReq > 0 and self.jobAuthorization = 'no‘ post: if self.totalJobCost <= upperCostBound and self.deliveryDate <= custDeliveryReq then self.jobAuthorization = 'yes' endif These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 25 Why Design Language? can be a derivative of the HOL of choice e.g., Ada PDL machine readable and processable can be embedded with source code, therefore easier to maintain can be represented in great detail, if designer and coder are different easy to review These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 26