Module 2:

Introduction to UML

Lawrence Chung CS6358.OT1: Module 2 1

References

 Documentation on UML is available from:

 http://www.rational.com
 Rational Rose is available from:
 http://www.rational.com
 Visual Modeling with Rational Rose and UML,
Terry Quatrani, 1998.

Lawrence Chung CS6358.OT1: Module 2 2

Overview

 Background
 What is UML for?
 Building blocks of UML
 Process for Using UML

Lawrence Chung CS6358.OT1: Module 2 3

Unified Modeling Language (UML)
 An effort by Rational to standardize OOA&D notation
 UML attempts to combine the best of the best from
 Data Modeling concepts (Entity Relationship Diagrams)
 Business Modeling (work flow)
 Object Modeling
 Component Modeling

 “a graphical language for visualizing, specifying, constructing, and

documenting the artifacts of a software intensive system” [Booch]

 Offers vocabulary and rules for communication

 Focus on conceptual and physical representations of a system
 Not a process but a language

Lawrence Chung CS6358.OT1: Module 2 4

UML History
 OO languages appear mid 70’s to late 80’s
 Between ’89 and ’94, OO methods increased from 10 to 50.
 Unification of ideas began in mid 90’s.
 Rumbaugh joins Booch at Rational ’94
 v0.8 draft Unified Method ’95
 Jacobson joins Rational ’95
 UML v0.9 in June ’96
 UML 1.0 offered to OMG in January ’97
 UML 1.1 offered to OMG in July ’97
 Maintenance through OMG RTF
 UML 1.2 in June ’98
 UML 1.3 in fall ’99

 Rational now has

 Grady Booch - Fusion
 James Rumbaugh – Object Modeling Technique (OMT)
 Ivar Jacobson – Object-oriented Software Engineering: A Use Case Approach (Objectory)
 ( And David Harel - StateChart)

Lawrence Chung CS6358.OT1: Module 2 5

UML is for Visual Modeling
A picture is worth a thousand words!

- Uses standard graphical notations

- Semi-formal
- Captures Business Process from enterprise information systems to distributed Web-based
applications and even to hard real time embedded systems

Sales Places Order

Representative Customer

Fulfill Order

Item

via
Ships the Item

Business Process

Lawrence Chung CS6358.OT1: Module 2 6

 UML is also for …
Specifying
 building models that are: Precise, Unambiguous, Complete
 UML symbols are based on well-defined syntax and semantics.
 UML addresses the specification of all important analysis, design, and
implementation decisions.

Constructing
 Models are related to OO programming languages.
 Round-trip engineering requires tool and human intervention to avoid information loss
 Forward engineering — direct mapping of a UML model into code.
 Reverse engineering — reconstruction of a UML model from an implementation.

Documenting
 Architecture, Requirements, Tests, Activities (Project planning, Release management)

Lawrence Chung CS6358.OT1: Module 2 7

 Architecture & Views (You can skip this part on the first reading)
UML is for visualizing, specifying, constructing, and documenting with emphasis on system architectures (things in the
system and relationships among the things) from five different views

Architecture - set of significant decisions regarding:

 Organization of a software system.
 Selection of structural elements & interfaces from which a system is composed.
 Behavior or collaboration of elements.
 Composition of structural and behavioral elements.
 Architectural style guiding the system.

vocabulary system assembly

functionality Design View Implementation Viewconfiguration mgmt.

behavior
Use Case View
system topology
performance distribution
scalability Process View Deployment View delivery
throughput installation

Lawrence Chung CS6358.OT1: Module 2 8

Views
Use Case View
 Use Case Analysis is a technique to capture business process from user’s perspective.
 Encompasses the behavior as seen by users, analysts and testers.
 Specifies forces that shape the architecture.
 Static aspects captured in use case diagrams.
 Dynamic aspects captured in interaction diagrams, statechart diagrams, and activity
diagrams.

Design View
 Encompasses classes, interfaces, and collaborations that define the vocabulary of a
system.
 Supports functional requirements of the system.
 Static aspects captured in class diagrams and object diagrams.
 Dynamic aspects captured in interaction, statechart, and activity diagrams.

Lawrence Chung CS6358.OT1: Module 2 9

Views
Process View
 Encompasses the threads and processes defining concurrency and synchronization.
 Addresses performance, scalability, and throughput.
 Static and dynamic aspects captured as in design view; emphasis on active classes.

