Module 13:

1. Module 13:

2. Visualizing Scenarios • UML offers three diagrams for describing use cases and interactions in detail: • activity diagram • interaction diagrams: • sequence diagram • communication (collaboration) diagram • Interaction diagrams focus on the objects and methods and are used in design. • Activity diagrams are used to document the overall flow and are used in analysis.

3. Sequence Diagrams • A sequence diagram emphasizes the sequence of steps for a particular system transaction or use-case scenario. • Sequence diagrams are frequently enhanced by scripts. • The scripts are refinements of the scenario traces made during analysis.

4. Using Sequence Diagrams • Use sequence diagrams to: • document designs of methods and use cases • document existing code • document debug traces

5. Sequence Diagram Example

6. Methods • Two definitions: • A method is a function or transformation that may be applied to objects. (Rumbaugh) • A method is an action that one object performs upon another in order to elicit a response. (Booch) • All objects of a class possess the same set of methods (interface).

7. Alternative Terms • Different methodologies use various terms to describe methods: • service • operation • responsibility • member function

8. Method Examples • Some simple examples of methods are: • Scheduler: addEvent, removeEvent • Account: payInterest, withdraw • Investor: getName, changeAddress • Portfolio: computeValue • Methods that don't change the object are called accessors, whereas modifiers change the state of the object.

9. Signature • The signature of a method contains: • the method name • the type of its arguments • The signature is part of a C++ or Java function’s prototype. • The concept of signature is important to polymorphism.

10. Polymorphism • Two definitions: • Polymorphism is the ability of two or more classes to respond to the same message, each in its own way. (Wirfs-Brock) • Polymorphism means that the sender of a message does not need to know the receiving object’s type. (Jacobson)

11. Defining Methods • There are two approaches: • look at each class and define the methods that the class could use • look at how the class is used in specific use-case scenarios and assign each step to a method of a class; if no class can take on the responsibility, define a new class • To understand what a class does, you must understand how it is being used.

12. Guidelines for Methods • A well-designed method should: • carry out a single activity • have a meaningful name (e.g. getBalance, computeValue, addItem) • avoid input flags • take few or no parameters • not switch on the value of an attribute

13. Categories of Classes • A software architecture contains several categories of classes: • Business Entity Classes • User Interface Classes • Support and Data Structure Classes • Device Encapsulation Classes • Proxy and Wrapper Classes • Controller Classes

14. Encapsulating Use Cases • Classes in a software architecture should be as independent as possible to increase the stability of the system. • Use case flow is contained within Controller or Agent classes. • Each use case is represented by one or more controller classes. • Controllers encapsulate business process.

15. Controller Framework This is the well-known Model-View-Controller (MVC) framework for designing modern service-oriented applications, including web applications (e.g., JSF, Rails)

16. Naming Controller Classes • Use case controller classes should be named based on the use cases they represent: • Use Case Names: • Record Sales • Generate Monthly Report • Controller Names: • SalesRecorder • MonthlyReportGenerator • Each time a particular use case must be carried out, a corresponding controller object is instantiated and a method of that controller object is invoked. • The controller should delegate its work to the domain objects; it should regulate the flow of control, but not do any work.

17. Creating a Sequence Diagram • Decide on the perspective: • use case • computational process • operation • Define the start of the sequence diagram: • actor • controller • start activity

18. Sequence Diagram for a Use Case or

19. Sequence Diagram for a Method

20. Showing Object Interactions

21. Showing Loops

22. Showing Alternate Flows

23. Communication Diagrams • A communication diagramemphasizes links between objects and data flow along those links. • Communication diagrams do not have an associated script and have a more relaxed layout. • Communication diagrams were called collaboration diagrams in UML 1.4.

24. Communication Diagram Example

25. Data Flows Data Flow Tokens

26. Iterations and Conditions Iterations and conditional operations can be visually indicated with '*' and '[…]' adornments.

27. Indicating Object Creation

28. Message Icon Adornments • The message icon can be adorned to indicate the synchronization mechanism: simple timeout asynchronous synchronous balking

29. Examples of Message Semantics

30. Sequence Diagram Example

31. Module Review • In this module we learned that: • sequence diagrams illustrate the detailed message passing between objects

32. References • Kratochvil, M., & McGibbon, B. (2003). UML xtra-light: How to Specify Your Software Requirements. Cambridge University Press. • A short book on UML that keeps to the essentials. Explains how to get from use cases to requirements and how to model the requirements with use case, activity, class, and state diagrams. • Fowler, M. (2004). UML Distilled, 3rd Edition. Addison-Wesley Pearson. • A great reference book on UML that’s just detailed enough and not too confusing. Contains an explanation of all UML diagrams and is more geared towards developers. • Object Management Group (2007). UML Specification with UML Activity Diagrams. www.omg.org.