The Road Map. SE203b: OO Design for Software Engineers. W8: OO Design Approach

Transcription

1 SE203b: OO Design for Software Engineers W8: OO Design Approach Statechart,, Activity, Components & Node Diagrams Architectural frameworks Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa The Road Map Introduction to Software Design Software Design Approaches Introduction to OO Paradigm Software Design with OO Paradigm Patterns in Design and Architecture Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 2

2 OO Software Requirements & Design Process Requirement capture using Use Cases Use Case Diagrams Use Case Description Analysis & Design Class Diagrams Data Dictionary Interaction Diagrams Statechart Diagrams Activity Diagrams Implementation Deployment Architecture-centric Patterns Frameworks Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 3 Workflows and s Requirements Requirements Use Case Analysis Analysis Design Design Implementation Implementation Design Deployment Implementation Test Test Test Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 4

3 Use Case Diagram Captures system functionality as seen by users Built in early stages of development Purpose Specify the context of a system Capture the requirements of a system Validate a system s architecture Drive implementation and generate test cases Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 5 Class Diagram Captures the vocabulary of a system Built and refined throughout development Purpose Name and model concepts in the system Specify collaborations Specify logical database schemas Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 6

4 Sequence Diagram Captures dynamic behavior (time-oriented) Purpose flow of control Illustrate typical scenarios Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 7 Some Reusable OO Design Patterns Façade Adapter Composite Proxy Observer Abstract Factory Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 8

5 Analysis & Design Use Case Use Case Diagram Class Diagrams Object Object Diagrams Diagrams Analysis & Design Depl. Impl. Test Component Component Diagrams Diagrams Deployment Deployment Diagrams Diagrams Sequence Diagrams Collaboration Diagrams Statechart Statechart Diagrams Diagrams Activity Activity Diagrams Diagrams Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 9 Statechart Diagram Captures entity behavior (event-oriented) Purpose o o object lifecycle reactive objects (user interfaces, devices, etc.) Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 10

6 States & Events At any given point in time, the system is in one state It will remain in this state until an event occurs o that causes it to change state Events invoke changes in state Final state due to a given event depends upon the initial state An event separates two states off Lamp On A transition represents a change of state in response to an event Lamp Off It is considered to occur instantaneously The label on each transition is the event that causes the change of state Special states: A black circle represents the start state A circle with a ring around it represents an end state on Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 11 Actions & Activities Events trigger operations in the state diagram Two types of operations o An action is an instantaneous operation and not interruptible i.e., its internal structure is not important to model o An activity is an operation that takes time to complete it can be interrupted on Lamp On Off / display_off On / display_on off Lamp Off Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 12

7 Basic UML Statechart Diagram Initial state State Event Ready Transition stop /ctr := 0 Final state Done stop Action Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 13 Object lifecycle - General Handling depends on specific request type Create/Initialize Create/Initialize Object Object Wait Wait for for Request Request void:offhook (); {busy = true; obj.reqdialtone(); }; Handle Handle Request Request Terminate Terminate Object Object Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 14

8 Object lifecycle and State Machines Direct mapping: Create/Initialize Object Lamp On on Wait for Event Handle Event off Lamp Off on/print( on ) off Terminate Object stop Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 15 Actions on Entry to States Entry and exit actions Entry Actions: Performed whenever the state is entered o Notation: entry/ action name o Useful when all transitions entering a state share a common action Exit Actions: Performed whenever the state is exited. o Notation: exit/ action name o Useful when all transitions leaving a state share a common action. LampOn entry/lamp.on(); exit/lamp.off(); e1 e2 Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 16

