MODULE 13:

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer 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. 13-2

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer 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. 13-3

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer Using Sequence Diagrams Use sequence diagrams to: ◦ document designs of methods and use cases ◦ document existing code ◦ document debug traces 13-4

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer Sequence Diagram Example 13-5

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer 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). 13-6

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer Alternative Terms Different methodologies use various terms to describe methods: ◦ service ◦ operation ◦ responsibility ◦ member function 13-7

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer 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. 13-8

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer 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. 13-9

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer 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) 13-10

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer 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

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer 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-12

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer 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 13-13

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer 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

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer 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) 13-15

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer 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

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer Creating a Sequence Diagram Decide on the perspective: ◦ use case ◦ computational process ◦ operation Define the start of the sequence diagram: ◦ actor ◦ controller ◦ start activity 13-17

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer Sequence Diagram for a Use Case or 13-18

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer Sequence Diagram for a Method 13-19

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer Showing Object Interactions 13-20

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer Showing Loops 13-21

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer Showing Alternate Flows 13-22

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer Communication Diagrams A communication diagram emphasizes 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

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer Communication Diagram Example 13-24

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer Data Flows Data Flow Tokens 13-25

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer Iterations and Conditions Iterations and conditional operations can be visually indicated with '*' and '[…]' adornments

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer Indicating Object Creation 13-27

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer Message Icon Adornments The message icon can be adorned to indicate the synchronization mechanism: simple synchronous balking timeout asynchronous 13-28

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer Examples of Message Semantics 13-29

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer Sequence Diagram Example 13-30

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer Module Review In this module we learned that: ◦ sequence diagrams illustrate the detailed message passing between objects 13-31

Principles of Information Systems Analysis & DesignDesign © 2009 by Dr. Martin Schedlbauer 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