02 November 2006 Kaiser: COMS W4156 Fall 2006 1
COMS W4156: Advanced Software Engineering
Prof. Gail Kaiser
http://york.cs.columbia.edu/classes/cs4156/
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 4
Unified Modeling Language
• Provide structure for problem solving
• Furnish abstractions to manage complexity
• Experiment to explore multiple solutions
Why do we model?
Why do we model graphically?• Graphics reveal content, structure, …
• 1 bitmap = 1 megaword
02 November 2006 Kaiser: COMS W4156 Fall 2006 5
The Challenge
02 November 2006 Kaiser: COMS W4156 Fall 2006 6
The Vision
02 November 2006 Kaiser: COMS W4156 Fall 2006 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 other’s techniques
02 November 2006 Kaiser: COMS W4156 Fall 2006 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 Jacobson’s 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 12
Example
Actors
Actor
Use Cases
Relationships
Relationship
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 16
Core ElementsConstruct Description Syntax
use case A sequence of actions that a system (or other entity) can perform, including variants, interacting with actors of the system.
actor A coherent set of roles that users of use cases play when interacting with these use cases.
system boundary
Represents the boundary between the physical system and the actors who interact with the physical system.
UseCaseNam e
ActorNam e
02 November 2006 Kaiser: COMS W4156 Fall 2006 17
Construct Description Syntax
association The participation of an actor in a use case. i.e., instance of an actor and instances of a use case communicate with each other.
generalization A taxonomic relationship between a more general use case and a more specific use case.
extend A relationship from an extension use case to a base use case, specifying how the behavior for the extension use case can be inserted into the behavior defined for the base use case.
include An relationship from a base use case to an inclusion use case, specifying how the behavior for the inclusion use case is inserted into the behavior defined for the base use case.
Core Relationships
<<extend>>
02 November 2006 Kaiser: COMS W4156 Fall 2006 18
Customer
Supervisor
SalespersonPlace
Establishcredit
Check
Telephone Catalog
Fill orders
Shipping Clerk
status
order
Use Case Diagram
02 November 2006 Kaiser: COMS W4156 Fall 2006 19
Use Case Relationships
additional requests :
OrderProduct
SupplyArrange
«include»«include»«include»
RequestCatalog
«extend»Extension points
PaymentCustomer Data
after creation of the order
Place Order
1 * the salesperson asks forthe catalog
02 November 2006 Kaiser: COMS W4156 Fall 2006 20
Actor Relationships
EstablishCredit
PlaceOrder
Salesperson
Supervisor
1 *
1 *
02 November 2006 Kaiser: COMS W4156 Fall 2006 21
Example: Online HR System
Online HR System
LocateEm ployees
UpdateEm ployee
Profile
Update Benefits
Access TravelSystem
Access PayRecords
Em ployee
M anager
Healthcare P lan System
{if currentMonth = Oct.}
{readOnly}
Insurance P lan System
02 November 2006 Kaiser: COMS W4156 Fall 2006 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 employee’s area the employee is informed and asked to select another plan...
02 November 2006 Kaiser: COMS W4156 Fall 2006 23
Online HR System: Use Case Relationships
Update M edicalP lan
Update DentalP lan
Update Benefits______________Extension pointsbenefit options:
after required enrollm ents
UpdateInsurance P lan
Em ployee
<<include>> <<include>> <<include>>
ElectReim bursem entfor Healthcare
Elect StockPurchase
<<extend>>em ployee requestsstock purchase option
<<extend>>em ployee requestsreim bursem ent option
extensioncondition
extension pointname andlocation
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 25
Example
02 November 2006 Kaiser: COMS W4156 Fall 2006 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")
02 November 2006 Kaiser: COMS W4156 Fall 2006 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)
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
One-wayassociation
Two-wayassociation
02 November 2006 Kaiser: COMS W4156 Fall 2006 29
Class Diagrams
02 November 2006 Kaiser: COMS W4156 Fall 2006 30
Construct Description Syntax
class a description of a set of objects that share the same attributes, operations, methods, relationships and semantics.
interface a named set of operations that characterize the behavior of an element.
component a modular, replaceable and significant part of a system that packages implementation and exposes a set of interfaces.
node a run-time physical object that represents a computational resource.
constraint a semantic condition or restriction.
«in terface»
Core Elements
{constra in t}
02 November 2006 Kaiser: COMS W4156 Fall 2006 31
Construct Description Syntax
association a relationship between two or more classifiers that involves connections among their instances.
aggregation A special form of association that specifies a whole-part relationship between the aggregate (whole) and the component part.
generalization a taxonomic relationship between a more general and a more specific element.
dependency a relationship between two modeling elements, in which a change to one modeling element (the independent element) will affect the other modeling element (the dependent element).
realization a relationship between a specification and its implementation.
Core Relationships
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 33
Classes: compartments with names
bill no-shows
Reservation
operations
guarantee()cancel ()change (newDate: Date)
responsibilities
match to available rooms
exceptions
invalid credit card
02 November 2006 Kaiser: COMS W4156 Fall 2006 34
Classes: method body
report ()
BurglarAlarm
isTripped: Boolean = false
PoliceStation
1 station
*
{ if isTrippedthen station.alert(self)}
alert (Alarm)
02 November 2006 Kaiser: COMS W4156 Fall 2006 35
Types and Implementation Classes
Set«type»
addElement(Object)removeElement(Object)testElement(Object):Boolean
* elements
Object«type»
HashTableSet«implementationClass»
addElement(Object)removeElement(Object)testElement(Object):Boolean
1 body
HashTable«implementationClass»
setTableSize(Integer)
02 November 2006 Kaiser: COMS W4156 Fall 2006 36
Interfaces: Shorthand Notation
+create()+login(UserName, Passwd)+find(StoreId)+getPOStotals(POSid)+updateStoreTotals(Id,Sales)+get(Item)
-storeId: Integer-POSlist: List
Store
POSterminal
POSterminalHome
<<use>>
StoreHome
Store
POSterminal
02 November 2006 Kaiser: COMS W4156 Fall 2006 37
Associations
Person
Manages
JobCompany
boss
worker
employeeemployer
0..1
Job
Account
Person
Corporation
{Xor}
salary
02 November 2006 Kaiser: COMS W4156 Fall 2006 38
Association Ends
Polygon PointContains
{ordered}
3..1
GraphicsBundle
colortexturedensity
1
1
-bundle
+vertex
02 November 2006 Kaiser: COMS W4156 Fall 2006 39
PlayerTeam
Year
Record
goals forgoals againstwinslosses
goalkeeper
season
team
ties
Ternary Associations
02 November 2006 Kaiser: COMS W4156 Fall 2006 40
CompositionWindow
scrollbar [2]: Slidertitle: Headerbody: Panel
Window
scrollbar title body
Header Panel
2 1 1
Slider
111
scrollbar:Slider
Window
2
title:Header1
body:Panel1
02 November 2006 Kaiser: COMS W4156 Fall 2006 41
GeneralizationShape
SplineEllipsePolygon
Shape
SplineEllipsePolygon
Shared Target Style
Separate Target Style
. . .
. . .
02 November 2006 Kaiser: COMS W4156 Fall 2006 42
GeneralizationVehicle
WindPoweredVehicle
MotorPoweredVehicle
LandVehicle
WaterVehicle
venue
venuepowerpower
SailboatTruck
{overlapping} {overlapping}
02 November 2006 Kaiser: COMS W4156 Fall 2006 43
Dependencies
«friend»ClassA ClassB
ClassC
«instantiate»
«call»
ClassD
operationZ()«friend»
ClassD ClassE
«refine»ClassC combines
two logical classes
02 November 2006 Kaiser: COMS W4156 Fall 2006 44
Dependencies
Controller
DiagramElements
DomainElements
GraphicsCore
«access»
«access»
«access»
«access»
«access»
02 November 2006 Kaiser: COMS W4156 Fall 2006 45
Derived Attributes and Associations
Person
birthdate/age{age = currentDate - birthdate}
Company
Person
Department
WorksForDepartment
/WorksForCompany
{ Person.employer=Person.department.employer }
1
1
1employer
employerdepartment
02 November 2006 Kaiser: COMS W4156 Fall 2006 46
Objects
triangle: Polygon
center = (0,0)vertices = ( (0,0),(4 ,0) ,(4,3))borderC olor = blackfi llColor = white
triangle: Polygon
triangle
:Polygon
scheduler
02 November 2006 Kaiser: COMS W4156 Fall 2006 47
Composite Objects
horizontalBar:ScrollBar
verticalBar:ScrollBar
awindow : Window
surface:Pane
title:TitleBar
moves
moves
02 November 2006 Kaiser: COMS W4156 Fall 2006 48
Links
downhillSkiClub:Club Joe:Person
Jill:Person
Chris:Person
member
member
member
treasurer
officer
president
officer
02 November 2006 Kaiser: COMS W4156 Fall 2006 49
Constraints and Comments
Member-of
Chair-of
{subset}Person Co mm ittee
Perso n Com pany
boss
{Person.employer =Person.boss.employer}
employeremployee
0..1
0..1
1
Representsan incorporated entity.
02 November 2006 Kaiser: COMS W4156 Fall 2006 50
Adapted from Fig. 23 [EJB 2.0].
+getOrderStatus+setOrderStatus+getLineItems+setLineItems+getCreditApproved+setCreditApproved
...
OrderBean{abstract}
LineItem{abstract}
Product
1
*
1
*
<<interface>>EntityBean
CreditCard{abstract}
Customer
PMOrder
PMLineItem
PMCreditCard
*
1
*
buyer
order
order
item
item
commodity
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 52
Sequence Example
Sequence of m
essages/calls in time order
Sequence of m
essages/calls in time order
Object instances to which the messages are sent
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 54
Example
Identify the objects asIdentify the objects asclass instance name : class nameclass instance name : class name
Draw a line for each Draw a line for each message, with an message, with an arrowhead pointing arrowhead pointing to the receiving class to the receiving class instance instance
Draw a dotted line Draw a dotted line for each return for each return value, with an value, with an arrowhead arrowhead pointing back to pointing back to the originating the originating class instanceclass instance
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 58
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 64
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 66
Example• 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
Swimlanes
Activity = rounded rectangle
Transitionlines
Terminationpoint
02 November 2006 Kaiser: COMS W4156 Fall 2006 67
Implementation Diagrams
• Show aspects of model implementation, including source code structure and run-time implementation structure
• Kinds– Component diagram– Deployment diagram
02 November 2006 Kaiser: COMS W4156 Fall 2006 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)
02 November 2006 Kaiser: COMS W4156 Fall 2006 69
Components
<<Entity>>030303zak:Order
OrderHome
Order
OrderPK
<<Session>>ShoppingSession
ShoppingSessionHome
ShoppingSession
OrderInfo
<<focus>>:Order
<<auxiliary>>:OrderPK
<<auxiliary>>:OrderInfo
OrderHome
Order
02 November 2006 Kaiser: COMS W4156 Fall 2006 70
Component Diagram
<<EJBEntity>>Catalog
CatalogHome
Catalog
CatalogPK
<<EJBSession>>ShoppingSession
ShoppingSessionHome
ShoppingSession
CatalogInfo
<<file>>CatalogJAR
<<focus>>Catalog
<<auxiliary>>CatalogPK
<<auxiliary>>CatalogInfo
CatalogHome
Catalog
<<EJBEntity>>ShoppingCart
ShoppingCartHome
ShoppingCart
02 November 2006 Kaiser: COMS W4156 Fall 2006 71
Component Diagram with Relationships
<<ejbEntity>>Catalog
<<auxiliary>>CatalogInfo
<<focus>>Catalog
<<reside>> <<reside>>
<<auxiliary>>CatalogPK
<<reside>>
<<file>>CatalogJAR
<<implement>>
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 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.
02 November 2006 Kaiser: COMS W4156 Fall 2006 74
02 November 2006 Kaiser: COMS W4156 Fall 2006 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")
02 November 2006 Kaiser: COMS W4156 Fall 2006 76
Example
Componentpackages
Nodes
Instance name: instance type
Dependency
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 79
• 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-independent 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
Summary
02 November 2006 Kaiser: COMS W4156 Fall 2006 80
• 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
Resources
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 82
Upcoming
• First demo week November 8-14
• First iteration final report due November 14th
• Second iteration plan due November 21st
02 November 2006 Kaiser: COMS W4156 Fall 2006 83
Second Iteration Plan due Tuesday November 21st
• There are four main goals for this second iteration:
1. Complete your application if not already completed by the end of the first iteration. (Enhancements optional.)
2. Conduct semi-formal unit testing.
3. Participate in a semi-formal code inspection.
4. Investigate the security and robustness properties of your small systems.
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 87
Deliverables1. 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
02 November 2006 Kaiser: COMS W4156 Fall 2006 88
COMS W4156: Advanced Software Engineering
Prof. Gail Kaiser
http://york.cs.columbia.edu/classes/cs4156/