System Behavior Modeling with Statecharts

2. Objectives • Explain how statecharts can be used to describe system behaviors • Use statecharts to model system behavior and method logic • Explain the importance of design patterns in object-oriented design • Briefly describe and use the singleton, adaptor, and observer design patterns Object-Oriented Analysis and Design with the Unified Process

3. Objectives (continued) • Explain why enterprise-level systems require special design consideration • Apply UML deployment architectural notation to Web-based systems • Explain how Web services work to obtain information on the Internet Object-Oriented Analysis and Design with the Unified Process

4. Overview • Model system and object behavior • Statecharts • Protect and stabilize systems • Protection from variations and indirection • Establish best practices in system construction • Design patterns, or templates • Design for enterprise-level and Web-based systems • Distributed and networked environments Object-Oriented Analysis and Design with the Unified Process

5. Modeling System Behavior and Method Logic with Statecharts • Statecharts were used in the requirements discipline to capture status conditions of objects • Statecharts are used in the design discipline to • Define the behavioral constraints of the system classes created during design • Windows menus, authentication and security classes, error-handling classes • Describe the method logic within class methods • Action-expressions contain information that help define method logic Object-Oriented Analysis and Design with the Unified Process

6. System-level Statecharts • Designate the states and processing controls of a system • Which menu items are enabled or disabled • Which windows are modal • Which tool bars and icons are active • Document possible options presented to users • Use state variables to record the value of the current state Object-Oriented Analysis and Design with the Unified Process

7. Figure 9-1 Logon statechart for a computer system Object-Oriented Analysis and Design with the Unified Process

8. Messages, Transitions, and Methods • A message causes a transition to fire • A transition in a statechart is the execution of a method • A method signature is defined by the message to a destination object • Action expressions in a statechart define method logic • Describes the actions to be performed during a transition Object-Oriented Analysis and Design with the Unified Process

9. Figure 9-2 Comparison of methods, messages, and transitions Object-Oriented Analysis and Design with the Unified Process

10. Action-expressions and Method Logic • A sequence diagram may not contain enough internal details about a method • Design statecharts extend requirements statecharts • Action-expressions contain logic for later coding • Transitions that allow the object to remain in the same state • Temporary states for inter-model consistency • Decision pseudostates to indicate decision points on a paths Object-Oriented Analysis and Design with the Unified Process

11. Figure 9-4 Statechart for Order Object-Oriented Analysis and Design with the Unified Process

12. Figure 9-5 Design statechart for Order Object-Oriented Analysis and Design with the Unified Process

13. Design Principles-Protection From Variations • Parts of a system that are unlikely to change are segregated from those that will • Drives the multilayer design pattern • Stable business logic can be protected from variations in the user interface • Changes in the business logic are isolated to the controller class Object-Oriented Analysis and Design with the Unified Process

14. Design Principles-Indirection • Indirection is an implementation of the protection from variations principle • Decouples classes or other system components by placing an intermediate classes between them • Used in many corporate security systems between an internal network and the Internet • A proxy server catches all incoming messages and redistributes them to the recipients Object-Oriented Analysis and Design with the Unified Process

15. Importance of Design Patterns • Standard design templates can speed OO design • Patterns can exist at different levels of abstraction • At the most concrete level, a class definition with code • At the most abstract level, an approach to a problem • Patterns should contain five main elements • Pattern name, problem, solution, example, benefits and consequences Object-Oriented Analysis and Design with the Unified Process

16. Figure 9-6 Pattern description for the controller pattern Object-Oriented Analysis and Design with the Unified Process

17. Basic Design Patterns • The authors of Elements of Reusable Object-Oriented Software (referred to as the Gang of Four) developed a basic classification scheme for patterns (Figure 9-7) • The 23 GoF patterns are some of the most fundamental and important patterns in use • Scores of other patterns have been defined • For example, both Java and .NET have sets of enterprise patterns Object-Oriented Analysis and Design with the Unified Process

18. Figure 9-7 Classification of design patterns Object-Oriented Analysis and Design with the Unified Process

19. Singleton Pattern • For classes that must have only one instance, but need to be invoked from several classes and locations within the system • The class itself controls the creation of only one instance • A static variable of the class refers to the object that is created • A class method instantiates the object on the first call, and returns a reference to the object on subsequent calls Object-Oriented Analysis and Design with the Unified Process

