Presentation is loading. Please wait.

Presentation is loading. Please wait.

Pratt & Adamski chapter 9 & Some extra material The Object-Oriented approach Object-Oriented DBMSs Semantic Object Models Spring 2012.

Similar presentations


Presentation on theme: "Pratt & Adamski chapter 9 & Some extra material The Object-Oriented approach Object-Oriented DBMSs Semantic Object Models Spring 2012."— Presentation transcript:

1 Pratt & Adamski chapter 9 & Some extra material The Object-Oriented approach Object-Oriented DBMSs Semantic Object Models Spring 2012

2 Overview Object-Oriented Systems Class Diagrams Unified Modeling Language (UML) Object-Oriented DBMS Semantic Object Models (SOM)

3 Object-Oriented Systems View the world in terms of objects ("things") Easier to think of systems as objects (customer, shipping clerk,,) main driver: reusability Object-orientation appears as: Object-oriented user interfaces (90% of new projects) Object-oriented programming (80% of new projects) Object-oriented databases (5% or less) OO analysis and design (30 to 40%)

4 Objects: Key Concepts Definition: Objects are data guarded by a protective layer of code. OO Software components consist of variables and methods Key concepts of the object-oriented paradigm: object attributes of objects methods of object show behavior (what it can provide ) class : template of objects inheritance (lower level objects can inherit from higher level)

5 Objects: Key Concepts Key Concepts (continued): -Modularity (reduce complex systems into highly cohesive but loosely coupled modules) -Encapsulation (Information hiding in implementation) Message Objects communicate via message passing. A message consists of an object (the recipient), a method, and optional parameters.

6 Object Examples Example: items in a department store. TV is an object. The attributes of this object are model, year, cost, etc.The methods, for store are, purchase, repair Radio is another object, so is a dishwasher many of these objects have similar properties (attributes, methods) can define a hierarchy.

7 Object Examples A Customer object is customer data and customer methods The attributes of customer object are Name, Address, Account No, Balance Due The methods on the customer object are Send-Invoice, Add-Customer, etc. Customer Name Address Account No Balance Due Add-Customer() Update-Customer() Get-Balance-Due() Send-Invoice() Smith: Customer -Smith -1109 Main St. -1100987546 -$589.19 Add-Customer() Update-Customer() Get-Balance-Due() Send-Invoice() ClassObject

8 Unified Modeling Language (UML) Original version released in 1996 Became an International Standard in 1997 with the formation of UML Partners (HP, IBM, Microsoft, Oracle, Rational Software) A graphical language for Object-Oriented Analysis and Design (OOAD) Manage Resources Manage Projects Project Manager Resource Manager Use Case Diagram Class Diagram Resource Salaried Hourly Sequence Diagram

9 Unified Modeling Language (UML) 1. Use Case Diagram 2. Class Diagrams 3. Object Diagrams 4. Sequence Diagrams 5. Collaboration Diagrams 6. Statechart Diagrams 7. Activity Diagrams 8. Component Diagrams 9. Deployment Diagrams Unified Modeling Language (UML)

10 Use-cases  Use cases describe the functionality of the system from the user point of view.  Each use case provides one or more scenarios of how the system should interact with the users called actors  Use cases are written in non-technical language, understood by users  Use cases are written as a part of requirement analysis.  Use cases are separate and distinct from use case diagrams, which allow one to abstractly work with groups of use cases.  Use case diagrams are created after the use case descriptions are written. Source: Dr. Sidorova, UNT

11 Use Cases Diagrams Depiction of a system’s behavior or functionality under various conditions as the system responds to requests from users Actor Use-case System boundary Association (connection) Include relationship Extend relationship Generalization relationship > Source: Dr. Sidorova, UNT

12 Example of a use case diagram from Wikepidea Source: Dr. Sidorova, UNT

13 Class: Key Concepts Class A template or prototype that defines the composition and the behavior of all objects of certain kinds. These objects are called instances of the class Inheritance A mechanism to organize classes by commonalities.  subclasses, specialization  superclass, generalization Example: Student GradStudent MSStudent PhDStudent UGStudent

14 Class diagrams  A class: point  An object: p1  Attributes or fields: int x, y;  A method: point move(int dx, int dy)  A message: p2 = p1.move(10, 10) Point xyxy Move Fields (attributes) Class name methods p1: Point x = 0 y = 0 p2: Point x = 10 y = 10

15 Name of class Attributes Data types Methods (operations) Association (relationship) Multiplicity (cardinality) Class Diagram details

