November 5, 2009COMS W41561 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser [email protected]

November 5, 2009 COMS W4156 1

COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]

http://bank.cs.columbia.edu/classes/cs4156/

mailto:[email protected]



Topics covered in this lecture

• UML Overview

• Use cases

• Sequence diagrams

• Statecharts

• Activity diagrams


Introduction toUnified Modeling Language


What is UML?

• UML = Unified Modeling Language • A standard language for specifying, visualizing,

constructing and documenting software artifacts• Standardized by Object Management Group (OMG)• Uses mostly graphical notations• Helps project teams communicate, explore potential

designs, and validate the requirements and architectural design of the software system

http://www.uml.org/


History of UML Unified Modeling Language• In 1994, Grady Booch and Jim Rumbaugh of

Rational Software Corporation began unifying the Booch and OMT (Object Modeling Technique) methods developed in the late 1980s

• In 1995, Ivar Jacobson and his Objectory company joined Rational, merging in the OOSE (Object-Oriented Software Engineering) method

• The “three amigos” released UML 0.9 in 1996

http://cs-exhibitions.uni-klu.ac.at/index.php?id=447





History of UML

• The 3 methods were already evolving toward each other independently - it made sense to continue that evolution together rather than apart

• By unifying semantics and notation, they could bring some stability to the tool marketplace, allowing projects to settle on one mature modeling language and letting tool builders focus on delivering more useful features

• They expected that their collaboration would yield improvements in all 3 earlier methods, helping to address problems that none previously handled well


History of UML


History of UML

• In June 1996, OMG issued a Request for Proposals (RFP) for an industry-standard modeling language

• Rational established the UML Partners consortium, seeking organizations willing to dedicate resources to work toward a strong UML 1.0 definition

• UML 1.0 was submitted to OMG in January 1997 as an initial RFP response

• UML 1.1 was adopted by OMG in November 1997• Various later 1.x versions, with 1.4.2 adopted by International

Organization for Standardization (ISO)• UML 2.0 adopted by OMG in October 2000, with 2.1.2

adopted by ISO• Most recent UML 2.2 released in February 2009

http://www.iso.org/iso/home.htm

http://www.omg.org/spec/UML/2.2/


Goals of UML• Provide users with a ready-to-use, expressive visual

modeling language so they can develop and exchange meaningful models

• Provide extensibility and specialization mechanisms to augment the core concepts

• Be independent of particular programming languages, design methodologies and development processes

• Encourage the growth of the tools market• Support higher-level development concepts such as

frameworks, components and patterns• Integrate “best practices”


Unified Modeling Language

• Provide structure for problem solving

• Furnish abstractions to manage complexity

• Experiment to explore multiple solutions

Why do we model?

Why do we model graphically?• Graphics reveal content, structure, …

• 1 bitmap = 1 megaword


The Challenge


The Vision


Our Focus: the LanguageUnified Modeling Language

• Language = syntax + semantics– Syntax = rules by which language elements

(e.g., words) are assembled into expressions (e.g., phrases, clauses)

– Semantics = rules by which syntactic expressions are assigned meanings


• The basic building blocks (syntax) of UML are:– Model elements (classes, interfaces, components,

use cases)– Relationships (associations, generalization,

dependencies)– Diagrams (class diagrams, use case diagrams,

interaction diagrams)

• Simple building blocks are used to create large, complex structures

Building Blocks


Types of UML Diagrams

• Each UML diagram is designed to let developers and customers view a software system from a different perspective and in varying degrees of abstraction– Use Case– Behavioral– Structural– Implementation


Use Cases


Use Case Modeling

• Aka User Interaction or Requirements Model• View of a system that emphasizes high-level

behavior as it appears to outside users• Describes the boundary and interaction between the

system and users (or external systems)• Partitions system functionality into interactions or

units of work (“use cases”) that are meaningful to particular user roles or external systems (“actors”)


Use Case Diagram

• Displays the relationships among actors and use cases

• To show a use case, draw an oval in the middle of the diagram and put the name of the use case in the center of, or next to, the oval

