SE300 SWE Practices. Lecture 10B Component Design (Abstraction, Interface/Implementation, Cohesion, Coupling, Refactoring) Tuesday, March 17, 2015

Transcription

1 SE300 SWE Practices Lecture 10B Component Design (Abstraction, Interface/Implementation, Cohesion, Coupling, Refactoring) Tuesday, March 17, 2015 Sam Siewert

2 Synchronization with Text SEPA (Pressman) Chapter 14, 15 & 16 Read Chapter 14 for General Component Design Concepts and Service Design Example Read Chapter 15 to Reinforce Interactive Architecture Discussion Goals for Software System Re-use and Maintenance Component Design Services Transformation and State Machine Specification Real-Time vs. Best-Effort Web Services (Example of Web Services in Pressman Chapter 14, Section 4) Legacy Systems Wrapping Old Algorithms in New Interfaces (e.g. BLAS) Refactoring Ideally Changing Implementation and Not Interfaces Sam Siewert 2

3 Component Design Concepts Create a Public Interface Specification (Negotiate and Control Changes Carefully) Create Private Data and Methods (Can Be changed, Refactored without Re-negotiation) Encapsulate Data and Methods to Operate on Data that form a Cohesive Re-use Component Interface Changes Are Much more Costly than Implementation Changes With OOA/OOD/OOP We can Inherit Attributes, Methods and Re-Use Interfaces as well as Implementations Sam Siewert 3

4 Note on Refactoring Ideally Refactoring includes Changes (Improvements) to Implementation (Private) Features of a Component Specification and Implementation Refactoring Can Include Changes to Public Interfaces, but this is Costly! Most Refactoring Involves Private Changes (Less Impact to Customers/Users) Pressman Gives Example of Interface and Component Refactoring Because of Cohesion/Coupling Issues in Design on P. 301 (Not Ideal) Sam Siewert 4

5 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: a component contains processing 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. These slides are designed to accompany Software Engineering: A Practitioner s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 5

6 OO Component analysis c lass Print Job num berof Pages num berof Sides paperty pe m agnif ic at ion product ionfeat ures c om put ejobcost( ) passjobt oprint er( ) comput ejob design component Print Job init iat ejob < < 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( ) elaborated design class Print Job 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 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 slides are designed to accompany Software Engineering: A Practitioner s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 6

7 Conventional Component getjobdata design component ComputePageCost accesscostsdb elaborated 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: job size in: color=1, 2, 3, 4 in: pagesize = A, B, C, B out : BPC out : SF get JobDat a ( num berpages,num berdocs, sides, color, pagesize, pagecost ) accesscost sdb (jobsize, color, pagesize, BPC, SF) comput epagecost( ) job size ( JS) = num berpages * num berdocs; lookup base page cost ( BPC) --> accesscost sdb ( JS, color) ; lookup size fact or ( SF) --> accesscost DB ( JS, color, size) job com plexit y fact or ( JCF) = 1 + [ ( sides-1) * sidecost + SF] pagecost = BPC * JCF These slides are designed to accompany Software Engineering: A Practitioner s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 7

8 Design Guidelines Components 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 Interfaces provide important information about communication and collaboration (as well as helping us to achieve the OPC) 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 slides are designed to accompany Software Engineering: A Practitioner s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 8

9 Cohesion Conventional view: the single-mindedness of a module OO view: cohesion implies that a component or class encapsulates only attributes and operations that are closely related to one another and to the class or component itself Levels of cohesion Functional Layer Communicational Sequential Procedural Temporal utility These slides are designed to accompany Software Engineering: A Practitioner s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 9

10 Coupling Conventional view: The degree to which a component is connected to other components and to the external world OO view: 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 slides are designed to accompany Software Engineering: A Practitioner s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 10

11 Component Level Design-I Step 1. Identify all design classes that correspond to the problem domain. Step 2. Identify all design classes that correspond to the infrastructure domain. Step 3. Elaborate all design classes that are not acquired as reusable components. Step 3a. Specify message details when classes or component collaborate. Step 3b. Identify appropriate interfaces for each component. These slides are designed to accompany Software Engineering: A Practitioner s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 11

