02 november 2006kaiser: coms w4156 fall 20061 coms w4156: advanced software engineering prof. gail...

02 November 2006 Kaiser: COMS W4156 Fall 2006 1

COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]

http://york.cs.columbia.edu/classes/cs4156/

mailto:[email protected]



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 components• Integrate best practices


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


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 other’s techniques


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


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


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


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


Example

Actors

Actor

Use Cases

Relationships

Relationship


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


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


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


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


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


Customer

Supervisor

SalespersonPlace

Establishcredit

Check

Telephone Catalog

Fill orders

Shipping Clerk

status

order

Use Case Diagram


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


Actor Relationships

EstablishCredit

PlaceOrder

Salesperson

Supervisor

1 *

1 *


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


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


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


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


Example


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


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)


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


Class Diagrams



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}



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


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

bill no-shows

Reservation

operations

guarantee()cancel ()change (newDate: Date)

responsibilities

match to available rooms

exceptions

invalid credit card


Classes: method body

report ()

BurglarAlarm

isTripped: Boolean = false

PoliceStation

1 station

*

{ if isTrippedthen station.alert(self)}

alert (Alarm)


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)


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


Associations

Person

Manages

JobCompany

boss

worker

employeeemployer

0..1

Job

Account

Person

Corporation

{Xor}

salary


Association Ends

Polygon PointContains

{ordered}

3..1

GraphicsBundle

colortexturedensity

1

1

-bundle

+vertex


PlayerTeam

Year

Record

goals forgoals againstwinslosses

goalkeeper

season

team

ties

Ternary Associations


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


GeneralizationShape

SplineEllipsePolygon

Shape

SplineEllipsePolygon

Shared Target Style

Separate Target Style

. . .

. . .


GeneralizationVehicle

WindPoweredVehicle

MotorPoweredVehicle

LandVehicle

WaterVehicle

venue

venuepowerpower

SailboatTruck

{overlapping} {overlapping}


Dependencies

«friend»ClassA ClassB

ClassC

«instantiate»

«call»

ClassD

operationZ()«friend»

ClassD ClassE

«refine»ClassC combines

two logical classes


Dependencies

Controller

DiagramElements

DomainElements

GraphicsCore

«access»

«access»

«access»

«access»

«access»


Derived Attributes and Associations

Person

birthdate/age{age = currentDate - birthdate}

Company

Person

Department

WorksForDepartment

/WorksForCompany

{ Person.employer=Person.department.employer }

1

1

1employer

employerdepartment


Objects

triangle: Polygon

center = (0,0)vertices = ( (0,0),(4 ,0) ,(4,3))borderC olor = blackfi llColor = white

triangle: Polygon

triangle

:Polygon

scheduler


Composite Objects

horizontalBar:ScrollBar

verticalBar:ScrollBar

awindow : Window

surface:Pane

title:TitleBar

moves

moves


Links

downhillSkiClub:Club Joe:Person

Jill:Person

Chris:Person

member

member

member

treasurer

officer

president

officer


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.


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


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

Sequence of m

essages/calls in time order

Sequence of m

essages/calls in time order

Object instances to which the messages are sent


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


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


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 diagram

• Only classes with "interesting" states — e.g., classes with three or more potential states during system activity — should be modeled


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


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


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


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


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


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


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


Implementation Diagrams

• Show aspects of model implementation, including source code structure and run-time implementation structure

• 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

classes)– Implemented by artifacts (e.g., binary,

executable, or script files)


Components

<<Entity>>030303zak:Order

OrderHome

Order

OrderPK

<<Session>>ShoppingSession

ShoppingSessionHome

ShoppingSession

OrderInfo

<<focus>>:Order

<<auxiliary>>:OrderPK

<<auxiliary>>:OrderInfo

OrderHome

Order


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


Component Diagram with Relationships

<<ejbEntity>>Catalog

<<auxiliary>>CatalogInfo

<<focus>>Catalog

<<reside>> <<reside>>

<<auxiliary>>CatalogPK

<<reside>>

<<file>>CatalogJAR

<<implement>>


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


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.


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


Example

Componentpackages

Nodes

Instance name: instance type

Dependency


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


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


• 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


• 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


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


Upcoming

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


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


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


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


COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]


mailto:[email protected]


02 november 2006kaiser: coms w4156 fall 20061 coms w4156: advanced software engineering prof. gail...

Documents