01 november 2007kaiser: coms w4156 fall 20071 coms w4156: advanced software engineering prof. gail...

01 November 2007 Kaiser: COMS W4156 Fall 2007 1

COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]

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

mailto:[email protected]



Reprise: 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 (blueprints)• Helps project teams communicate, explore

potential designs, and validate the requirements and architectural design of the software system


Our Focus: the LanguageUnified 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)

• Simple building blocks are used to create large, complex structures

Building Blocks


Types of UML Diagrams

• 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– Interaction– State– Structural– Implementation


Structural Modeling

• Define the architecture

• Used to model the “things” that make up the system

• Model class structure and contents

• Emphasizes the structure of objects, including their classifiers, attributes, operations, and relationships including dependencies


Structural Diagrams

• Show a graph of elements connected by relationships

• Kinds– Class diagram: classifier view– Object diagram: instance view

• Shows the static structures of the system (not dynamic or temporal)


Class Diagrams

• Shows how the different entities (people, things and data) relate to each other

• A class diagram can be used to display logical classes, not necessarily code 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, interest rates

• Use domain vocabulary


Class Diagram Example


Class Notation

• A class is depicted on the class diagram as a rectangle with three horizontal sections (compartments)

• The upper section shows the class's name• The middle section contains the class's

structure or attributes, optionally with initial values

• The lower section contains the class's operations or behaviors (or "methods")

• May be abbreviated to show just name, or just name and attributes


Class Example


Class Diagram • Draw a generalization relationship using a line

with an arrowhead at the top pointing to the super class, where the arrowhead should a completed triangle

• Associations– A solid line if both classes are aware of each other– 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, i.e., direction of potential navigation)

– Optionally label with multiplicity


Example Class Diagram

Generalization

One-wayassociation

Two-wayassociation


Association Example


Generalization Example


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}


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


Implementation 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

• May add compartments such as responsibilities and exceptions, even gist of method body

• May indicate attribute and operation visibility: public, private, protected, package


Example Implementation Class

bill no-shows

Reservation

operations

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

responsibilities

match to available rooms

exceptions

invalid credit card


Example Class Detail

Window

display ()

size: Areavisibility: Boolean

hide ()

Window

Window

+default-size: Rectangle#maximum-size: Rectangle

+create ()

+display ()

+size: Area = (100,100)#visibility: Boolean = true

+hide ()

-xptr: XWindow*

-attachXWindow(xwin:Xwindow*)

{abstract,author=Joe,status=tested}

+ = public- = private# = protected~ = package visibility


Method Body Example

report ()

BurglarAlarm

isTripped: Boolean = false

PoliceStation

1 station

*

{ if isTrippedthen station.alert(self)}

alert (Alarm)


Generalization

• Often represents inheritance at implementation class level

• Abstract class names given in italics

• Possibly multiple inheritance

• Possibly multiple inheritance hierarchies emanating from same base class

• Separate vs. shared target formats


Generalization Example Equivalent Forms


Generalization ExampleShape

SplineEllipsePolygon

Shape

SplineEllipsePolygon

Shared Target Style

Separate Target Style

. . .

. . .


Multiple Level Generalization ExampleVehicle

WindPoweredVehicle

MotorPoweredVehicle

LandVehicle

WaterVehicle

venue

venuepowerpower

SailboatTruck

{overlapping} {overlapping}


Associations

• Reflect connections, usually implemented as an instance variable in one class

• Connector may include named roles at each end, cardinality, direction and constraints

• Self-associations permitted• May indicate choice (xor)• May be N-ary (not just binary)• Association classes allow an association

connection to have operations and attributes


Association Example


Association Examples

Person

Manages

JobCompany

boss

worker

employeeemployer

0..1

Job

Account

Person

Corporation

{Xor}

salary


Association Class Example


PlayerTeam

Year

Record

goals forgoals againstwinslosses

goalkeeper

season

team

ties

Ternary Association Class Example


Aggregations • Aggregations are a stronger form of association

between a whole and its parts• Drawn with a diamond next to the class

representing the target or whole (parent)• open vs. closed diamond indicates usage vs.

containment semantics• Containment may be indicated by composition

rather than relationship lines


Aggregation Example


Aggregation Example

Polygon PointContains

{ordered}

3..1

GraphicsBundle

colortexturedensity

1

1

-bundle

+vertex


Composition ExampleWindow

scrollbar [2]: Slidertitle: Headerbody: Panel

Window

scrollbar title body

Header Panel

2 1 1

Slider

111

scrollbar:Slider

Window

2

title:Header1

body:Panel1


Dependencies • Dependencies are a weaker form of association without

semantic knowledge• Often used early in the design process where it is known

that there is some kind of link between two elements, but it is too early to know exactly what the relationship is

• Later in the design process, dependencies may be replaced with a more specific type of connector

• Shown with a dashed line (e.g., from client to supplier)• <<label>> on line specifies kind (stereotype) of

dependency, e.g., <<instantiate>>, <<import>>, etc.


Dependencies Example

«friend»ClassA ClassB

ClassC

«instantiate»

«call»

ClassD

operationZ()«friend»

ClassD ClassE

