november 5, 2009coms w41561 coms w4156: advanced software engineering prof. gail kaiser...
Post on 31-Dec-2015
215 Views
Preview:
TRANSCRIPT
November 5, 2009 COMS W4156 1
COMS W4156: Advanced Software Engineering
Prof. Gail Kaiser
Kaiser+4156@cs.columbia.edu
http://bank.cs.columbia.edu/classes/cs4156/
November 5, 2009 COMS W4156 2
Topics covered in this lecture
• UML Overview
• Use cases
• Sequence diagrams
• Statecharts
• Activity diagrams
November 5, 2009 COMS W4156 3
Introduction toUnified Modeling Language
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 7
History of UML
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 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”
November 5, 2009 COMS W4156 10
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
November 5, 2009 COMS W4156 11
The Challenge
November 5, 2009 COMS W4156 12
The Vision
November 5, 2009 COMS W4156 13
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
November 5, 2009 COMS W4156 14
• 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
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 16
Use Cases
November 5, 2009 COMS W4156 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”)
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 19
Use Cases and Actors
November 5, 2009 COMS W4156 20
Use Case Diagram Example
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 22
Example with Multiple User Roles
Actors
Actor
Use Cases
Relationships
Relationship
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 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)
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 27
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
November 5, 2009 COMS W4156 28
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>>
November 5, 2009 COMS W4156 29
Generalization
• Applies to both user roles and to use cases
November 5, 2009 COMS W4156 30
Association
• Optional arrowhead shows direction of control
November 5, 2009 COMS W4156 31
Association Multiplicity
• Optional multiplicity values at each end
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 33
Extending Use Cases
• One use case may be used to extend the behavior of another, typically in exceptional circumstances
November 5, 2009 COMS W4156 34
Extension Points
• The point at which an extending use case is added
November 5, 2009 COMS W4156 35
Sequence Diagrams
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 38
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
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 40
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
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 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)
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 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 lifeline’s execution occurrence
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 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
• …
November 5, 2009 COMS W4156 52
Statecharts
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 54
Example Statechart
November 5, 2009 COMS W4156 55
Another Example Statechart
November 5, 2009 COMS W4156 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)
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 62
State Actions
• Effects can be associated with states rather than individual transitions
• Defined On Entry and/or On Exit
November 5, 2009 COMS W4156 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• …
November 5, 2009 COMS W4156 64
That was all very complicated
How about something simpler?
November 5, 2009 COMS W4156 65
Activity Diagrams
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 67
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 69
Swimlanes
Initial activity
Activity = rounded rectangle
Transitionlines
Terminationpoint
November 5, 2009 COMS W4156 70
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
November 5, 2009 COMS W4156 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…
November 5, 2009 COMS W4156 72
• 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
November 5, 2009 COMS W4156 73
Final Notes
November 5, 2009 COMS W4156 74
Next Assignment
• Demos November 4th-12th
November 5, 2009 COMS W4156 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
November 5, 2009 COMS W4156 76
COMS W4156: Advanced Software Engineering
Prof. Gail Kaiser
Kaiser+4156@cs.columbia.edu
http://bank.cs.columbia.edu/classes/cs4156/
top related