• To draw an actor on a use case diagram, draw a stick person to the left or right of your diagram, labeled with the user role

• Use simple lines (sometimes lines with arrows) to depict relationships between actors and use cases


Use Cases and Actors


Use Case Diagram Example


Use Case Diagram

• A use case illustrates a single unit of meaningful work provided by the system, as a dialog

• NOT necessarily related to software modules• The main purpose is to help development teams

visualize the functional requirements of a system– relationship of actors to essential processes– relationships among different use cases


Example with Multiple User Roles

Actors

Actor

Use Cases

Relationships

Relationship


Use Case Diagram

• Use case diagrams generally show groups of use cases– either all use cases for the complete system– or a breakout of a particular collection of use

cases with related functionality (e.g., all use cases related to security administration)

• By looking at a use case diagram, you can easily tell the functions that the system provides


Example• This system lets the band

manager view a sales statistics report and the Billboard 200 report for the band's CDs

• It lets the record manager view a sales statistics report and the Billboard 200 report for a particular CD

• The diagram also tells us that our system delivers Billboard reports from an external system Billboard Reporting Service


Use Case Diagram

• The absence of use cases in the diagram shows what the system doesn't do

• With clear and simple use case descriptions provided on such a diagram, a project sponsor can easily see if needed functionality is present or not present in the system (system scope)


Example

• This use case diagram does not provide a way for a band manager to listen to songs from the different albums on the Billboard 200 — i.e., we see no reference to a use case called anything like Listen to Songs


Core ElementsConstruct Description Syntax

use case A sequence of actions that a system (or other entity) can perform, including variants, interacting with actors of the system.

actor A coherent set of roles that users of use cases play when interacting with these use cases.

system boundary

Represents the boundary between the physical system and the actors who interact with the physical system.

UseCaseNam e

ActorNam e


Construct Description Syntax

association The participation of an actor in a use case. i.e., instance of an actor and instances of a use case communicate with each other.

generalization A taxonomic relationship between a more general use case and a more specific use case.

extend A relationship from an extension use case to a base use case, specifying how the behavior for the extension use case can be inserted into the behavior defined for the base use case.

include An relationship from a base use case to an inclusion use case, specifying how the behavior for the inclusion use case is inserted into the behavior defined for the base use case.

Core Relationships

<<extend>>


Generalization

• Applies to both user roles and to use cases


Association

• Optional arrowhead shows direction of control


Association Multiplicity

• Optional multiplicity values at each end


Including Use Cases

• Use cases may contain the functionality of another use case as part of their normal processing

• In general it is assumed that any included use case will be called every time the basic path is run


Extending Use Cases

• One use case may be used to extend the behavior of another, typically in exceptional circumstances


Extension Points

• The point at which an extending use case is added


Sequence Diagrams


Behavioral Modeling

• Captures the varieties of interaction and instantaneous states within a model as it executes over time

• Tracks how the system will act in a real-world environment

• Observes the effects of an operation or event, including its results


Interaction Model

• Describes how objects in the system will interact with each other to get work done - in time sequence

• Sequence diagrams show a detailed flow for a specific use case or just part of a specific use case

• They show the calls or messages between the different objects in their sequence, using a vertical timeline

• A sequence diagram has two dimensions:– The vertical dimension shows the sequence of

messages/calls in the time order that they occur– The horizontal dimension shows the object instances to

which the messages are sent


Sequence Example

Sequence of m

essages/calls in time order

Sequence of m

essages/calls in time order

Object instances to which the messages are sent


Sequence Diagram• Across the top of your diagram, identify the class

instances (objects) by putting each class instance inside a box

• If a class instance sends a message to another class instance, draw a line with an open arrowhead pointing to the receiving class instance, labeled with message name and, optionally, parameters

• Return value may also be indicated by annotating the calling arrow

• Or draw a dotted line with an arrowhead pointing back to the originating class instance, label the return value above the dotted line


Example

Identify the objects asIdentify the objects asclass instance name : class nameclass instance name : class name

