COMS W4156: Advanced Software Engineering - PowerPoint PPT Presentation

1 / 88
About This Presentation

COMS W4156: Advanced Software Engineering


COMS W4156: Advanced Software Engineering Prof. Gail Kaiser – PowerPoint PPT presentation

Number of Views:176
Avg rating:3.0/5.0
Slides: 89
Provided by: GailK154


Transcript and Presenter's Notes

Title: COMS W4156: Advanced Software Engineering

COMS W4156 Advanced Software Engineering
  • Prof. Gail Kaiser
  • http//

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

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 and development processes
  • Provide a formal basis for understanding the
    modeling language
  • Encourage the growth of the OO tools market
  • Support higher-level development concepts such as
    collaborations, frameworks, patterns and
  • Integrate best practices

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

The Challenge
The Vision
History of UML
  • OO modeling languages appeared in 1980s as
    various methodologists experimented with
    different approaches to object-oriented analysis
    and design
  • The number of OO modeling languages exploded
    during early 1990s
  • Many users had trouble finding complete
    satisfaction in any one modeling language,
    fueling the "method wars
  • By the mid-1990s, revisions of these methods
    began to appear that incorporated each others

History of UML
  • Unified Modeling Language
  • In 1994, Grady Booch and Jim Rumbaugh of Rational
    Software Corporation began unifying the Booch OO
    design and OMT (Object Modeling Technique) OO
    analysis methods
  • In 1995, Ivar Jacobsons Objectory company was
    acquired by Rational, merging in the OOSE
    (Object-Oriented Software Engineering) method
  • Three amigos released UML 0.9 in 1996
  • 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

