COMS W4156: Advanced Software Engineering

1
COMS W4156 Advanced Software Engineering

• Prof. Gail Kaiser
• Kaiser4156_at_cs.columbia.edu
• http//bank.cs.columbia.edu/classes/cs4156/

2
Topics covered in this lecture

• UML Overview
• Use cases
• Sequence diagrams
• Statecharts
• Activity diagrams

3
Introduction toUnified Modeling Language
4
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

5
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

6
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

7
History of UML
8
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

9
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

10
Why do we model?

• Unified Modeling Language
• Provide structure for problem solving
• Furnish abstractions to manage complexity
• Experiment to explore multiple solutions

Why do we model graphically?

• Graphics reveal content, structure,
• 1 bitmap 1 megaword

11
The Challenge
12
The Vision
13
Our Focus the Language

• Unified 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

14
Building Blocks

• 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

15
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

16
Use Cases
17
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)

18
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

19
Use Cases and Actors
20
Use Case Diagram Example
21
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

22
Example with Multiple User Roles
Relationships
Use Cases
Actors
Actor
Relationship
23
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

24
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

25
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)

26
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

27
Core Elements
28
Core Relationships
ltltextendgtgt
29
Generalization

• Applies to both user roles and to use cases

30
Association

• Optional arrowhead shows direction of control

31
Association Multiplicity

• Optional multiplicity values at each end

32
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

33
Extending Use Cases

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

34
Extension Points

• The point at which an extending use case is added

35
Sequence Diagrams
36
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

37
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

38
Sequence Example
Object instances to which the messages are sent
Sequence of messages/calls in time order
39
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

40
Example
Identify the objects as class instance name
class name
Draw a line for each message, with an arrowhead
pointing to the receiving class instance
Draw a dotted line for each return value, with an
arrowhead pointing back to the originating class
instance
41
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

42
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

43
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

44
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

45
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)

46
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

47
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 lifelines execution occurrence

48
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

49
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

50
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

51
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

52
Statecharts
53
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

54
Example Statechart
55
Another Example Statechart
56
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)

57
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

58
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

59
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

60
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

61
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

62
State Actions

• Effects can be associated with states rather than
  individual transitions
• Defined On Entry and/or On Exit

63
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

64
That was all very complicated

• How about something simpler?

65
Activity Diagrams
66
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

67
(No Transcript)
68
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

69
Swimlanes
Initial activity
Transition lines
Activity rounded rectangle
Termination point
70
Example Discussion
Swimlanes

• 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
Activity rounded rectangle
Transition lines
Termination point
71
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

72
Resources

• 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/ -
  IBMs UML resource center (IBM bought Rational in
  2002)

73
Final Notes
74
Next Assignment

• Demos November 4th-12th

75
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

76
COMS W4156 Advanced Software Engineering

• Prof. Gail Kaiser
• Kaiser4156_at_cs.columbia.edu
• http//bank.cs.columbia.edu/classes/cs4156/