COMS W4156: Advanced Software Engineering - PowerPoint PPT Presentation

Loading...

PPT – COMS W4156: Advanced Software Engineering PowerPoint presentation | free to download - id: 7d80f2-MDMwM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

COMS W4156: Advanced Software Engineering

Description:

COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156_at_cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/ – PowerPoint PPT presentation

Number of Views:51
Avg rating:3.0/5.0
Slides: 73
Provided by: GailK151
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: COMS W4156: Advanced Software Engineering


1
COMS W4156 Advanced Software Engineering
  • Prof. Gail Kaiser
  • Kaiser4156_at_cs.columbia.edu
  • http//york.cs.columbia.edu/classes/cs4156/

2
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 (blueprints)
  • Helps project teams communicate, explore
    potential designs, and validate the requirements
    and architectural design of the software system

3
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 extend the core concepts
  • Be independent of particular programming
    languages, design methodologies and development
    processes
  • Encourage the growth of the OO tools market
  • Support higher-level development concepts such as
    frameworks, patterns and components
  • Integrate best practices

4
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

5
The Challenge
6
The Vision
7
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 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

8
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 OO 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

9
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 the 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 ISO
  • UML 2.0 adopted by OMG in October 2000, most
    recent UML 2.1.1 February 2007

10
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

11
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

12
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
  • Interaction
  • State
  • Structural
  • Implementation

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

14
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 to depict relationships between
    actors and use cases

15
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" (human users who will
    interact with the system) to essential processes
  • relationships among different use cases

16
Use Cases and Actors
17
Use Case Diagram Example
18
Example with Multiple User Roles
Relationships
Use Cases
Actors
Actor
Relationship
19
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
    security administration-related use cases)
  • By looking at a use case diagram, you can easily
    tell the functions that the system provides

20
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

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

22
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 Listen to
    Songs from Billboard 200

23
Core Elements
24
Core Relationships
ltltextendgtgt
25
Generalization
  • Applies to both user roles and to use cases

26
Association
  • Optional arrowhead shows direction of control

27
Association Multiplicity
  • Optional multiplicity values at each end

28
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

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

30
Extension Points
  • The point at which an extending use case is added

31
Behavioral Modeling
  • Capture 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

32
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 even just part of a specific
    use case
  • They show the calls or messages between the
    different objects in their sequence, using a
    vertical timeline

33
Sequence Diagram
  • 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

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

36
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
37
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

38
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

39
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

40
Sequence 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

41
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 which owns the
    sequence diagram

42
Messages
  • Messages are displayed as arrows
  • Messages can 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)

43
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

44
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

45
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

46
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

47
Duration and Time Constraints
  • When modeling a real-time system or a time-bound
    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

48
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

49
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
  • Describe 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

50
Example Statechart
51
Another Example Statechart
52
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)

53
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

54
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

55
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

56
Notation Example
  • By looking at the diagram, a person 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
  • A person can also tell that all loans will end in
    either the Loan Rejected state or the Loan in
    Maintenance state

57
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

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

59
Other Statechart Notation
  • Self-Transitions return to same state
  • Compound show sub-statecharts within a state
  • Composite allow 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

60
That was all very complicated
  • How about something simpler?

61
Activity Diagram
  • Aka dynamic model
  • Show 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

62
(No Transcript)
63
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

64
Swimlanes
Initial activity
Transition lines
Activity rounded rectangle
Termination point
65
Example Discussion
Swimlanes
  • Two swimlanes show two objects that control
    separate activities a band manager and a
    reporting tool
  • 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
66
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

67
More UML next time
68
Summary So Far
  • UML is effective for modeling large, complex
    software systems
  • It is simple to learn for most developers, but
    provides advanced features for expert analysts,
    designers and architects
  • It can specify systems in an implementation-indepe
    ndent manner
  • 10-20 of the constructs are used 80-90 of the
    time
  • Use case modeling specifies the functional
    requirements of system
  • Behavioral modeling specifies the interactions
    that occur during and across use cases

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

70
First Iteration Demos Due!
  • October 30th November 8th
  • Extra credit on per-day-early sliding scale
  • Only team members present for the demo (for CVN
    virtually present) will receive credit 10 of
    final grade
  • No presentation needed, but be prepared to
    answer questions, show your code, and let the TA
    enter input to your system

71
Upcoming Deadlines
  • First iteration final report due Friday November
    9th, must respond to any issues that arose
    during demo
  • Midterm Individual Assessment posted Friday
    November 9th
  • Midterm Individual Assessment due Friday November
    16th
  • 2nd iteration starts

72
COMS W4156 Advanced Software Engineering
  • Prof. Gail Kaiser
  • Kaiser4156_at_cs.columbia.edu
  • http//york.cs.columbia.edu/classes/cs4156/
About PowerShow.com