COMS W4156: Advanced Software Engineering - PowerPoint PPT Presentation

1 / 88
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:176
Avg rating:3.0/5.0
Slides: 89
Provided by: GailK154
Category:

less

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

8
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

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

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
  • 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)
  • 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
    abstraction

11
Use Case Modeling
  • Use case model a view of a system that
    emphasizes the behavior as it appears to outside
    users
  • 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

12
Example
Relationships
Use Cases
Actors
Actor
Relationship
13
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
  • 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

14
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

15
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

16
Core Elements
17
Core Relationships
ltltextendgtgt
18
Use Case Diagram
19
Use Case Relationships
20
Actor Relationships
21
Example Online HR System
22
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...

23
Online HR System Use Case Relationships
24
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

25
Example
26
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
    attributes
  • The lower section contains the class's operations
    (or "methods")

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

28
Example
  • The CDSalesReport class inherits from the Report
    class
  • 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

Inheritance
Two-way association
One-way association
29
Class Diagrams
30
Core Elements
31
Core Relationships
32
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

33
Classes compartments with names
34
Classes method body
35
Types and Implementation Classes
36
Interfaces Shorthand Notation
37
Associations
38
Association Ends
39
Ternary Associations
40
Composition
41
Generalization
42
Generalization
43
Dependencies
44
Dependencies
45
Derived Attributes and Associations
46
Objects
47
Composite Objects
48
Links
49
Constraints and Comments
50
Adapted from Fig. 23 EJB 2.0.
51
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

52
Sequence Example
Object instances to which the messages are sent
Sequence of messages/calls in time order
53
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
    instance
  • Place the name of the message/method above the
    line
  • Optionally, you can draw a dotted line with an
    arrowhead pointing back to the originating class
    instance
  • Label the return value above the dotted line

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

56
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

57
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
    diagram
  • Only classes with "interesting" states e.g.,
    classes with three or more potential states
    during system activity should be modeled

58
(No Transcript)
59
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
    circle
  • And one or more termination points, which are
    drawn using a circle with a solid circle inside
    it
  • 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

60
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

61
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

62
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

63
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

64
(No Transcript)
65
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
    point
  • 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

66
Example
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
67
Implementation Diagrams
  • Show aspects of model implementation, including
    source code structure and run-time implementation
    structure
  • Kinds
  • Component diagram
  • Deployment diagram

68
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
    classes)
  • Implemented by artifacts (e.g., binary,
    executable, or script files)

69
Components
70
Component Diagram
71
Component Diagram with Relationships
72
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
    components

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

74
(No Transcript)
75
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
    cube
  • Use the naming convention used in sequence
    diagrams instance name instance type
    (e.g., "w3reporting.myco.com Application
    Server")

76
Example
Instance name instance type
Nodes
Component packages
Dependency
77
Example
  • 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 w3reporting.myco.com
  • The diagram shows the Reporting Tool component
    drawn inside of IBM WebSphere, which in turn is
    drawn inside of the node w3.reporting.myco.com

78
Example
  • 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 db1.myco.com
    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

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

80
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

81
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

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

83
Second Iteration Plan due Tuesday November 21st
  • There are four main goals for this second
    iteration 
  • 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.

84
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

85
Code Inspection
  • For each pair in your team, select a different
    non-trivial "unit" of your code than for unit
    testing
  • 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
    style!
  • 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

86
Security and Robustness
  • Develop an "attack plan" to try to BREAK your
    system
  • 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
    hangs)
  • Tests should generally operate at the system
    level, but not necessarily through the user
    interface
  • 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

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

88
COMS W4156 Advanced Software Engineering
  • Prof. Gail Kaiser
  • Kaiser4156_at_cs.columbia.edu
  • http//york.cs.columbia.edu/classes/cs4156/
Write a Comment
User Comments (0)
About PowerShow.com