Draw a line for each Draw a line for each message, with an message, with an arrowhead pointing to arrowhead pointing to the receiving class the receiving class instance instance

Draw a dotted line Draw a dotted line for each return for each return value, with an value, with an arrowhead pointing arrowhead pointing back to the back to the originating class originating class instanceinstance


Reading a Sequence Diagram

• Start at the top left corner with the "driver" class instance that starts the sequence

• Then follow each message down the diagram• Shows objects as lifelines running down the

page, with their interactions over time represented as messages drawn as arrows from the source lifeline to the target lifeline

• Not intended for showing complex procedural logic


Example Reading

• aServlet sends a message to the ReportGenerator class instance named gen

• The message is labeled generateCDSalesReport, which means that the ReportGenerator object implements this message handler

• The generateCDSalesReport message label has cdId in parentheses, which means that aServlet is passing a variable named cdId with the message


Example Reading• When gen instance receives a

generateCDSalesReport message, it then makes subsequent calls to the CDSalesReport class, and an actual instance of a CDSalesReport called aCDReport gets returned

• The gen instance then makes calls to the returned aCDReport instance, passing it parameters on each message call

• At the end of the sequence, the gen instance returns aCDReport to its caller aServlet


Lifelines• A lifeline represents an individual participant in a sequence

diagram• A lifeline will usually have a rectangle containing its object

name• If its name is "self", that indicates the lifeline represents the

classifier that owns the sequence diagram


Messages

• Messages are displayed as arrows

• Messages can be synchronous (calls) or asynchronous

• The first message is a synchronous message (denoted by the solid arrowhead) complete with an implicit return message; the second is asynchronous (line arrowhead); and the third is the asynchronous return message (dashed line)


Execution Occurrence

• A thin rectangle running down the lifeline denotes the execution occurrence, or activation of a focus of control

• The first execution occurrence is the source object sending two messages and receiving two replies; the second is the target object receiving a synchronous message and returning a reply; the third is the target object receiving an asynchronous message and returning a reply


Self Messages

• Can represent a recursive call of an operation, or one method calling another method belonging to the same object

• Shown as creating a nested focus of control in the lifeline’s execution occurrence


Lost and Found Messages• Lost messages are those

that are either sent but do not arrive at the intended recipient, or which go to a recipient not shown on the current diagram

• Found messages are those that arrive from an unknown sender, or from a sender not shown on the current diagram

• Denoted going to or coming from an endpoint element


Lifeline Start and End

• A lifeline may be created and/or destroyed during the timescale represented by a sequence diagram

• The symbol at the head of the lifeline is shown at a lower level down the page than the symbol of the object that caused the creation

• The lifeline is terminated by a stop symbol, represented as a cross


Duration and Time Constraints

• When modeling a real-time system or a time-bounded business process, it can be important to consider the length of time it takes to perform actions

• When setting a duration constraint for a message, the message will be shown as a sloping line


Other Sequence Diagram Notation

• Combined fragments depict a degree of procedural logic

• Gates act as off-page references

• Part decomposition for multiple lifelines from same object

• …


Statecharts


Statechart Diagram• A statechart (or state transition or state machine) diagram

models the different states that an object can be in and how that object transitions from state to state

• Describes the states or conditions that an instance of a class assumes over time, its “life history”

• Shows the events that transition from one state to another, and the actions that result from a state change

• It can be argued that every class has a state, but not every class should have a statechart diagram

• Only classes with "interesting" states — e.g., classes with three or more potential states during system activity — should be modeled


Example Statechart


Another Example Statechart


Statechart Diagram Notation Set

• The initial starting point, where flow of control starts, is drawn using a solid circle

• A transition between states is drawn using a line with an open arrowhead

• A state is drawn using a rounded rectangle, may have entrance/exit conditions

• A decision point is drawn as an open circle• One or more termination points are drawn using a

circle with a solid circle inside it (bulls eye)


Notation Example• Initial starting point - solid circle• Transition between states - line with arrowhead• State – rounded rectangle • Decision point - open circle• Termination points - circle with solid inner circle


Drawing a Statechart

