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/