Transcript Week 05

7
Object Oriented Database
and UML
MIS 304 Winter 2006
7
And now for Something Completely
Different…
2
7
Class Objective
• Understand the basic concepts of Object
Orientation.
• Understand how the OO approach differs from
the Relational approach.
• Apply the concepts of OO to Database
management.
• Understand the UML Modeling Language and how
it applies to databases
3
7
Object Orientation and Its Benefits
• Object orientation is a modeling and development
methodology based on object-oriented (OO)
concepts.
• Definition of Object Orientation:
A set of design and development principles based on
conceptually autonomous computer structures known as
objects. Each object represents a real-world entity with
the ability to interact with itself and with other objects.
• Think of objects as “Nouns” with the “Verbs” already
attached to them.
4
7
5
7
The History of Object Orientation
Video
6
7
Additional Information on PARC
• Dealers of Lightning: Xerox PARC and the Dawn
of the Computer Age , Michael Hiltzik, Texere,
2001, ISBN 1842030000
• Triumph of the Nerds, Robert Cringley, PBS, 1995.
7
7
The Evolution of OO Concepts
• From traditional to object-oriented programming
(OOP)
– Before OOP, data and procedures were isolated from each
other. Data were treated as the passive component, while
procedures manipulated the data as the active component.
– Procedural languages (e.g., COBOL) encouraged the rigid
distinction between data and procedure.
– In an OOP environment, the programmer asks Objects to
perform operations on themselves.
– OO concepts first appeared in some programming
languages and set the stage for more refined OO concepts.
8
7
The Evolution of OO Concepts
• Main Objectives of Object-Oriented
Programming Languages (OOPL)
– To provide an easy-to-use software development
environment.
– To provide a powerful software modeling tool for
applications prototyping.
– To decrease development time by reducing the amount
of code.
– To improve programmer productivity by making that
code reusable.
9
7
The Evolution of OO Concepts
• Important Attributes of OO Environment
– The data set is no longer passive.
– Data and procedures are bound together,
creating an object.
– The object has an innate ability to act on itself.
10
7
Object-Oriented Concepts
• Overview
– Objects: Components and Characteristics
– Object Identity
– Attributes (Instance Variables)
– Object State
– Messages and Methods
– Classes
– Protocol
– Superclasses, Subclasses, and Inheritance
– Methods Overriding and Polymorphism
– Abstract Data Types
– Object Classification
11
7
Object-Oriented Concepts
• Objects: Components and Characteristics
An object is an abstract representation of a real-world entity
that has a unique identity, embedded properties, and the
ability to interact with other objects and itself.
12
7
Object-Oriented Concepts
• Object Identity
– The object’s identity is represented by an object ID
(OID), which is unique to that object.
– The OID is assigned by the system at the moment of
the object’s creation and cannot be changed under any
circumstance.
– The OID can be deleted only if the object is deleted,
and that OID can never be reused.
13
7
Object Identity
• Based on an Object Identifier (OID)
• Must be guaranteed to be unique in the space in
which the object exists.
• Syntax options
– Dotted 1.2.3.4.5.6.7
– GUID Semi-Random number {}
14
7
Object-Oriented Concepts
• Attributes (Instance Variables)
– Objects are described by their attributes, known as
instance variables. (See Table 11.2)
– Attributes have a domain. The domain logically groups
and describes the set of all possible values that an
attribute can have.
– An attribute can be single valued or multivalued.
– Attributes may reference one or more other objects.
15
Object Attributes
7
16
7
Object-Oriented Concepts
• Object State
– The object state is the set of values that the object’s
attributes have at a given time.
• If we change the object’s state, we must change the
values of the object attributes.
• To change the object’s attribute values, we must send a
message to the object.
• This message invokes a method.
17
7
Object-Oriented Concepts
• Messages and Methods
– Every operation performed on an object must be
implemented by a method.
• Methods represent real-world actions and are equivalent
to procedures in traditional programming languages.
– Every method is identified by a name and has a body.
• The body is composed of computer instructions written in
some programming language to represent a real-world
action.
18
7
Object-Oriented Concepts
• Messages and Methods
– To invoke a method you send a message to the object.
• A message is sent by specifying a receiver object, the
name of the method, and any required parameters.
• The internal structure of the object cannot be accessed
directly by the message sender. The ability to hide the
object’s internal details (attributes and methods) is known
as encapsulation.
• An object may send messages to change or interrogate
another object’s state. (See Figure 11.3)
19
Objects Send Messages To Each Other
7
20
7
Object-Oriented Concepts
• Classes
– Objects that share common characteristics are
grouped into classes. A class is a collection of similar
objects with shared structure (attributes) and behavior
(methods).
– Each object in a class is known as a class instance or
object instance. (See Figure 11.4)
– Classes are general and extensible
– Example: STUDENT class (See Figure 11.5)
21
7
Class Illustration
Animal
Vertebrates
Living
Living
Backbone
22
Representation Of The Class Student
7
23
7
Object-Oriented Concepts
• Protocol
– The class’s collection of messages, each identified by a
message name, constitutes the object or class protocol.
– The protocol represents an object’s public aspect; i.e., it is
known by other objects as well as end users.
– The implementation of the object’s structure and methods
constitutes the object’s private aspect.
– A message can be sent to an object instance or the class.
When the receiver object is a class, the message will invoke a
class method.
24
7
Public and Private Aspects Of An Object
25
7
Flashlights Demo
• Example of basic OO concepts
26
OO Summary: Object Characteristics
7
27
7
Object-Oriented Concepts
• Superclasses, Subclasses, and Inheritance
– Classes are organized into a class hierarchy.
• Example: Musical instrument class hierarchy (Figure 11.8)
– Piano, Violin, and Guitar are a subclass of Stringed instruments,
which is, in turn, a subclass of Musical instruments.
– Musical instruments defines the superclass of Stringed
instruments, which is, in turn, the superclass of the Piano, Violin,
and Guitar classes.
– Inheritance is the ability of an object within the hierarchy to
inherit the data structure and behavior (methods) of the
classes above it.
28
7
Musical Instruments Class Hierarchy
29
Object-Oriented Concepts
7
• Two variants of inheritance:
– Single inheritance exists when a class has only one
immediate superclass above it.
• Most of the current OO systems support single inheritance.
• When the system sends a message to an object instance, the
entire hierarchy is searched for the matching method in the
following sequence:
– Scan the class to which the object belongs.
– If the method is not found, scan the superclass.
• The scanning process is repeated until either one of the
following occurs:
– The method is found.
– The top of the class hierarchy is reached without finding the
message.
30
7
Single Inheritance
31
7
Object-Oriented Concepts
• Two variants of inheritance:
– Multiple inheritance allow a class to be derived from several
parent superclasses located above that class.
– Single inheritance exists when a class has only one
immediate (parent) superclass above it.
32
Motor Vehicle And
Bicycle Instance Variables
7
33
7
Object-Oriented Concepts
• Method Overriding and Polymorphism
– We may override a superclass’ method definition by
redefining the method at the subclass level. (See
Figure 11.12)
– Polymorphism allows different objects to respond to
the same message in different ways. (See Figure
11.13)
34
Employee Class Hierarchy
Method Override
7
35
Employee Class Hierarchy
Polymorphism
7
36
7
Object-Oriented Concepts
• Object Classification
– A simple object contains only single-valued attributes and
none of its attributes refer to another object.
– A composite object contains at least one multivalued
attribute and none of its attributes refer to another object.
– A compound object contains at least one attribute that
references another object.
– A hybrid object contains a repeating group of attributes, and
at least one of the repeating attributes refers to another
object.
– An associative object is used to represent a relationship
between two or more objects.
37
7
Characteristics of an OO Data Model
• An Object-Oriented Data Model Must:
– Support the representation of complex objects.
– Be extensible; i.e., it must be capable of defining new data
types as well as the operations to be performed on them.
– Support encapsulation; i.e., the data representation and the
method’s implementation must be hidden from external
entities.
– Exhibit inheritance; an object must be able to inherit the
properties (data and methods) of other objects.
– Support the notion of object identity (OID).
38
7
How do you apply these concepts to
Databases?
39
OO And E-R Model Components
7
40
7
OODM and Previous Data Models
• Object, Entity, and Tuple
– An OODM object has additional characteristics
such as behavior, inheritance, and
encapsulation.
– Such characteristics make OO modeling much
more natural than E-R and relational
modeling.
41
An Invoice Representation
7
But remember the object has “methods” attached to it too.
42
7
OODM and Previous Data Models
• Class, Entity Set, and Table
– Class is a more powerful concept that allows not only the
description of the data structure but also the description of
the behavior.
– A class allows both the concept and the implementation of
abstract data types.
• Encapsulation and Inheritance
– An object belonging to a class inherits all the properties of its
superclasses.
– Encapsulation hides the data representation and the
method’s implementation from other objects and the user.
43
7
OODM and Previous Data Models
• Object ID
– Object ID is not supported in either the E-R model or
the relational model.
– The hierarchical and the CODASYL models support
some form of ID.
• Relationships
– Relationships in an OODM can be of two types:
interclass references or class hierarchy inheritance.
– E-R and relational models use a value-based
relationship approach.
44
7
OODM and Previous Data Models
• Access
– E-R and relational models use an ad hoc, setoriented query language.
– OODM is suited to support both navigational
and set-oriented access.
45
7
Object-Oriented DBMS
46
The Thirteen OODBMS Rules
7
47
7
How OO Affects Database Design
• OO database design approach provides both the
data identification and the procedures or data
manipulation to be performed.
• OO database design forces us to think of data
and procedures as a self-contained entity.
• OO design is iterative and incremental in nature.
• DBA’s role is likely to change with more
programming responsibilities.
• Lack of standards affects OO database design.
48
7
OODBMS: Advantages and Disadvantages
• Advantages
– More semantic information.
– Support for complex objects.
– Extensibility of data types.
– Improved performance with efficient caching.
– Versioning.
– Faster development and easy maintenance through inheritance and
reusability.
– Technology-driven product for next generation DBMS.
– Potential to integrate DBMSs into a single environment.
49
7
OODBMS: Advantages and Disadvantages
• Disadvantages
– Strong opposition from the established players.
– Lack of theoretical foundation.
– Retrogressive to the old pointer systems.
– Lack of standard ad hoc query language.
– Lack of business data design and management tools.
– Steep learning curve.
– Lack of resources.
50
7
How OO Concepts Have Influenced the
Relational Model
• New Features for Extended Relational
(Object/Relational) Model
– Extensibility of new user-defined (abstract) data types
– Complex objects
– Inheritance
– Procedure calls (rules or triggers)
– System-generated identifiers (OID surrogates)
51
7
How OO Concepts Have Influenced the
Relational Model
• Philosophy that guides the relational model’s
enhancements:
– Semantic and object-oriented concepts are necessary to
support the new generation of applications.
– These concepts can and must be added to the relational model.
– The benefits of the relational model must be preserved to
protect the investment in relational technology and to provide
downward compatibility.
52
7
The Next Generation of DBMS
• The next generation of DBMS is likely to
incorporate features borrowed from:
– Object-oriented database systems
– Artificial intelligence systems
– Expert systems
– Distributed database
– The Internet
53
7
So how do we model it?
• Need a new modeling methodology that accounts
for these new features.
54
7
55
7
Unified Modeling Language
MIS 304 Winter 2006
7
Class Objective
• Understand the Reasons for the development of a
UML
• Apply the concepts of UML to Databases
• Be able to construct some simple UML models.
57
7
Tower of Babel
• You have already seen 4 different “Modeling
Languages”
– The two in the book (actually 4 were mentioned)
– MS Access “Relationships”
– Basic “Objects”
• There are dozens of others.
58
7
Modeling Goals
• One of the goals of modeling is to improve
communication.
• When two IT people got together to compare
models they often waste a lot of time explaining
their models syntax to one another.
• You learn one in school and the organization you
work for uses another.
What to do?
59
7
The Solution
Put all of the World’s “Modeling Experts” in a room
and push pizza under the door every 5 hours but
don’t let them out until they agree on a single way
of modeling a “system”.
60
7
The Result - UML
•
•
•
•
An “Object Oriented” approach to modeling.
A common modeling notation.
A common modeling language.
Defines several related model notations for
representing all aspects of a system.
61
7
UML Goals
• To represent complete systems, not just software.
• Establish a explicit coupling between concepts
and executable code.
• Take into account scaling factors.
• Make the model understandable to humans and
machines.
62
7
UML Models
•
•
•
•
The Class Model for static structures.
The State model expresses dynamic behavior.
The Use Case describes the requirements of the user.
The Interaction Model represents scenarios and message
flows.
• The Implementation Model shows the work units
• The Deployment Model provides details that pertain to process
allocation.
And a special subset for Databases
63
7
A UML Model of UML Models
0..M
Package
Includes
0..1
0..*
0..1
Model
0..*
0..* References
Element
Model Element
Visual Element
1..*
0..*
Projection
64
7
UML Diagrams
• The Diagram provides the reader with a means of
Visualizing and manipulating model elements.
• The level of detail is suitable to the Context.
• The common building block is the Element.
• Mechanisms provide a way to link and describe
the elements.
65
7
UML Diagrams
•
•
•
•
•
•
•
•
•
Class Diagram 
Sequence Diagram 
Collaboration Diagram
Object Diagram 
Statechart Diagram
Activity Diagram 
Use Case Diagram 
Component Diagram
Deployment Diagram
66
7
Packages
• Provide a way to partition
a model
• Defines a namespace
• Packages can be
contained in other
packages.
Package Name
67
7
Class Diagrams
• A general way to describe
static structure.
• Describes a classic object
“class”
• No real change from
traditional OO model
notation
Class Name
Properties
Operations
68
7
Class Example
• Flashlight class
Flashlight
Handle
Shape
Bulbs
OnOff( )
69
7
Associations
An Association
Tools
Flashlight
A Link
Flashlight
Maglight
70
7
Associations
• Describe how elements are linked together.
–
–
–
–
–
1
0..1
M..N
0..*
1..*
One and only one
0 to 1
Many to many
0 to any integer
1 to any integer
71
7
Associations
0..M
Package
Includes
0..1
0..*
0..1
Model
0..*
0..* References
Element
Model Element
Visual Element
1..*
0..*
Projection
72
7
Class Hierarchy
Animal
Legs
2 Legs
4 Legs
Food
Carnivore
73
7
Object Diagrams
• Show a static state.
• Primarily used to show context.
• Look like Class diagrams.
74
7
Use Case
• Describes how the people involved “Use” the
system.
• Simple diagram that lays out the actors interfaces
and associations.
• One of the first steps in system design.
75
7
Use Case for Automobile
Drive
«uses»
«uses»
Customer
Service
Repair
«uses»
Mechanic
76
7
Activity Diagrams
• Represents the activities or behaviors of a
system.
77
7
Activity Diagram
Supply SSN
a.PersonID
Look up Person
SELECT PersonID, Name
FROM Person
WHERE p.PersonID =
a.PersonID
Identify
Person
Name
78
Activity Diagram With Swimlanes
Teacher
Student
7
Board
Teach
Learn
Supervise
Exam
Take Exam
Evaluate
79
7
Sequence Diagrams
• Used to display interactions between objects.
• Focuses on expressing interactions.
• Defines the sequence of actions between objects.
80
7
Sequence Diagrams
Caller
Phone
Recipient
Picks Up
Dial Tone
Dial
Ring
Ring
Picks Up
Hello
81
7
UML Patterns
•
How humans solve problems.
1.
2.
3.
•
•
•
Look at a problem.
Try to find an analog in our experience.
Adapt the analog to our problem.
In a formal system you can do this in a
standardized way.
In UML these are called “Patterns”
In UML Patterns are identified by a Name.
82
7
UML Database Patterns
•
•
•
•
Singleton
Composite
Flyweight
Analysis Patterns
–
–
–
–
Party
Geographical location
Process
Document
83
7
Singleton
• The Problem
– One object instance
– Used in hierarchy where the entity is part of the
structure. (A manager is an Employee)
• The Solution
– Single relationship with itself.
84
7
Singleton
The Data and
AnyOperation elements
represent the classspecific attributes an d
operations
Singleton
#Data: Any
+Instance( ) Singleton
+AnyOperations( ): Any
1
1..1
85
7
Composite
• Models the basic “Parent-Child” relationship.
• Used things for Organization Charts, HeaderDetail structures or any similar pattern.
86
7
Composite UML
87
7
Composite ERD
1
Table1
Table2
Has
(x,y)
Key1
M
Attr1
(x,y)
Key2
Key1
88
7
Generating SQL From UML
A
A1 : String
A2 : String
CREATE TABLE A (
A_Id Number (5),
A1 VARCHAR(),
A2 VARCHAR(),
PRIMARY KEY(A_Id)
)
SetPrimaryKey(A_Id)
89
7
References
• Database Design for Smarties Using UML for Data
Modeling, Robert J. Muller, Academic Press, 1999,
ISBN 1-55860-515-0
90