• Begin with a starting point and a transition line pointing to the initial state of the class, end with a termination point

• Draw the states themselves anywhere on the diagram, and then simply connect them using the state transition lines


Notation Example• Begins in the Loan Application state• When the pre-approval process is done, depending on the outcome, you

move to either the Loan Pre-approved state or the Loan Rejected state• This decision, made during the transition process, is shown with a

decision point — the empty circle in the transition line


Notation Example• By looking at the diagram, one can tell that a loan cannot go from the

Loan Pre-Approved state to the Loan in Maintenance state without going through the Loan Closing state

• One can also tell that all loans will end in either the Loan Rejected state or the Loan in Maintenance state


State Transitions• May optionally have any subset of triggers, guards, effects, denoted

Trigger [Guard] / Effect on the transition line• Trigger is the cause of the transition, which could be a signal, an event, a

change in some condition, the passage of time, or automatic• Guard is a condition which must be true in order for the trigger to cause

the transition• Effect is an action which will be invoked directly on the object that owns

the state machine as a result of the transition


State Actions

• Effects can be associated with states rather than individual transitions

• Defined On Entry and/or On Exit


Other Statechart Notation

• Self-Transitions return to same state• Compound shows sub-statecharts within a state• Composite allows internal state machines to be

shown in separate diagram• Named alternative entry and exit points• Choice (dynamic) and junction (static) pseudo-states

for conditional branches• History states remember previous states• Various concurrency capabilities• …


That was all very complicated

How about something simpler?


Activity Diagrams


Activity Diagram

• Aka dynamic model• Shows the procedural flow of control between two or

more class objects while processing an activity• Can be used to model higher-level business process

at the business work unit level• Or to model low-level internal class actions• Activity diagrams are often "less technical" in

appearance, compared to sequence and statechart diagrams, and business-minded people tend to understand them more quickly



Activity Diagram Notation Set

• An activity diagram starts with a solid circle connected to the initial activity

• The activity is modeled by drawing a rounded rectangle, enclosing the activity's name

• Activities connected to other activities through transition lines

• Activities that terminate the modeled process are connected to a termination point (bulls eye)

• Typically activities are grouped into swimlanes, which indicate the object that actually performs the activity


Swimlanes

Initial activity

Activity = rounded rectangle

Transitionlines

Terminationpoint


Example Discussion• Two swimlanes show two objects

that control separate activities• The process starts with the band

manager electing to view the sales report for one of his bands

• The reporting tool then retrieves and displays all the bands that person manages and asks him to choose one

• After the band manager selects a band, the reporting tool retrieves the sales information and displays the sales report

• Displaying the report is the last step in the process

Initial activity

Swimlanes

Activity = rounded rectangle

Transitionlines

Terminationpoint


Additional Activity Diagram Notation

• May include decision points that connect to different activities guarded by conditions

• Synchronization bars can show how activities happen in parallel

• Optionally use full statechart notation in a sequence diagram style, but then no longer so simple…


• http://www.uml.org/ — The official UML Web site• http://argouml.tigris.org/ — Information on Argo UML,

an open source UML modeling tool built in Java• http://uml.sourceforge.net/index.php — Information on

Umbrello UML Modeller, an open source UML modeling tool for KDE

• http://www-306.ibm.com/software/rational/uml/ - IBM’s UML resource center (IBM bought Rational in 2002)

Resources

http://www.uml.org/

http://argouml.tigris.org/

http://uml.sourceforge.net/index.php

http://www-306.ibm.com/software/rational/uml/


Final Notes


Next Assignment

• Demos November 4th-12th


Upcoming Deadlines

• Demos November 4th-12th

• First Iteration Final Report due November 13th

• Midterm Individual Assessment available by November 13th, due November 20th

• Second Iteration Plan due November 24th

http://bank.cs.columbia.edu/classes/cs4156/homeworks/firstreport.htm

http://bank.cs.columbia.edu/classes/cs4156/homeworks/secondplan.htm


COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]


mailto:[email protected]


Documents

November 5, 2009COMS W41561 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser [email protected]