Implementation View
 Encompasses components and files used to assemble and release a physical system.
 Addresses configuration management.
 Static aspects captured in component diagrams.
 Dynamic aspects captured in interaction, statechart, & activity diagrams.

Deployment View
 Encompasses the nodes that form the system hardware topology.
 Addresses distribution, delivery, and installation.
 Static aspects captured in deployment diagrams.
 Dynamic aspects captured in interaction, statechart, & activity diagrams.

Lawrence Chung CS6358.OT1: Module 2 10

Three (3) basic building blocks of UML

 Things
important modeling concepts (individual ones as the primitive
kinds)
 Relationships
tying individual things (i.e., their concepts)
 Diagrams
grouping interrelated collections of things and relationships

Lawrence Chung CS6358.OT1: Module 2 11

3 basic building blocks of UML - Things

 Structural — nouns of UML models.

 Behavioral — dynamic (verbal) parts of UML
models.
 Grouping — organizational parts of UML models.
 Annotational — explanatory parts of UML models.

Lawrence Chung CS6358.OT1: Module 2 12

Structural Things in UML- 7 Kinds
Nouns of UML models.
Conceptual or physical elements.

Active Class

Class Collaboration Event Mgr

Window thread
origin time Node
size Chain of suspend( )
open( ) Responsibility flush( )
close( ) stop( ) WebServer
move( )
Place
Order
listbox
IWindow Use Case
Interface Component

Lawrence Chung CS6358.OT1: Module 2 13

Structural Things in UML
name Window
1. Class origin
A description of a set of objects that share the same attributes size
attributes, operations, relationships, and semantics. open()
Usually implements one or more interfaces. operations close()
Cf. Active Class

2. Interface
A collection of operations that specify a service (for a
resource or an action) of a class or component. It describes
the externally visible behavior of that element.
<<interface>>
IWindow name IWindow

operations open()
close()

Lawrence Chung CS6358.OT1: Module 2 14

Structural Things in UML

3. Collaboration
Define an interaction among a web of objects. Chain of
Define a society of roles and other elements. Responsibility
Provide cooperative behavior.
Capture structural and behavioral dimensions.

4. Use Case
A sequence of actions that produce an observable
result for a specific actor. Place Order
Provides a structure for behavioral things.
Realized through a collaboration (usually realized by
a set of actors and the system to be built).

Lawrence Chung CS6358.OT1: Module 2 15

 Structural Things in UML
5. Active Class Event
name Manager
Special class whose objects own one or
attributes Thread
more processes or threads. Heavy border
time
Can initiate control activity. operations suspend()
flush()
6. Component
Replaceable part of a system.
Components can be packaged logically. Orderform.java
Conforms to a set of interfaces.
Provides the realization of an interface.

7. Node
Element that exists at run time.
Represents a computational resource. WebServer
Generally has memory and processing power.

Variations on Structural Things: Actors, Signals, Utilities, Processes & Threads, Applications, Documents, etc.

Lawrence Chung CS6358.OT1: Module 2 16

Behavioral Things in UML
Verbs of UML models.
Dynamic parts of UML models: “behavior over time and space”
Usually connected to structural things in UML.

Two primary kinds of behavioral things:

Interaction
behavior of a set of objects comprising of a set of message exchanges within a
particular context to accomplish a specific purpose.
display
State Machine
behavior that specifies the sequences of states an object or an
interaction goes through during its lifetime in response to events,
together with its responses to those events.

Idle Waiting

Lawrence Chung CS6358.OT1: Module 2 17

Grouping Things in UML
Packages - one primary kind of grouping.
- General purpose mechanism for organizing elements into groups.
- Purely conceptual; only exists at development time.
- Contains behavioral and structural things.
- Can be nested.
- Variations of packages are: Frameworks, models, & subsystems.

Meeting Scheduler

Lawrence Chung CS6358.OT1: Module 2 18

Annotational Things in UML

Explanatory parts of UML models

Comments regarding other UML elements (usually called adornments in
UML)

Note is one primary annotational thing in UML

best expressed in informal or formal text.

flexible
drop-out dates

Lawrence Chung CS6358.OT1: Module 2 19

3 basic building blocks of UML - Relationships

4 Kinds

 Dependency
 Association
 Generalization
 Realization

Lawrence Chung CS6358.OT1: Module 2 20

 Relationships in UML
1. Dependency
a semantic relationship between two things in which a change to one thing
(independent) may affect the semantics of the other thing (dependent).

Directed is optional and label is optional .