12 Component-Level Design-II Step 3c. Elaborate attributes and define data types and data structures required to implement them. Step 3d. Describe processing flow within each operation in detail. Step 4. Describe persistent data sources (databases and files) and identify the classes required to manage them. Step 5. Develop and elaborate behavioral representations for a class or component. Step 6. Elaborate deployment diagrams to provide additional implementation detail. Step 7. Factor every component-level design representation and always consider alternatives. These slides are designed to accompany Software Engineering: A Practitioner s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 12

13 Next For Event-Driven and General Activity Diagrams Concurrency Behavioral Specification Objects with Active Threads (Tasks) State-Machines Deterministic Response Model for a Task (Thread) Task Awaits and Activating Event and Transitions to a New Statet Sam Siewert 13

14 Domain Models Adding Object State Refine Behavior Models State Transition Analysis and State Machine Models Start Here! SA/SD DFD with Addition of Control Flows Sam Siewert 14

15 CFD/DFD vs. Activity Diagram CFD is an Extension to DFD to Combine State-ful Behavior with Processing SA/SD Origin Ward and Mellor Transformational Schema for Real-Time Systems Activity Diagram is UML Model to Achieve Similar Analysis and Specification to Unify Object State Models with Transformation We Recommend Doing Both, but Activity Diagrams are Supported by UML and UML Tools (Key Advantage) Sam Siewert 15

16 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Real Time Systems Design transformational processes, representing computations or information processing activities control processes, representing system s state dependent behavior, which is modeled by a Mealy type state machine continuous data flow, which must be processed in real time ordinary or discrete data flow event flow or control flow that triggers a transition of the state machine of a control process, or a command from a control process to a transformational process 13-16

17 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Real Time Systems Design a b P indicates that both data flow a and data flow b are required to begin executing process P a + b P indicates that either data flow a or data flow b is required to begin executing process P These logical connector can be applied to both data flow and control flow and transformation process and control process

18 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Z Z X Y Real Time Systems Design Two subsets of Z are used by two different successor processes. All of Z is used by two different successor processes. X Y Z Z is composed of Two subsets provided by two different predecessor processes. Z All of Z is provided by either one of two predecessor processes

19 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Cruise Control Example enable/disable rotation rate throttle control start/stop increase speed Increase Speed throttle position brake enable/ disable throttle control Cruise Control resume trigger enable/ disable enable/ disable Maintain Constant Speed rotation rate speed reached throttle position Record Rotation Rate Return to Previous Speed rotation rate set point rotation rate throttle control rotation rate throttle position 13-19

20 Activity Diagram validate attribut es input accesspaperdb (weight) returns basecostperpage Combination of Flow-chart (decisions) With Dataflow, but in UML, this is coordinated With UML Class Diagram and Components papercost perpage = basecostperpage size = B papercost perpage = papercost perpage * 1.2 size = C papercost perpage = papercostperpage * 1.4 size = D papercost perpage = papercost perpage * 1.6 color is custom papercostperpage = papercostperpage * color is standard returns ( papercostperpage ) These slides are designed to accompany Software Engineering: A Practitioner s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 20

21 Definition of Object States The CFD/DFD Imply State Concepts via Control Flows with Transformation Shown as Data Flow State Machines Provide Detail of Transformation Transitions Method To Elaborate the Processing Between States The Activity Diagram Shows Transformation of Data and Control Flow (just like CFD/DFD), but Likewise Lack State Detail State Machines Combined with Transformation (E.g. Transformation Takes you Between States) Commonly Found in Embedded Systems Analyze with Object State Transition Tables and Charts Sam Siewert 21

22 Statechart dat ainput Incomplet e buildingjobdat a ent ry/ readjobdat a () exit / displayjobdat a () do/ checkconsist ency() include/ dat ainput behavior wit hin t he st at e buildingjobdat a Pressman suggests That Transformation is Internal to a State (Required to make a State Transition) Alternate Approach is to Consider State Machines Internal to a Transformation Process dat ainput Complet ed [ all dat a it ems consist ent ] / displayuseropt ions jobcost Accept ed [ cust omer is aut horized] / get Elect ronicsignat ure comput ingjobcost ent ry/ comput ejob exit / save t ot aljobcost f ormingjob ent ry/ buildjob exit / save WOnumber do/ Difference Between State Analysis and State Machine Design submit t ingjob ent ry/ submit Job exit / init iat ejob do/ place on JobQueue jobsubmit t ed[ all aut horizat ions acquired] / print WorkOrder These slides are designed to accompany Software Engineering: A Practitioner s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 22