9 Order of Actions: Simple Case Exit actions prefix transition actions Entry action postfix transition actions LampOn entry/lamp.on(); exit/printf( exiting printf( exiting ); off/printf( to off ); LampOff entry/lamp.off(); exit/printf( exiting printf( exiting ); Resulting action sequence: printf( exiting ); printf( to off ); lamp.off(); off/printf( needless printf( needless ); printf( exiting ); printf( needless ); ); lamp.off(); Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 17 State ( Do ) Activities An activity is associated with a state The notation: do/ activity name It forks a concurrent thread that executes until: the activity completes or the state is exited o through an outgoing transition the activity can be a continuous operation e.g., do: display main screen Error entry/printf( error printf( error! ) do/while (true) alarm.ring(); Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 18

10 Conditions State1 Do /activity 1 Event1 [condition] /action State2 A state is often associated with the value of an object satisfying some conditions A conditions is a Boolean function of object value o e.g., the amount within predefined limits A guarded transition o a transition labeled by an event with a condition A guarded transition fires when its event occurs and the condition is true It showed as a Boolean expression in brackets following the event name e.g., insert card [readable] Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 19 Guards Conditional execution of transitions guards must be side-effect free Selling bid [value >= 200] /sell Happy bid [value < 100] /reject bid [(value >= 100) & (value < 200)] /sell Unhappy Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 20

11 State Generalization In a nested state diagram, a state in a higher-level is a form of generalization of the states in its lower level state diagram If it is in state X, it is in exactly one of the state x_1; ; x_n Y x_1 X x_n Z Transmission Neutral N F R N Stop U Forward First Second U D D Forward Reverse Third Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 21 Concurrency Aggregation concurrency A state diagram for an aggregate is a collection of state diagrams, one for each element The elements are inherently concurrent Objects can change state independently or interact Synchronization constraints are implemented by conditions in guarded transitions Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 22

12 Car Components: Example Car Ignition Accelerator Brake Transmission Transmission R Accelerator Neutral Reverse depress accel N Off On N F release accel Forward Ignition Off turn key to start [transmission in neutral] Starting release key On turn key off Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 23 Statecharts: : Recap Used to model event-driven (reactive) behavior well-suited to the server model inherent in the object paradigm Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 24

13 Activity Diagram Captures dynamic behavior (activity-oriented) Purpose o o workflows operations Transitions are caused by internal events The objective o To help understanding the flow of work (operations) that an object or component performs often associated with several classes especially concurrent activities Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 25 Kinds of Action States Action (State) Action Submachine (State) Submachine Just like their state machine counterparts (simple state and submachine state) except that transitions are caused by internal events and are taken when the step is finished, Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 26

14 Example POEmployee sortmail() delivermail() POEmployee.sortMail POEmployee. delivermail delivermail Check Out Truck Put Mail In Boxes Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 27 Activity Graph as Method All activity graphs are methods for operations Application is completely OO when all action states invoke operations POEmployee.sortMail POEmployee. delivermail POEmployee delivermail sortmail() delivermail() «realize» Check Out Truck Put Mail In Boxes Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 28

15 Coordinating Steps Initial state Final state Branch/merge Fork join Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 29 Coordinating Steps(Cont.) For modeling conventional flow chart decisions. Calculate Cost [cost < $50] [cost >= $50] Charge Account Get Authorization Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 30

16 Representing Concurrency Concurrency is shown using forks, joins and rendezvous. o o o A fork has one incoming transition and multiple outgoing transitions. The execution splits into multiple concurrent threads A join has multiple incoming transitions and one outgoing transition. The outgoing transition will be taken when all incoming transitions have occurred The incoming transitions must be triggered in separate threads If one incoming transition occurs a wait condition occurs at the join until the other transitions occur A rendezvous has multiple incoming and multiple outgoing transitions. Once all the incoming transitions occur all the outgoing transitions may occur Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 31 Example Build Frame Put On Roof Install Walls Install Foundation Inspect Install Electricity in Foundation Install Electricity In Frame Install Electricity Outside Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 32

17 Swimlanes The activity of an object might involve invocation of other ojects. The partition of activities among the existing objects can be explicitly shown using swimlanes Partitions are a grouping mechanism o Swimlanes are the notation for partitions They do not provide domain-specific semantics Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 33 Activity Diagrams an example with swimlanes Student CourseSection Receive course registration request [not ok] Check prerequisites Check special permission [not ok] [ok] [ok] Verify course not full [ok] [not ok] Complete registration Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 34

18 Coordinating Steps Synch state is inherited from state machines but used mostly in activity graphs Provides communication capability between parallel processes State machine notation Build Frame Put On Roof Install Walls Install Foundation Inspect Install Electricity in Foundation Install Electricity In Frame Install Electricity Outside Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 35 Convenience Features (Synch State) Forks and joins do not require composite states Synch states may be omitted for the common case (unlimited bound and one incoming and outgoing transition). Activity diagram notation Build Frame Put On Roof Install Walls Install Foundation Inspect Install Electricity in Foundation Install Electricity In Frame Install Electricity Outside Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 36

19 When to Use Activity Diagrams Use activity diagrams when the behavior you are modeling... does not depend much on external events mostly has steps that run to completion o rather than being interrupted by events requires object/data flow between steps is being constructed at a stage when you are more concerned with o which activities happen, rather than which objects are responsible for them (except partitions possibly) Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 37 Activity Diagrams: Recap Use Activity Diagrams for applications that are primarily control and data-driven, like business modeling rather than event-driven applications like embedded systems Purpose o workflows o operations Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 38

20 OO Software Requirements & Design Process Requirement capture using Use Cases Use Case Diagrams Use Case Description Analysis & Design Class Diagrams Data Dictionary Interaction Diagrams Statechart Diagrams Activity Diagrams Implementation Deployment Architecture-centric Patterns Frameworks Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 39 Workflows and s Requirements Requirements Use Case Analysis Analysis & Design Design Implementation Implementation Design Deployment Implementation Test Test Test Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 40

21 Use Case Use Case Diagram Class Class Diagrams Diagrams Deployment Deployment Diagrams Diagrams Object Object Diagrams Diagrams Design Analysis Depl. Impl. Test Component Component Diagrams Diagrams Sequence Sequence Diagrams Diagrams Collaboration Collaboration Diagrams Diagrams Statechart Statechart Diagrams Diagrams Activity Activity Diagrams Diagrams Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 41 Component Diagram Captures the physical structure of the implementation Components may be implemented by artifacts oo e.g., binary, executable, or or script files (such as html) component Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 42

22 Components and Classes Component is the physical implementation of a set of classes Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 43 Components and Interfaces The component realizes the interface is connected to the interface using a full realization relationship A component accesses the services of the other component through its interface Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 44

23 Component Diagram Example ShoppingSessionHome ShoppingSession <<EJBSession>> ShoppingSession CatalogHome <<EJBEntity>> Catalog CatalogHome CatalogPK CatalogPK Catalog Catalog CatalogInfo CatalogInfo Catalog ShoppingCartHome <<EJBEntity>> ShoppingCart ShoppingCart Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 45 Deployment Diagram Captures the topology of a system s hardware Shows the configuration of run-time processing elements and the software components, o processes and objects that live on them Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 46

24 Nodes and Components A component may be deployed by a node or more classes might be implemented by a component or more Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 47 Deployment Diagram Example(Cont.) Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 48

25 Deployment Diagram Example(Cont.) :Client <<browser>> :OpenSourceBrowser videostoreserver:appserver <<Session>> ShoppingSession ShoppingSession <<Entity>> Catalog Catalog <<Entity>> ShoppingCart ShoppingCart :DBServer <<database>> :VideoStoreDB Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 49 OO Software Requirements & Design Process Requirement capture using Use Cases Use Case Diagrams Use Case Description Analysis & Design Class Diagrams Data Dictionary Interaction Diagrams Statechart Diagrams Activity Diagrams Implementation Deployment Architecture-centric Patterns Frameworks Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 50

26 Architectural Patterns: : Frameworks The notion of patterns can be applied to software architecture These are called o architectural patterns, or o frameworks, or o architectural styles Each allows you to design flexible systems using components o The components are as independent of each other as possible Architectural patterns Layered View Controller (MVC) Distributed o Client Server o Broker Pipes and filters Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 51 Multi-Layer Style In a layered system, each layer communicates only with the layer immediately below it Each layer has a well-defined interface used by the layer immediately above o The higher layer sees the lower layer as a set of services A complex system can be built by superposing layers at increasing levels of abstraction It is important to have a separate layer for the UI Layers immediately below the UI layer o provide the application functions determined by the use-cases Bottom layers provide general services o e.g. network communication, database access Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 52

27 Multi-layer layer Style Example User Interface User Interface Application Logic OS Access Application Logic DB Access NW Comm. OS Access DB Access Network Communication Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 53 Example: 2-tier 2 & 3-tier 3 Architecture Graphical User Interface Application Graphical User Interface Business Object Graphical User Interface Business Object Relational Database/ External Relational Database/ External Design Patterns Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 54

28 Multi-layer layer Example Application Programs Screen Display Facilities User Account Mngt Application Programs Screen Display Facilities User Account Mngt. File System Kernel File System Kernel Typical layers in an operating system Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 55 Deployment Diagram Example(Cont.) :Client Presentation <<browser>> :OpenSourceBrowser videostoreserver:appserver Application Logic <<Session>> ShoppingSession ShoppingSession <<Entity>> Catalog Catalog <<Entity>> ShoppingCart ShoppingCart :DBServer Database <<database>> :VideoStoreDB Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 56

29 Complex Internet system Client Dynamic HTML, JavaScript, Java plug-ins, source code enhancements Server Java, C, C++, JavaScript, CGI Application Server Java, C, C++, JavaBeans, CORBA, DCOM Fulfillment System Financial System Inventory System RDBMS Server Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 57 The Multi-Layer Design Principles Divide and conquer: The layers can be independently designed Increase cohesion: Well-designed layers have layer cohesion Reduce coupling: Well-designed lower layers do not know about the higher layers the only connection between layers is through the interfaces (API) Increase abstraction: you do not need to know the details of how the lower layers are implemented Increase reusability: The lower layers can often be designed generically. Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 58

30 The Multi-layer layer Design Principles Increase reuse: o You can often reuse layers built by others that provide the services you need. Increase flexibility: o you can add new facilities built on lower-level services, or replace higher-level layers. Design for portability: o All the dependent facilities can be isolated in one of the lower layers. Design for testability: o Layers can be tested independently. Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 59 -View View-Controller (MVC( MVC) ) Style to separate the user interface layer from other parts of the system The main elements The model o contains the underlying classes whose instances are to be viewed and manipulated The view o contains objects used to render the appearance of the data from the model in the user interface The controller o contains the objects that control and handle the user s interaction with the view and the model The Observable design pattern is normally used to separate the model from the view Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 60

31 The MVC Architecture UI Example Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 61 MVC: : Example Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 62

32 MVC: : Example Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 63 The MVC Architecture Example viewed by actor View create and update receives actor events notify about changes Controller modify Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 64

33 The MVC Design Principles Divide and conquer: o The three components can be somewhat independently designed Increase cohesion: o The components have stronger layer cohesion by separating view and controller Reduce coupling: o The communication channels between the three components are minimal Increase reuse: o The view and controller normally make extensive use of reusable components for various kinds of UI controls Design for flexibility: o It is usually quite easy to change the UI by changing the view, the controller, or both Design for testability: You can test the application separately from the UI Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 65 Distributed Architecture Clients LAN WAN Servers Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 66

34 Client-Server & Multi-tier tier Styles There is at least one component that has the role of server o waiting for and then handling connections that has the role of client o initiating connections in order to obtain some service. A further extension is the Peer-to-Peer pattern A system composed of various software components that are distributed over several hosts. Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 67 Client-Server Client1: System1: <<communication>> exchange messages System3: <<communication>> exchange messages <<communication>> exchange messages <<communication>> Request service 1 <<communication>> look up addresses Server: Peer-to-peer Client2: System2: Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 68

35 Physical Application Architecture Thinner client, thicker server Client A Application Client B Application Client C WWW Browser Business Object Services DCOM CORBA Beans Business Object Engine Business COM Object Server MTS Beans ETS Business Object Services Web Server HTML CGI ASP Business Object Services Java Business Object Engine Business Object Engine Relational Database Server(s) Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 69 The distributed architecture Design Principles Divide and conquer: o Dividing the system into client and server processes where Each can be separately developed. Increase cohesion: o The server can provide a cohesive service to clients. Reduce coupling: o There is usually only one communication channel exchanging simple messages. Increase abstraction: o Separate distributed components are often good abstractions. Increase reuse: o It is often possible to find suitable frameworks on which to build good distributed systems However, client-server systems are often very application specific Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 70

36 The distributed architecture Design Principles Design for flexibility: o can be easily reconfigured by adding extra servers or clients Design for portability: o You can write clients for new platforms without having to port the server. Design for testability: o You can test clients and servers independently. Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 71 The Broker Style Transparently distribute aspects of the software system to different nodes o An object can call methods of another object without knowing that this object is remotely located o CORBA and Web-services are a well-known open standards that support borkering. Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 72

37 Example of a Broker system Client Proxy object request Distributed Infrastructure Broker Server Remote Obj Subscribe Interface Repository (Registration) Publish Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 73 The Broker Architecture Design Principles Divide and conquer: o The remote objects can be independently designed. Increase reusability: o It is often possible to design the remote objects so that other systems can use them too. Increase reuse: o You may be able to reuse remote objects that others have created. Design for flexibility: o The brokers can be updated as required, or the proxy can communicate with a different remote object. Design for portability: o You can develop clients for new platforms while still accessing brokers and remote objects on other platforms. Design defensively: o You can provide careful assertion checking in the remote objects. Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 74

38 The Pipe-and and-filter Framework A stream of data, in a relatively simple format, is passed through a series of processes Each of which transforms it in some way. Data is constantly fed into the pipeline. The processes work concurrently. The architecture is very flexible. o o o o Almost all the components could be removed. Components could be replaced. New components could be inserted. Certain components could be reordered. Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 75 Example of a pipe-and and-filter system encoders for microphone input microphones near sound source cancel echo cancel noise remove non-voice frequencies equalize dynamic range compress transmit distant microphone encoder for ambient noise encode speaker output TCP/IP Transmission decompress receive Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 76

39 The Pipe-Filter Architecture Design Principles Divide and conquer: o The separate processes can be independently designed. Increase cohesion: o The processes have functional cohesion. Reduce coupling: o The processes have only one input and one output. Increase abstraction: o The pipeline components are often good abstractions, hiding their internal details. Increase reusability: o The processes can often be used in many different contexts. Increase reuse: o It is often possible to find reusable components to insert into a pipeline. Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 77 The Pipe-Filter Architecture Design Principles Design for flexibility: o There are several ways in which the system is flexible. Design for testability: o It is normally easy to test the individual processes. Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 78

40 OO Software Requirements & Design Process Requirement capture using Use Cases Use Case Diagrams Use Case Description Analysis & Design Class Diagrams Data Dictionary Interaction Diagrams Statechart Diagrams Activity Diagrams Implementation Deployment Architecture-centric Patterns Frameworks Mar 29, 2006 SE203b, ECE UWO, Hamada Ghenniwa 79