2. Associations
a structural relationship that describes a set of links, a link being a connection between
objects.
employer employee
0..1
*
Can be directed labels Can have multiplicity & role names
Aggregation
a special kind of association. It represents a
structural
relationship between the wholeRepresented
and its parts.by a black diamond.

Lawrence Chung CS6358.OT1: Module 2 21

Relationships in UML

3. Generalization
a specialization/generalization relationship in which objects of the specialized element
(the child) are more specific than the objects of the generalized element.

4. Realization
a semantic relationship between two elements, wherein one element guarantees to carry
out what is expected by the other element.

Where?
Between interfaces and classes that realize them…
Between use cases and the collaborations that realize them...

Lawrence Chung CS6358.OT1: Module 2 22

3 basic building blocks of UML - Diagrams
Graphical representation of a set of elements.
Represented by a connected graph: Vertices are things; Arcs are
behaviors.
5 most common views built from 9 diagram types.
Class Diagram; Object Diagram

Use case Diagram

Sequence Diagram; Collaboration Diagram

Statechart Diagram

Activity Diagram

Component Diagram

Deployment Diagram

Lawrence Chung CS6358.OT1: Module 2 23

 Diagrams in UML
– University Registration System as a Running Example

The UTD wants to computerize its registration system

 The Registrar sets up the curriculum for a semester
 One course may have multiple course offerings
 Students select four (4) primary courses and two (2) alternate courses
 Once a student registers for a semester, the billing system is notified so the
student may be billed for the semester
 Students may use the system to add/drop courses for a period of time after
registration
 Professors use the system to set their preferred course offerings and receive
their course offering rosters after students register
 Users of the registration system are assigned passwords which are used at
logon validation

Lawrence Chung CS6358.OT1: Module 2 24

Diagrams in UML – Actors in Use Case Diagram
 An actor is someone or some thing that must interact with the
system under development

Professor
Registrar

Student
Billing System

Lawrence Chung CS6358.OT1: Module 2 25

Diagrams in UML - Use Cases in Use Case Diagram
 A use case is a pattern of behavior the system exhibits
– Each use case is a sequence of related transactions performed by an
actor and the system in a dialogue
 Actors are examined to determine their needs
– Registrar -- maintain the curriculum
– Professor – set course offerings and request roster
– Student -- maintain schedule
– Billing System -- receive billing information from registration

Maintain Curriculum Request Course Roster Maintain Schedule

Lawrence Chung CS6358.OT1: Module 2 26

Diagrams in UML - Documenting Use Cases in Use Case Diagram

 A flow of events is described in documents for each use case

 Written from an actor point of view
 Details what the system must provide to the actor when the use case
is executed
 Typical contents
 How the use case starts and ends
 Normal flow of events
 Alternate flow of events
 Exceptional flow of events

Lawrence Chung CS6358.OT1: Module 2 27

Diagrams in UML
– Flow of Events for Maintaining Curriculum and Setting Course Offerings
(Maintaining Curriculum and Setting Course Offerings are two of the activities in running university registration system)

Flow of Events for Maintaining Curriculum

 This use case begins when the Registrar logs onto the Registration System and enters
his/her password.
 The system verifies that the password is valid and prompts the Registrar to select the
current semester or a future semester.
 The Registrar enters the desired semester.

Flow of Events for Setting Course Offerings

 The system prompts the professor to select the desired activity: ADD, DELETE,
REVIEW, or QUIT.
 If the activity selected is ADD: Add a Course subflow is performed.
 If the activity selected is DELETE: Delete a Course subflow is performed.
 If the activity selected is REVIEW: Review Curriculum subflow is performed.
 If the activity selected is QUIT, the use case ends.

Lawrence Chung CS6358.OT1: Module 2 28

Diagrams in UML - Use Case Diagram
 Use case diagrams are created to visualize the
relationships between actors and use cases

Request Course Roster

Professor

Student
Set Course Offerings
Maintain Schedule

Billing System Maintain Curriculum

Registrar

Lawrence Chung CS6358.OT1: Module 2 29

Diagrams in UML
- Uses and Extends Use Case Relationships in Use Case Diagram

A uses relationship shows behavior common to one or more use cases

An extends relationship shows optional behavior

<<uses>>
<<extends>>
Register for courses

<<uses>>
Register for Logon validation
Distance Learning courses

Maintain curriculum

Lawrence Chung CS6358.OT1: Module 2 30