23 State Machine for Service A Service Can be Modeled as a Simple State Machine that awaits Service Request(s) Accepts Request Input Interprets, Processes Request Produces a Response to Request Returns to wait for Next Request Considerations Do Requests Queue? Transform Occurs Inside States Sam Siewert 23

24 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Cruise Control State Machine enable/trigger Record Rotation Rate, enable Maintain Constant Speed start increase speed/disable Maintain Constant Speed, enable Increase Speed brake/disable Increase Speed Maintain Speed Increase Speed Interrupted brake/disable Maintain Constant Speed stop increasing speed/disable Increase Speed, trigger Record Rotation Speed enable Maintain Constant Speed resume/enable Return to Previous Speed brake/disable Return to Previous Speed Resume Speed 13-24

25 Timed State Machine Time intervals can be used to label the state transitions. The time intervals define the timing lower bounds and upper bounds allowed for processing the event and executing the list of actions. The time interval can be decomposed to define the allowed times for processing the event, and executing each of the actions in the action list. Similarly, time can be defined for state entrance action, state exit action, and state activity. Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved

26 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. State Diagram for Real Time Systems S1 event/action [x,y] S2 S1 event/action [x] S2 Time interval. The time allowed for processing the event and executing the action is x to y time units. S1 event[x,y]/ action[u,v] S2 Time interval. The time allowed for processing the event and executing the action is x time units. S1 track(contact)/ (targetlist.fit (contact)[5,8]) S2 The time allowed for processing the event is x to y time units and executing the action is u to v time units. The time allowed for targetlist object to fit the contact with a tracked target is 5 to 8 time units

27 Problems with Conventional Approaches High cyclomatic complexity (number of states multiplied by number of transitions). Nested case statements make the code difficult to comprehend, modify, test, and maintain. Difficult to introduce new states (need to change every event case). Difficult to introduce new events (need to change every state case). Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved

28 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Applying State Pattern The state pattern is a low complexity and easy to extend approach to implement a state machine. S1 t1() t3()[c2] S2 Each mathod is state:=state.ti(); i=1, 2, 3 t2()[c1]/a() Client Subject t1() t2() t3() state Each method is return this; State t1(): State t2(): State t3(): State State machine for a subject Legend: S1, S2: states t1(), t2(): state transition [ci]: guard condition /a(): action to be performed implement t1() behavior; return new S2(); S1 t1(): State S2 t2(): State t3(): State 13-28

29 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Applying State Pattern to Cruise Control CruiseControl onoffbuttonpressed() leverdown() leverup() brakeapplied() leverdownandhold() leverupandhold() leverpulled() leverreleased() State states : State [ ] onoffbuttonpressed (c:cruisecontrol) leverdown (c:cruisecontrol) leverup (c:cruisecontrol) leverreleased (c:cruisecontrol) state leverdownandhold (c:cruisecontrol) leverupandhold (c:cruisecontrol) leverpulled(c:cruisecontrol) brakeapplied(c:cruisecontrol) setdesiredspeed(c:cruisecontrol) CruiseDeactivated onoffbuttonpresse d (c:cruisecontrol) CruiseActivated onoffbuttonpresse d (c:cruisecontrol) CruisingCancelled Cruising DecreasingSpeed IncreasingSpeed leverdownandhold(c:cruiseco ntrol) leverupandhold(c:cruisecontro l) leverdown(c:cruisecontrol) leverup(c:cruisecontrol) leverdownandhold(c:cruisecontrol) leverupandhold(c:cruisecontrol) leverdown(c:cruisecontrol) leverpulled(c:cruisecontrol) brakeapplied(c:cruisecontrol) leverreleased (c:cruisecontrol) leverreleased (c:cruisecontrol) 13-29

30 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Benefits of State Pattern Significantly reduces the cyclomatic complexity of the state handling code. Easy to add states --- simply add state subclasses and implement the relevant operations. Easy to add transitions --- simply add operations to the State class and implement the operations in relevant State subclasses. Easy to understand, implement, test and maintain