Object Oriented Database and UML - PowerPoint PPT Presentation

Loading...

PPT – Object Oriented Database and UML PowerPoint presentation | free to download - id: 60093a-MDgyM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Object Oriented Database and UML

Description:

MIS 304 Winter 2006 And now for Something Completely Different Class Objective Understand the basic concepts of Object Orientation. Understand how the OO approach ... – PowerPoint PPT presentation

Number of Views:354
Avg rating:3.0/5.0
Slides: 91
Provided by: gmmCottag
Learn more at: http://www.gmm.cottageland.net
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Object Oriented Database and UML


1
Object Oriented Database and UML
  • MIS 304 Winter 2006

2
And now for Something Completely Different
3
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

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

5
(No Transcript)
6
The History of Object Orientation
Video
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.

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

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

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

11
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

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

13
Object-Oriented Concepts
  • Object Identity
  • The objects 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 objects 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.

14
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

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

16
Object Attributes
17
Object-Oriented Concepts
  • Object State
  • The object state is the set of values that the
    objects attributes have at a given time.
  • If we change the objects state, we must change
    the values of the object attributes.
  • To change the objects attribute values, we must
    send a message to the object.
  • This message invokes a method.

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

19
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 objects internal details
    (attributes and methods) is known as
    encapsulation.
  • An object may send messages to change or
    interrogate another objects state. (See Figure
    11.3)

20
Objects Send Messages To Each Other
21
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)

22
Class Illustration
Animal Living
Vertebrates Living Backbone
23
Representation Of The Class Student
24
Object-Oriented Concepts
  • Protocol
  • The classs collection of messages, each
    identified by a message name, constitutes the
    object or class protocol.
  • The protocol represents an objects public
    aspect i.e., it is known by other objects as
    well as end users.
  • The implementation of the objects structure and
    methods constitutes the objects 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.

25
Public and Private Aspects Of An Object
26
Flashlights Demo
  • Example of basic OO concepts

27
OO Summary Object Characteristics
28
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.

29
Musical Instruments Class Hierarchy
30
Object-Oriented Concepts
  • 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.

31
Single Inheritance
32
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.

33
Motor Vehicle And Bicycle Instance Variables
34
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)

35
Employee Class Hierarchy Method Override
36
Employee Class Hierarchy Polymorphism
37
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.

38
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 methods 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).

39
How do you apply these concepts to Databases?
40
OO And E-R Model Components
41
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.

42
An Invoice Representation
But remember the object has methods attached to
it too.
43
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 methods implementation from other objects
    and the user.

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

45
OODM and Previous Data Models
  • Access
  • E-R and relational models use an ad hoc,
    set-oriented query language.
  • OODM is suited to support both navigational and
    set-oriented access.

46
Object-Oriented DBMS
47
The Thirteen OODBMS Rules
48
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.
  • DBAs role is likely to change with more
    programming responsibilities.
  • Lack of standards affects OO database design.

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

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

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

52
How OO Concepts Have Influenced the Relational
Model
  • Philosophy that guides the relational models
    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.

53
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

54
So how do we model it?
  • Need a new modeling methodology that accounts for
    these new features.

55
(No Transcript)
56
Unified Modeling Language
  • MIS 304 Winter 2006

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

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

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

60
The Solution
  • Put all of the Worlds Modeling Experts in a
    room and push pizza under the door every 5 hours
    but dont let them out until they agree on a
    single way of modeling a system.

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

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

63
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

64
A UML Model of UML Models
0..M
0..1
Package
Model
0..1
0..
References
Includes
0..
0..
Element
Model Element
Visual Element
1..
0..
Projection
65
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.

66
UML Diagrams
  • Class Diagram ?
  • Sequence Diagram ?
  • Collaboration Diagram
  • Object Diagram ?
  • Statechart Diagram
  • Activity Diagram ?
  • Use Case Diagram ?
  • Component Diagram
  • Deployment Diagram

67
Packages
  • Provide a way to partition a model
  • Defines a namespace
  • Packages can be contained in other packages.

Package Name
68
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
69
Class Example
  • Flashlight class

Flashlight Handle Shape Bulbs OnOff( )
70
Associations
An Association
Tools
Flashlight
A Link
Flashlight
Maglight
71
Associations
  • Describe how elements are linked together.
  • 1 One and only one
  • 0..1 0 to 1
  • M..N Many to many
  • 0.. 0 to any integer
  • 1.. 1 to any integer

72
Associations
0..M
0..1
Package
Model
0..1
0..
References
Includes
0..
0..
Element
Model Element
Visual Element
1..
0..
Projection
73
Class Hierarchy
Animal
Legs
Food
2 Legs
4 Legs
Carnivore
74
Object Diagrams
  • Show a static state.
  • Primarily used to show context.
  • Look like Class diagrams.

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

76
Use Case for Automobile
Drive
uses
uses
Customer
Service
uses
Repair
Mechanic
77
Activity Diagrams
  • Represents the activities or behaviors of a
    system.

78
Activity Diagram
Look up Person SELECT PersonID, Name FROM Person
WHERE p.PersonID a.PersonID
Identify Person Name
Supply SSN a.PersonID
79
Activity Diagram With Swimlanes
Teacher
Student
Board
Teach
Learn
Supervise Exam
Take Exam
Evaluate
80
Sequence Diagrams
  • Used to display interactions between objects.
  • Focuses on expressing interactions.
  • Defines the sequence of actions between objects.

81
Sequence Diagrams
Caller
Phone
Recipient
Picks Up
Dial Tone
Dial
Ring
Ring
Picks Up
Hello
82
UML Patterns
  • How humans solve problems.
  • 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.

83
UML Database Patterns
  • Singleton
  • Composite
  • Flyweight
  • Analysis Patterns
  • Party
  • Geographical location
  • Process
  • Document

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

85
Singleton
Singleton Data Any Instance( )
Singleton AnyOperations( ) Any
1
The Data and AnyOperation elements represent the
class-specific attributes an d operations
1..1
86
Composite
  • Models the basic Parent-Child relationship.
  • Used things for Organization Charts,
    Header-Detail structures or any similar pattern.

87
Composite UML
88
Composite ERD
1
M
Table1
Table2
Has
(x,y)
(x,y)
Key2
Key1
Key1
Attr1
89
Generating SQL From UML
A A1 String A2 String SetPrimaryKey(A_Id)
CREATE TABLE A ( A_Id Number (5), A1
VARCHAR(), A2 VARCHAR(), PRIMARY KEY(A_Id) )
90
References
  • Database Design for Smarties Using UML for Data
    Modeling, Robert J. Muller, Academic Press, 1999,
    ISBN 1-55860-515-0
About PowerShow.com