Diagrams in UML - Use Case Realizations
A use case diagram presents an outside view of the system.

Then, how about the inside view of the system?

 Interaction diagrams describe how use cases are realized as

interactions among societies of objects, including the messages that
may be dispatched among them. They address the dynamic view of
the system.

 Two types of interaction diagrams

 Sequence diagrams
 Collaboration diagrams

Lawrence Chung CS6358.OT1: Module 2 31

Diagrams in UML - Sequence Diagram
 A sequence diagram displays object interactions arranged in a time
sequence

: Student registration registration math 101 math 101

form manager section 1

1: fill in info

2: submit

3: add course(Sue, math 01)

4: are you open?
5: are you open?
6: add (Sue)
7: add (Sue)

Lawrence Chung CS6358.OT1: Module 2 32

Diagrams in UML - Collaboration Diagram
 Displays object interactions organized around objects and their direct
links to one another.
 Emphasizes the structural organization of objects that send and
receive messages.

course form :
1: set course info CourseForm
2: process

: Registrar 3: add course

theManager :
aCourse :
CurriculumManager
Course
4: new course

Lawrence Chung CS6358.OT1: Module 2 33

Diagrams in UML - Class Diagrams

 A class diagram shows the existence of classes and their

relationships in the logical view of a system
 UML modeling elements in class diagrams
 Classes and their structure and behavior
 Association, aggregation, dependency, and inheritance relationships
 Multiplicity and navigation indicators
 Role names

Lawrence Chung CS6358.OT1: Module 2 34

Diagrams in UML - Classes
 A class is a collection of objects with common structure, common
behavior, common relationships and common semantics
 Some classes are shown through the objects in sequence and
collaboration diagram
 A class is drawn as a rectangle with three compartments
 Classes should be named using the vocabulary of the domain
 Naming standards should be created
 e.g., all classes are singular nouns starting with a capital letter

Lawrence Chung CS6358.OT1: Module 2 35

Diagrams in UML - Classes: Naming & 3 Sections

ScheduleAlgorithm
RegistrationForm

RegistrationManager

Course

Student

Professor
CourseOffering

Lawrence Chung CS6358.OT1: Module 2 36

Diagrams in UML – Classes: Operations & Attributes
Operations
• The behavior of a class is represented by its operations
• Operations may be found by examining interaction diagrams

registration registration RegistrationManager

form manager

3: add course(Sue, math 01) addCourse(Student,Course)

Attributes
• The structure of a class is represented by its attributes
• Attributes may be found by examining class definitions, the problem
requirements, and by applying domain knowledge
CourseOffering
Each course offering number
has a number, location and time location
time

Lawrence Chung CS6358.OT1: Module 2 37

Diagrams in UML – Some Classes with Operations & Attributes

ScheduleAlgorithm
RegistrationForm

RegistrationManager
addStudent(Course, StudentInfo)
Course
name
numberCredits
Student open()
name addStudent(StudentInfo)
major

Professor
name CourseOffering
tenureStatus location

open()
addStudent(StudentInfo)

Lawrence Chung CS6358.OT1: Module 2 38

Diagrams in UML – Object Diagrams
• Shows a set of objects and their relationships.
• A static snapshot of instances.

Harry
(Student)
Name: “Harry Mat”
Major: CS

Sue
(Professor)
Name: “Sue Becker”
tenureStatus: true

Lawrence Chung CS6358.OT1: Module 2 39

Diagrams in UML – Finding Relationships

• Relationships are discovered by examining interaction diagrams

– If two objects must “talk” there must be a pathway for communication

RegistrationManager
Registration Math 101:
Manager Course

3: add student(Sue)

Course

Lawrence Chung CS6358.OT1: Module 2 40

Diagrams in UML – Relationships: Multiplicity and Navigation

ScheduleAlgorithm
RegistrationForm

0..*
1 RegistrationManager
addStudent(Course, StudentInfo)
1 Course
name
0..* numberCredits
Student open()
addStudent(StudentInfo)
major

1
3..10
Professor 1..*
4 CourseOffering
tenureStatus location
1
0..4 open()
addStudent(StudentInfo)

Lawrence Chung CS6358.OT1: Module 2 41

Diagrams in UML – Inheritance
• Inheritance is a relationship between a superclass and its subclasses
• Common attributes, operations, and/or relationships are shown at the highest
applicable level in the hierarchy

ScheduleAlgorithm
RegistrationForm