16 Associations are shown as lines joining classes and represent relationships. Multiplicity indicates the number of objects at the end of the relationship. Example: 1..1, 0..n, 1..n. The visibility symbol indicates whether other classes can view or update attribute values: –Public visibility (+), any other class can view/update –Protected visibility (#), class itself or its subclasses can view/update –Private visibility (-), only class itself can view/update

17 Class Diagram for Premiere Products Figure 9.24

18 Class Diagram with Constraints Figure 9.25

19 Class Diagram with a Generalization and a Constraint Figure 9.26

20 Object-Oriented DBMS (OODBMS) System in which data and the methods operating on that data are encapsulated into objects Store graphics, drawings, video, sound, and other complex objects called binary large objects (BLOBs) General concepts –Objects and classes –Methods and messages –Inheritance

21 Rules for OODBMSs: what they should support 1.Complex Objects 2.Object Identity 3.Encapsulation 4.Information Hiding 5.Types (classes) 6.Inheritance 7.Late Binding (polymorphism) 8.Computational Completeness 9.Extensibility 10.Persistence 11.Performance 12.Concurrent Update support 13.Recovery support 14.Query facilities

22 Semantic Object Model (SOM): a different approach

23 S-O MODEL CHARACTERISTICS S-O Model More Bottom-Up-Oriented than the E-R Model Both Are a Type of "Pseudo-Code“ or "Flowchart" Tool For DB Design David Kroenke primary developer of the SO Model (1994). –The Model Is Robust But Lacks Standards. –NOT Widely Used Yet in CASE Tools.

24 S-O MODEL DEFINITIONS 1.* Semantic Object 2.* Object Identifier (primary key) 3.* Object Properties or Attributes 4.* Semantic Object Links 5.* Formulas

25 S-O MODEL DEFINITIONS * Semantic Objects -- Represented by a Rectangle (See Fig B.2.a) –A named collection of Properties that sufficiently describes a distinct entity (Things, Objects (Nouns) Of Importance To The Users' Data Model) –E.g., Employee, Customer, Inventory, Order, Etc. Instance Of A Semantic Object (Fig B.3) –Professor “Nick Evangelopoulos” Semantic Object Classes -- –Collections Of Same Types Of Objects

26 Object Diagram Fig. B.2

27 Figure B.3 Instance of a Semantic Object

28 S-O MODEL DEFINITIONS * Semantic Objects are Distinct Entities -- –There are NO “weak” semantic objects! –Consider the relational DB design of an ordering system: Line_Item would be property of ORDER, not a distinct entity. –Semantic Objects are ALWAYS independent!! –Names in CAPITAL letters Semantic Objects: Must Exist In The Minds Of The Users-- This is Why They Are Called Semantic Objects

29 S-O MODEL DEFINITIONS Object Identifier: –Identifies A Unique Object Instance (Key) –May Be a Group or Composite (concatenated) Key (OrderNum, LineNum), (Cust_Name, Cust_Addr) –ID NameMixedCase –ID UniqueId when underlined

30 S-O MODEL DEFINITIONS * Properties (Or Attributes) -- Fig B.2 Characteristics Of Semantic Objects: –Simple Data Values (S) –Multi-Valued (MV or 1.N) –Composite or Group Attributes (G) –Object attributes or Semantic Object Links (SOLs); (see below) Paired attributes: If an object contains another object, the second object will contain the first [SOLs are reciprocal] –USE Mixed Case for Naming Convention: DeptId

31 Figure B.2 (b) Cardinalities (Min.Max)

32 S-O MODEL DEFINITIONS * Semantic Object Link (SOL) –Special Type of Property –Recursiveness –Represented by a rectangle inside of the SO * Formulas (F) –Formula Functions: SUM, COUNT, MIN, MAX, AVG –Formula Expressions: e.g., Salary / 12

33 Figure B.2 (a) & (b) SOLs

34 S-O MODEL DEFINITIONS (Misc..) Property Domains –Set Of All Possible Values Of A Property Semantic Object Views (Fig. B.4) –Subset Of Properties Of S-O Required By A Particular Application Or User. Synthesis Of Multiple Objects –Views Required To Build Complete Object Diagram.

35 Figure B.4 Semantic Object View

36 S-O DIAGRAMS Guidelines Picture Of User’s Defined Objects –Non-Standard notation Rectangles for Objects; NAMES in Capital letters inside rectangle Object Properties written in MixedCase SOLinks -- Written in Capital letters inside their own rectangles within the SO Groups (Composites) properties are bracketed or braced on Right-hand side

37 S-O DIAGRAMS Guidelines (continued) Multi-valued property Cardinalities are shown as Subscripts: –1.1, 1.N, 0.1, 0.N, etc. (also, MV) –Actually Minimum and Maximum Cardinality for each property (ID, S, G, or SOL) Min.Max The minimum and maximum allowable occurrences for each property. 0.1 means that the property may have no instances, but at most 1. 1.N means that the property must have at least one instance, and could have many instances.

38 Figure B.2 (b) Cardinalities (Min.Max)

39 Summary Object-Oriented Systems Class Diagrams Unified Modeling Language (UML) Object-Oriented DBMS Semantic Object Models (SOM)


Download ppt "Pratt & Adamski chapter 9 & Some extra material The Object-Oriented approach Object-Oriented DBMSs Semantic Object Models Spring 2012."

Similar presentations


Ads by Google