20. Figure 9-8 Singleton pattern template Object-Oriented Analysis and Design with the Unified Process

21. Adaptor Pattern • Plugs an external class into a system • Converts the method calls from within the system to match the method names in the external class • A standard solution for protection from variations • Insulates the system from frequently changing classes • An interface is frequently used to specify and enforce the use of correct method names Object-Oriented Analysis and Design with the Unified Process

22. Figure 9-10 Adapter pattern template Object-Oriented Analysis and Design with the Unified Process

23. Observer pattern • Used to handle event-processing and reduce coupling • The domain class • Allows other classes to “subscribe” as listeners • “Publishes” the changes to the listeners • The windows class • Sends a reference of itself to subscribe as a listener • Implements the method to be invoked when notified • Inherits the method from the listener interface Object-Oriented Analysis and Design with the Unified Process

24. Figure 9-11 Three classes in the Create new order use case Object-Oriented Analysis and Design with the Unified Process

25. Figure 9-12 Implementation of the observer pattern Object-Oriented Analysis and Design with the Unified Process

26. Figure 9-13 Observer pattern template Object-Oriented Analysis and Design with the Unified Process

27. Designing Enterprise-level Systems • Enterprise-level systems share components among multiple people or groups in an organization • Enterprise-level systems almost always use multiple tiers of computers • Can be client/server network-based or Internet based • Designed with deployment diagrams • A type of implementation diagram that shows physical components across different locations Object-Oriented Analysis and Design with the Unified Process

28. Figure 9-14 Differences between client/server and Internet systems Object-Oriented Analysis and Design with the Unified Process

29. UML Notation for Deployment Diagrams • Component • Executable module or program • Has an application program interface (API) that is available to the outside world • Node • A physical entity at a specific location • Frameset • A high-level object that holds items to be displayed by a browser Object-Oriented Analysis and Design with the Unified Process

30. Figure 9-15 UML component notation Object-Oriented Analysis and Design with the Unified Process

31. Figure 9-16 UML node notation Figure 9-17 UML extension for frameset Object-Oriented Analysis and Design with the Unified Process

32. Simple Internet Architecture • Used for viewing static information • The browser component executes on the client computer • The Internet server component executes on the server computer • Pages reside on the server and are sent to the browser for display • Program logic is inserted through scripting languages, applets, or other controls Object-Oriented Analysis and Design with the Unified Process

33. Figure 9-18 Simple Internet architecture Object-Oriented Analysis and Design with the Unified Process

34. Two-layer Architecture • Primarily captures information from the user and updates the database • The domain layer and data access layer are usually combined • Input data is sent to a CGI or an application server • The user-interface classes often contain the business logic and data access • Processing takes place with servlets (Java) or code behind classes (.NET) Object-Oriented Analysis and Design with the Unified Process

35. Figure 9-19 Two-layer Internet architecture Object-Oriented Analysis and Design with the Unified Process

36. Three-layer Architecture • Separates domain layer and data access layers • Necessary for systems with complex business logic or multiple user interfaces • Using CGI • Provide a use case controller for each form • Using an application server • Java tools: Java Server Pages and servlets • .NET tools: Common Runtime Language and code behind classes Object-Oriented Analysis and Design with the Unified Process

37. Figure 9-20 Three-layer Internet architecture Object-Oriented Analysis and Design with the Unified Process

38. Web Services • A program that provides a service via the Internet • The service is posted in a directory so that systems can find it • Requests for information go to the UDDI directory • UDDI provides the Internet address of a program offering that service • The application then requests the information • All communication is based on XML to allow for generic data exchange Object-Oriented Analysis and Design with the Unified Process

39. Figure 9-21 Invoking a Web service Object-Oriented Analysis and Design with the Unified Process

40. Summary • Design statecharts • Specify precise behavior and constraints of the various portions of the final system • Describe the method logic within an object • Good design is based on two factors • Good principles • Standard design patterns Object-Oriented Analysis and Design with the Unified Process

41. Summary (continued) • Protection from variations • Separates components that are likely to change • Indirection • Intermediate class provides an interface between elements • Design pattern examples • Singleton • Adaptor • Observer Object-Oriented Analysis and Design with the Unified Process