RegistrationManager
addStudent(Course, StudentInfo)
Course
name
RegistrationUser numberCredits
name
Student open()
addStudent(StudentInfo)
major

Professor
CourseOffering
tenureStatus location

open()
addStudent(StudentInfo)

Lawrence Chung CS6358.OT1: Module 2 42

Diagrams in UML – State Transition Diagram
• The life history of a given class
• The events that cause a transition from one state to another
• The actions that result from a state change

Add student[ count < 10 ]

Add Student /
Initialization Set count = 0
Open
do: Initialize course
entry: Register student
exit: Increment count

Cancel

Cancel [ count = 10 ]

Canceled
do: Notify registered students
Closed
Cancel do: Finalize course

Lawrence Chung CS6358.OT1: Module 2 43

Diagrams in UML – Statechart Diagram
• shows a state machine, consisting of states, transitions,
events and activities

Add student[ Count < 10 ]

Add student / Set count = 0

Initialization Open

[ Count = 10 ] ^Course
Report.Create report
Cancel course

Cancelled Closed
Cancel course

Lawrence Chung CS6358.OT1: Module 2 44

Diagrams in UML – Activity Diagrams
• A special kind of statechart diagram that shows the flow from activity to activity.
Not directly supported in Rational Rose 98
Body Prepare for speech

Swimlanes
a mechanism to group and
organize activity states Decompress

Gesture Synch Mouth Stream Audio

Cleanup

Lawrence Chung CS6358.OT1: Module 2 45

Diagrams in UML – Activity Diagrams
How do we represent these if not supported by UML, or Rational Rose?

Place a state at each

Prepare for speech
synchronization bar!

Decompress

This is the result

(Can you figure this out?)
Gesture Synch Mouth Stream Audio Prepare for speech

Sync 1

Decompress
Gesture

Sync 2

Synchronization
Synch Mouth Stream Audio

sync3

Sync 4

Cleanup
Cleanup

Lawrence Chung CS6358.OT1: Module 2 46

Diagrams in UML – Component Diagram

• shows the organizations and dependencies among a set of

components.

Billing.exe Register.exe
Billing
System Registrar.exe

People.dll
User
Course.dll
Course
Courses.dll
People.dll
Student Professor
Course Course
Offering

Lawrence Chung CS6358.OT1: Module 2 47

Diagrams in UML – Deployment Diagram
• The deployment diagram shows the configuration of run-time
processing elements and the software processes living on them.
• The deployment diagram visualizes the distribution of components
across the enterprise.

Registration Database

Main
Library Building

Dorm

Lawrence Chung CS6358.OT1: Module 2 48

Extensibility of UML
• Stereotypes can be used to extend the UML notational elements
• Stereotypes may be used to classify and extend associations,
inheritance relationships, classes, and components
• Examples:
– Class stereotypes: boundary, control, entity, utility, exception
– Inheritance stereotypes: uses and extends
– Component stereotypes: subsystem

Stereotypes — extends vocabulary.

Tagged values — extends properties of UML building blocks.
Constraints — extend the semantics of UML building blocks.

Lawrence Chung CS6358.OT1: Module 2 49

Using UML Concepts in a Nutshell

 Display the boundary of a system & its major functions using use
cases and actors
 Illustrate use case realizations with interaction diagrams
 Represent a static structure of a system using class diagrams
 Model the behavior of objects with state transition diagrams
 Reveal the physical implementation architecture with component &
deployment diagrams
 Extend your functionality with stereotypes

Lawrence Chung CS6358.OT1: Module 2 50

Rules of UML
 Well formed models — semantically self-consistent and in harmony with all its
related models.
 Semantic rules for:
 Names — what you can call things.
 Scope — context that gives meaning to a name.
 Visibility — how names can be seen and used.
 Integrity — how things properly and consistently relate to one another.
 Execution — what it means to run or simulate a dynamic model.

 Avoid models that are

Elided — certain elements are hidden for simplicity.
Incomplete — certain elements may be missing.
Inconsistent — no guarantee of integrity.

Lawrence Chung CS6358.OT1: Module 2 51

Process for Using UML

How do we use UML as a notation to construct a good model?

 Use case driven — use cases are primary artifact for defining behavior
of the system.
 Architecture-centric — the system’s architecture is primary artifact for
conceptualizing, constructing, managing, and evolving the system.
 Iterative and incremental — managing streams of executable
releases with increasing parts of the architecture included.

The Rational Unified Process (RUP)

Lawrence Chung CS6358.OT1: Module 2 52