«refine»ClassC combines

two logical classes


Dependencies Example

Controller

DiagramElements

DomainElements

GraphicsCore

«access»

«access»

«access»

«access»

«access»


Interfaces• All interface operations are public and abstract, and all

interface attributes must be constants• By realizing an interface, classes are guaranteed to

support a required behavior, which allows the system to treat non-related elements in the same way – that is, through the common interface

• While a class may only inherit from a single super-class, it may implement multiple interfaces

• May be drawn in a similar style to a class, with operations specified

• Or may be drawn as a circle with no explicit operations detailed (when drawn as a circle, realization links to the circle form of notation are drawn without target arrows)


Interface Example


Interface Realization Example


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

Interface Example


Types and Implementation Classes Example

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)


Object Diagrams

• Refer to a specific instance• Special case of a class diagram• Does not show operations but may show

runtime state• Object names are underlined and may

show the name of the classifier from which the object is instantiated

• May compose multiple specific instances• May be drawn as glyphs


Class vs. Object Diagram Example


Run-time State Example


More Object Examples

triangle: Polygon

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

triangle: Polygon

triangle

:Polygon

scheduler


Composite Objects Example

horizontalBar:ScrollBar

verticalBar:ScrollBar

awindow : Window

surface:Pane

title:TitleBar

moves

moves


When to Model Structure• Adopt an opportunistic top-down

interleaved with bottom-up approach to modeling structure– Specify the top-level structure using

“architecturally significant” classifiers and model management constructs (subsystems)

– Specify lower-level structure as you discover detail wrt classifiers and relationships


Implementation Diagrams

• Additional structural modeling (beyond classes, interfaces and objects)

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

• Kinds– Package diagram– Component diagram– Deployment diagram


Package Diagrams

• Used to reflect the organization of packages and their elements

• Provide a visualization of the namespaces• Elements contained in a package share the

same namespace, therefore must have unique names

• Drawn as folders, with tabs at the top; the package name is on the tab or inside the rectangle

• Dotted arrows show dependencies - one package depends on another if changes in the other could possibly force changes in the first


Package Diagrams

• Packages may be imported or nested• A <<merge>> connector between two

packages defines an implicit generalization between elements in the source package and elements with the same name in the target package

• The target package need not contain elements with same names as all source package elements


Package Diagram Example

nestedpackage


Component Diagrams• Describes the software components that make

up the system• 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

• A component is illustrated as a large rectangle with two smaller rectangles on the side, lollipops represent interfaces

• Dashed lines with arrows between components indicate dependencies


Component Examples

<<Entity>>030303zak:Order

OrderHome

Order

OrderPK

<<Session>>ShoppingSession

ShoppingSessionHome

ShoppingSession

OrderInfo

<<focus>>:Order

<<auxiliary>>:OrderPK

<<auxiliary>>:OrderInfo

OrderHome

Order


Component Diagram Example

<<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 Example with Labeled Dependencies


Deployment Diagram

• Visualizes the physical architecture and the deployment of components on that hardware architecture

• Shows how a system will be physically deployed in the hardware environment, distribution of components across the enterprise

• Its purpose is to show where the different components of the system will physically run and how they will communicate with each other


Deployment Diagram Notation• Includes the notation elements used in a

component diagram, plus adds 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 (or box) with the name of the node at the top of the cube

• Use the naming convention [instance name] : [instance type] (e.g., "w3reporting.myco.com : Application Server")


Deployment Diagram Example


• 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 for the

structural elements that supply the behavior (sequence, state, activity diagrams) and implement the use cases (use case diagrams)

• Implementation diagrams extend structural modeling to source code and run-time structure

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

• http://www-306.ibm.com/software/rational/uml/ - IBM’s UML resource center (IBM bought Rational in 2002)

Resources

http://www.uml.org/

http://argouml.tigris.org/

http://uml.sourceforge.net/index.php

http://www-306.ibm.com/software/rational/uml/


First Iteration DemosDue!

• October 30th – November 8th • Extra credit on per-day-early sliding scale• Only team members present for the demo

(for CVN virtually present) will receive credit – 10% of final grade

• No “presentation” needed, but be prepared to answer questions, show your code, and let the TA enter input to your system


Upcoming Deadlines

• First iteration final report due Friday November 9th, must respond to any “issues” that arose during demo

• Midterm Individual Assessment posted Friday November 9th

• Midterm Individual Assessment due Friday November 16th

• 2nd iteration starts

http://york.cs.columbia.edu/classes/cs4156/homeworks/firstreport.htm


Second Iteration

• Add extensive error checking and exception handling

• Black box unit testing and white box statement coverage

• Semi-formal code inspection• Security and stress testing• Seeking volunteer teams to do code inspections

(Tue 27 Nov and Thu 29 Nov) and final demos (Tue 4 Dec and Thu 6 Dec) in class


COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]


mailto:[email protected]


01 november 2007kaiser: coms w4156 fall 20071 coms w4156: advanced software engineering prof. gail...

Documents

coms w4156

gail kaiser kaiser

blocks slide

software system slide

educlassescs4156 slide

temporal slide

class diagram example

class example