History of UML
  • In June 1996, the Object Management Group (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
  • 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
  • Later versions 1.2, 1.3, 1.4, 1.4.2 (also ISO),
    1.5, 2.0
  • UML 2.0 adopted October 2004 - but some parts
    still not available, 2.1 already in progress

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
  • The basic building blocks (syntax) of UML are
  • Model elements (classes, interfaces, components,
    use cases)
  • Relationships (associations, generalization,
  • Diagrams (class diagrams, use case diagrams,
    interaction diagrams)
  • Used to create large, complex structures
  • Each UML diagram is designed to let developers
    and customers view a software system from a
    different perspective and in varying degrees of

Use Case Modeling
  • Use case model a view of a system that
    emphasizes the behavior as it appears to outside
  • Partitions system functionality into interactions
    (use cases) that are meaningful to users or
    external systems (actors)
  • The use case diagram displays the relationships
    among actors and use cases
  • To show a use case on a use case diagram, draw an
    oval in the middle of the diagram and put the
    name of the use case in the center of, or below,
    the oval
  • To draw an actor (indicating a system user) on a
    use case diagram, you draw a stick person to the
    left or right of your diagram (some draw prettier
    stick people than others)
  • Use simple lines to depict relationships between
    actors and use cases

Use Cases
Use Case Diagram
  • Use case diagrams generally show groups of use
  • 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
  • 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

  • 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

  • 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

Core Elements
Core Relationships
Use Case Diagram
Use Case Relationships
Actor Relationships
Example Online HR System
Online HR System Update Benefits Use Case
  • Actors employee, employee account db,
    healthcare plan system, insurance plan system
  • Preconditions
  • Employee has logged on to the system and
    selected update benefits option
  • Basic course
  • System retrieves employee account from employee
    account db
  • System asks employee to select medical plan
    type include Update Medical Plan.
  • System asks employee to select dental plan type
    include Update Dental Plan.
  • Alternative courses
  • If health plan is not available in the
    employees area the employee is informed and
    asked to select another plan...

Online HR System Use Case Relationships
Structural Modeling
  • A view of a system that emphasizes the structure
    of the objects, including their classifiers,
    relationships, attributes and operations
  • Class diagrams model class structure and contents
    using design elements such as classes, packages
    and objects
  • A class diagram shows how the different entities
    (people, things, and data) relate to each other
  • It shows the static structures of the system (not
    dynamic or temporal)
  • A class diagram can be used to display logical
    classes, which are typically the kinds of things
    the business people in an organization talk about
    rock bands, CDs, radio play or home mortgages,
    car loans, and interest rates

Class Example
  • A class is depicted on the class diagram as a
    rectangle with three horizontal sections
  • The upper section shows the class's name
  • The middle section contains the class's
  • The lower section contains the class's operations
    (or "methods")

Class Diagram
  • Draw the inheritance (or generalization)
    relationship using a line with an arrowhead at
    the top pointing to the super class, where the
    arrowhead should a completed triangle
  • An association relationship should be a solid
    line if both classes are aware of each other
  • And a line with an open arrowhead if the
    association is known by only one of the classes
    (pointing to the class known by the other one)

  • The CDSalesReport class inherits from the Report
  • A CDSalesReport is associated with one CD, but
    the CD class doesn't know anything about the
    CDSalesReport class
  • The CD and the Band classes both know about each
    other, and both classes can be associated to one
    or more of each other

Two-way association
One-way association
Class Diagrams
Core Elements
Core Relationships
Class Diagram
  • Class diagrams can also be used to show
    implementation classes, which are the things that
    programmers typically deal with
  • An implementation class diagram will probably
    show some of the same classes as the logical
    classes diagram
  • The implementation class diagram won't be drawn
    with the same attributes, however, because it
    will most likely have references to things like
    Vectors and HashMaps
  • Kinds
  • Class diagram classifier view
  • Object diagram instance view

Classes compartments with names
Classes method body
Types and Implementation Classes
Interfaces Shorthand Notation
Association Ends
Ternary Associations
Derived Attributes and Associations
Composite Objects
Constraints and Comments
Adapted from Fig. 23 EJB 2.0.
Sequence Diagram
  • Sequence diagrams show a detailed flow for a
    specific use case or even just part of a specific
    use case
  • They show the calls between the different objects
    in their sequence
  • And can show, at a detailed level, different
    calls to different objects
  • 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
  • Start at the top left corner with the "driver"
    class instance that starts the sequence, then
    follow each message down the diagram

Sequence Example
Object instances to which the messages are sent
Sequence of messages/calls in time order
Sequence Diagram
  • Across the top of your diagram, identify the
    class instances (objects) by putting each class
    instance inside a box
  • In the box, put the class instance name and class
    name separated by a space/colon/space " "
    (e.g., myReportGenerator ReportGenerator)
  • If a class instance sends a message to another
    class instance, draw a line with an open
    arrowhead pointing to the receiving class
  • Place the name of the message/method above the
  • Optionally, you can draw a dotted line with an
    arrowhead pointing back to the originating class
  • Label the return value above the dotted line

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

Statechart Diagram
  • A statechart diagram models the different states
    that a class can be in and how that class
    transitions from state to state
  • It can be argued that every class has a state,
    but not every class should have a statechart
  • Only classes with "interesting" states e.g.,
    classes with three or more potential states
    during system activity should be modeled

(No Transcript)
Statechart Diagram Notation Set
  • The initial starting point, which is drawn using
    a solid circle
  • A transition between states, which is drawn using
    a line with an open arrowhead
  • A state, which is drawn using a rectangle with
    rounded corners
  • A decision point, which is drawn as an open
  • And one or more termination points, which are
    drawn using a circle with a solid circle inside
  • Begin with a starting point and a transition line
    pointing to the initial state of the class
  • Draw the states themselves anywhere on the
    diagram, and then simply connect them using the
    state transition lines

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

  • 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

  • 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

Activity Diagram
  • Activity diagrams show the procedural flow of
    control between two or more class objects while
    processing an activity
  • Activity diagrams can be used to model
    higher-level business process at the business
    unit level
  • Or to model low-level internal class actions
  • Activity diagrams are "less technical" in
    appearance, compared to sequence diagrams, and
    business-minded people tend to understand them
    more quickly

(No Transcript)
Activity Diagram Notation Set
  • Similar to that used in a statechart diagram
  • An activity diagram starts with a solid circle
    connected to the initial activity
  • The activity is modeled by drawing a rectangle
    with rounded edges, enclosing the activity's name
  • Activities can be connected to other activities
    through transition lines
  • Or to decision points that connect to different
    activities guarded by conditions of the decision
  • Activities that terminate the modeled process are
    connected to a termination point
  • Optionally, the activities can be grouped into
    swimlanes, which are used to indicate the object
    that actually performs the activity

  • 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

Initial activity
Activity rounded rectangle
Transition lines
Termination point
Implementation Diagrams
  • Show aspects of model implementation, including
    source code structure and run-time implementation
  • Kinds
  • Component diagram
  • Deployment diagram

Component Diagram
  • Provides a physical view of the system
  • Shows the dependencies that the software has on
    the other software components (e.g., software
    libraries) in the system
  • Components may be
  • Specified by classifiers (e.g., implementation
  • Implemented by artifacts (e.g., binary,
    executable, or script files)

Component Diagram
Component Diagram with Relationships
Example with 4 Components
  • Reporting Tool, Billboard Service, Servlet 2.2
    API, and JDBC API
  • The arrowed lines from the Reporting Tool
    component to the Billboard Service, Servlet 2.2
    API, and JDBC API components mean that the
    Reporting Tool is dependent on those three

Deployment Diagram
  • Shows how a system will be physically deployed in
    the hardware environment
  • Its purpose is to show where the different
    components of the system will physically run and
    how they will communicate with each other
  • Since the diagram models the physical runtime, a
    system's production staff will make considerable
    use of this diagram.

(No Transcript)
Deployment Diagram Notation
  • The notation in a deployment diagram includes the
    notation elements used in a component diagram,
    plus adding the concept of a node
  • A node represents either a physical machine or a
    virtual machine node (e.g., a mainframe node)
  • To model a node, simply draw a three-dimensional
    cube with the name of the node at the top of the
  • Use the naming convention used in sequence
    diagrams instance name instance type
    (e.g., " Application

Instance name instance type
Component packages
  • Users access the Reporting Tool by using a
    browser running on their local machine and
    connecting via HTTP over their company's intranet
    to the Reporting Tool
  • This tool physically runs on the Application
    Server named
  • The diagram shows the Reporting Tool component
    drawn inside of IBM WebSphere, which in turn is
    drawn inside of the node

  • The Reporting Tool connects to its reporting
    database using the Java language to IBM DB2's
    JDBC interface
  • Which then communicates to the actual DB2
    database running on the server named
    using native DB2 communication
  • In addition to talking to the reporting database,
    the Report Tool component communicates via SOAP
    over HTTPS to the Billboard Service

  • 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
  • Structural modeling specifies a skeleton that can
    be refined and extended with behavior and other
  • Use case modeling specifies the functional
    requirements of system in an object-oriented

  • http// The official UML Web site
  • http// Information on Argo
    UML, an open source UML modeling tool built in
  • http//
    Information on Umbrello UML Modeller, an open
    source UML modeling tool for KDE

Project Deliverables
  • Project concept (P/F)
  • Revised concept (P/F)
  • First iteration (25)
  • 1st iteration plan (5)
  • 1st iteration progress report (5)
  • 1st iteration demo (5)
  • 1st iteration final report (10)
  • Second iteration (25)
  • 2nd iteration plan
  • Code inspection
  • 2nd iteration progress report
  • 2nd iteration demo
  • 2nd iteration final report

  • First demo week November 8-14
  • First iteration final report due November 14th
  • Second iteration plan due November 21st

Second Iteration Plan due Tuesday November 21st
  • There are four main goals for this second
  • Complete your application if not already
    completed by the end of the first iteration.
    (Enhancements optional.)
  • Conduct semi-formal unit testing.
  • Participate in a semi-formal code inspection.
  • Investigate the security and robustness
    properties of your small systems.

Unit Testing
  • For each pair in your team, select one
    non-trivial "unit" of your code (two units for a
    team with two pairs and one unit for a team with
    one pair/triplet)
  • Unit should correspond to a component or class,
    not just an individual subroutine
  • Selected unit(s) should be among those most
    likely to include remaining flaws, not those
    least likely
  • Define a set of equivalence classes and
    corresponding boundary values, where applicable
    (black box)
  • Elaborate your strategy for ensuring that your
    test suite adequately covers the unit's
    statements and branches (white box)
  • The goal is to find as many flaws as possible,
    not to demonstrate that your code "works!
  • You do not need to supply the actual test cases
    yet that will be part of the second iteration
    interim progress report

Code Inspection
  • For each pair in your team, select a different
    non-trivial "unit" of your code than for unit
  • Prepare a "checklist"  for your upcoming code
    inspection meeting, e.g., including coding
    conventions and level of commenting
  • Remember the goal of the meeting is to find as
    many flaws as possible, not to nitpick coding
  • Schedule a 30-40 minute meeting with your TA to
    conduct the actual code inspection between
    Tuesday November 28th through Monday December 4th
    (class time will be available Nov 28 and Nov 30)
  • All team members must be present
  • One member of each pair designated as the
    "reader" for that pair's code
  • The TA will be the "moderator
  • The findings from your code inspection meeting
    will be part of the second iteration interim
    progress report, but you do not need to fix any
    flaws found until the final demo

Security and Robustness
  • Develop an "attack plan" to try to BREAK your
  • Security testing (e.g., violate login
    authorization scheme, overflow a buffer, inject
    extraneous commands into an underlying database)
  • Stress testing (e.g., cause core dumps or system
  • Tests should generally operate at the system
    level, but not necessarily through the user
  • A successful test is one that finds a flaw!
  • You are not required to fix these flaws 
  • You will need to document your test cases and any
    flaws they found (as well as any optional repairs
    made) in your second iteration final report

  1. Cover page
  2. Unit testing Identify the chosen unit(s) and
    explain the black box equivalence classes and
    boundary value analysis.  Discuss any scaffolding
    you expect to need. Describe your strategy for
    ensuring that your test suite, including white
    box as well as black box test cases, adequately
    covers the unit's statements and branches.
    Present a set of engineering tasks that will
    construct and execute your black and white box
    unit test suite.
  3. Code inspection Identify the chosen unit(s) and
    elaborate your checklist.  Discuss any
    engineering tasks expected prior to and as follow
    up to the code inspection meeting.
  4. Security and robustness Develop a set of
    engineering tasks focused on security/stress
    testing of your systems, particularly how you
    will develop, prepare and execute your tests.
  5. Schedule  Give a complete schedule including all
    the engineering tasks for unit testing, code
    inspection and security/stress testing.
  6. Controversies

COMS W4156 Advanced Software Engineering
  • Prof. Gail Kaiser
  • http//
Write a Comment
User Comments (0)