Process for Using UML - Iterative Life Cycle
• It is planned, managed and predictable …almost
• It accommodates changes to requirements with less disruption
• It is based on evolving executable prototypes, not documentation
• It involves the user/customer throughout the process
• It is risk driven

Primary phases
 Inception — seed idea is brought up to point of being a viable project.
 Elaboration — product vision and architecture are defined.
(http://www.utdallas.edu/~chung/OOAD_SUMMER04/HACS_vision_12.doc)
 Construction — brought from architectural baseline to point of deployment into
user community.
 Transition — turned over to the user community.

Lawrence Chung CS6358.OT1: Module 2 53

Process for Using UML - Iterative Approach
Three Important Features
• Continuous integration - Not done in one lump near the delivery date
• Frequent, executable releases - Some internal; some delivered
• Attack risks through demonstrable progress - Progress measured in products,
not documentation or engineering estimates

Resulting Benefits
• Releases are a forcing function that drives the development team to closure
at regular intervals - Cannot have the “90% done with 90% remaining” phenomenon
• Can incorporate problems/issues/changes into future iterations rather than
disrupting ongoing production
• The project’s supporting elements (testers, writers, toolsmiths, QA, etc.) can
better schedule their work

Lawrence Chung CS6358.OT1: Module 2 54

Process for Using UML - Risk Reduction Drives Iterations

Define scenarios to Plan Iteration N

address highest risks • Cost
Initial Project Risks • Schedule
Initial Project Scope

Develop Iteration N
• Collect cost and

Iteration N quality metrics

Assess Iteration N

Revise Overall
Project Plan
• Cost
• Schedule
• Scope/Content Risks Eliminated
Revise Project Risks
• Reprioritize

Lawrence Chung CS6358.OT1: Module 2 55

Process for Using UML - Use Cases Drive the Iteration Process

Inception Elaboration Construction Transition

Iteration 1 Iteration 2 Iteration 3

Each iteration is defined in terms

of the scenarios it implements
“Mini-Waterfall” Process
• Results of previous iterations
Selected scenarios • Up-to-date risk assessment
• Controlled libraries of models, code, and tests

Iteration Planning
Reqs Capture
Analysis & Design
Implementation
Test
Release description
Prepare Release
Updated risk assessment
Controlled libraries

Lawrence Chung CS6358.OT1: Module 2 56

Process for Using UML - But No Silver Bullet
• main reason for using the iterative life cycle:
– Not all the needed information up front
– Changes throughout the development period

• expect
– To face some persistent, recurring risks
– To discover new risks along the way
– To do some rework; to throw away some lines of code
– To change requirements along the way

Lawrence Chung CS6358.OT1: Module 2 57

Summary

 Background

 What is UML for?

for visualizing, specifying, constructing, and documenting models
 Building blocks of UML
Things, Relationships (4 kinds) and Diagrams (7 different kinds)
 Process for Using UML
Use case-driven, Architecture-centric, & Iterative and incremental

Lawrence Chung CS6358.OT1: Module 2 58

Points to Ponder
 How much unification does UML do?
Consider the Object Model Notation on the inside cover on the front and back of the textbook
"Object Oriented Modeling and Design" by Rumbaugh, et.al.
1. List the OMT items that do not exist in UML
2. List the UML items that do not exist in OMT
3. For those items of OMT for which UML equivalents exist, map the notation to UML.

 Where would you want to use stereotypes?

 Model the “Business Process” on page 6 in UML.
 Map the four (4) phases of the RUP to the traditional software lifecycle.
 If an object refers to a concept, can an object refer to a concept of an
concept? Consider some examples.
 What would be the essential differences between a property and an
attribute? Consider some examples.
 What is the syntax and semantics of a class diagram?
 In Component-Based Software Engineering (CBSE), components are the
units, or building blocks, of a (distributed) software system.
What kind of building blocks of UML can be components for CBSE?

Lawrence Chung CS6358.OT1: Module 2 59

 Points to Ponder

Are Sequence and Collaboration Diagrams Isomorphic?

course options form
1: add a course
course options course form course course offering
: Professor 2: display
form
3: select course offering

1: add a course
2: display : Professor course form

3: select course offering

5: get professor (professor id)
4: add professor (professor id)

4: add professor (professor id)

5: get professor (professor id)

course
6: add professor (professor) 6: add professor (professor)

course offering

Lawrence Chung CS6358.OT1: Module 2 60