1 / 60

Other High-Level Design Languages

Other High-Level Design Languages. Unified Modeling Language Object Description Language. UML: Introduction. UML was developed originally to describe software designs, and has been extended to describe DB designs. Brief history 1994-96: G. Booch, J. Rumbaugh, I. Jocobson (Rational Software)

ishana
Download Presentation

Other High-Level Design Languages

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Other High-Level Design Languages Unified Modeling Language Object Description Language

  2. UML: Introduction • UML was developed originally to describe software designs, and has been extended to describe DB designs. • Brief history • 1994-96: G. Booch, J. Rumbaugh, I. Jocobson (Rational Software) • 1997: UML 1.0, 1.1 • 2004/7: UML 1.4.2 (ISO/IEC 19501) • 2005/7: UML 2.0 • 2007/8: UML 2.1.1 • 2007/11: UML 2.1.2 • 2009/2: UML 2.2 • 2010/5: UML 2.3 • 2011/3: UML 2.4-beta 2 2 Lu Chaojun, SJTU

  3. UML vs. E/R vs. ODL • E/R: graphical • ODL: OO (covered later) • UML: graphical + OO • Midway between E/R and ODL. • Object=attributes+methods, unlike E/R ES • Has a graphical notation, unlike ODL • No multiway relationships as in E/R. • But allows attributes on binary relationships, which ODL doesn’t. 3 Lu Chaojun, SJTU Lu Chaojun, SJTU

  4. Classes • Sets of objects, with attributes (state ) and methods (behavior ). • Attributes have types. • PK indicates an attribute in the primary key (optional) of the object. • Methods have declarations: arguments (if any) and return type. 4 Lu Chaojun, SJTU

  5. Example: Student Class Class Name Attributes Methods Student Sno: string PK Name: string setName(n) getName() : string 5 Lu Chaojun, SJTU

  6. Associations • Binary relationships between classes. • Set of pairs of objects • Represented by named lines • Multiplicity at each end: m..n means between m and n of these associate with one on the other end. • Use * in place of n = “infinity” • Single * = 0..* • Default: 1..1 “exactly one” 6 Lu Chaojun, SJTU

  7. Example: Association Student Course 1..80 takes 0..* 7 Lu Chaojun, SJTU

  8. Multiplicity: UML vs E/R 0..* 0..* 0..* 0..1 0..* 1..1 E/R UML 8 Lu Chaojun, SJTU

  9. Self-association • An association can have both ends at the same class. • To distinguish two roles: use two names, one for each end. Student 1..1 monitorRole 1..* studRole 9 Lu Chaojun, SJTU Lu Chaojun, SJTU

  10. Association Classes • Attributes on associations are permitted. • Create an association class and attach it to the association. • It has its own name. • Its attributes may be thought of as attributes of the association. • Analogous to attributes on relationships in E/R. 10 Lu Chaojun, SJTU

  11. Example: Association Class Grade mark: int Student Course 1..80 takes 0..* 11 Lu Chaojun, SJTU

  12. Subclasses • Like E/R, but subclass points to superclass with a line ending in a triangle. • The subclasses of a class C (at the same level in the hierarchy) can be: • Complete or partial • Every object in C is in at least one subclass • Disjoint or overlapping • Every object in C is in at most one subclass 12 Lu Chaojun, SJTU

  13. Example: Subclasses Student sno: string name: string GradStud advisor: string EveningStud job: string NetworkStud place: string 13 Lu Chaojun, SJTU

  14. Aggregations • Relationships with implication that the objects on one side are “owned by” or are “part of ” objects on the other side. • Must be many-one • Represented by a diamond at the end of the connecting line, at the “owner” side. • Implications • In a relational implementation: no need to convert to a relation. • In OO, use reference to other class. 14 Lu Chaojun, SJTU

  15. Example: Aggregation • Open diamond: 0..1 • No need to name it. Student sno: string name: string Dorm num: string orientation: string 0..* 15 Lu Chaojun, SJTU

  16. Compositions • Like aggregations, but with the implication that every object is owned by exactly one object on the other side. • Represented by solid diamond at owner. 16 Lu Chaojun, SJTU

  17. Example: Composition • Solid diamond: 1..1 Student sno: string name: string Dept name: string head: string 0..* 17 Lu Chaojun, SJTU

  18. UML to Relation • General rules, like E/R: • Classes to relations • Same name, same attributes • Associations to relations • keys from the two connected classes+attributes from association class 18 Lu Chaojun, SJTU Lu Chaojun, SJTU

  19. Subclasses to Relations • We can use any of the three strategies outlined for E/R to convert a class and its subclasses to relations. • E/R-style: each subclass’ relation stores only its own attributes, plus key. • OO-style: relations store attributes of subclass and all superclasses. • Nulls: One relation, with NULL’s as needed. 19 Lu Chaojun, SJTU

  20. Subclasses to Relations(cont.) • If a hierarchy is disjoint at every level, then OO. • Need not to consider each possible tree of subclasses • If a hierarchy is both complete and disjoint at every level, then OO. • Construct relations for leaves of the hierarchy • If the hierarchy is large and overlapping at some or all levels, then E/R. 20 Lu Chaojun, SJTU Lu Chaojun, SJTU

  21. Aggr./Composition to Relations • Like E/R approach to many-one relationships, construct no relations for the aggregation. 21 Lu Chaojun, SJTU

  22. UML Analog of Weak ES • In OO, objects have OID. • Distinguishable even if they have the same values for each of their attributes and other properties. • In UML, we can take this viewpoint. Create new key attribute if necessary. • In UML, we can also treat compositions as supporting relationships for a “weak” class. • Conversion is the same as in E/R. 22 Lu Chaojun, SJTU Lu Chaojun, SJTU

  23. Example: Weak Class • Like in E/R: Schools(name, address) Class(schoolName, className, monitor) Schools name PK address Classes name PK monitor 0..* PK 23 Lu Chaojun, SJTU Lu Chaojun, SJTU

  24. ODL

  25. Object-Oriented DBMS • Standards group: ODMG • Object Data Management Group. • ODMG completed its work on ODMG 3.0 in 2001 and was disbanded. • ODMG imagines OO-DBMS vendors implementing an OO language like C++ with extensions that allow the programmer to transfer data between the database and “host language” seamlessly. 25 Lu Chaojun, SJTU

  26. ODMG Standard • ODMG = ODL + OQL • ODL = Object Description Language • Extension of IDL (CORBA) • Define persistent classes, whose objects are stored permanently in DB. • ODL class definitions are part of the extended, OO host language • OQL = Object Query Language • Imitate SQL in an OO framework. 26 Lu Chaojun, SJTU

  27. ODL Classes • A class declaration includes: • A name for the class; • Optional key declaration(s); • Property declarations: • Attribute • Relationship • Method 27 Lu Chaojun, SJTU

  28. Class Definitions • Simplest form: class <className> { <list of properties> } • Properties are separated by semicolons. 28 Lu Chaojun, SJTU

  29. Attribute Declarations • Attributes are (usually) elements with a type that does not involve classes. attribute <type> <name>; • Attribute type can be: • Simple type: integer, string, etc. • Nonatomic type: structures and collections 29 Lu Chaojun, SJTU

  30. Relationship Declarations • Relationships connect an object to one or more objects of another class. relationship <type> <name> inverse <relationship>; • Relationship type can be: • A class: many-one • A collection: one-many or many-many 30 Lu Chaojun, SJTU Lu Chaojun, SJTU

  31. Inverse Relationships • Suppose class C has a relationship R to class D. • Then class D must have some relationship S to class C. • R and S must be true inverses. • If object d is related to object c by R, then c must be related to d by S. 31 Lu Chaojun, SJTU

  32. Example class Student { attribute string sno; attribute string name; relationship Set<Course> take inverse Course::takenBy; } class Course { attribute string cno; attribute string title; relationship Set<Student> takenBy inverse Student::take; } 32 Lu Chaojun, SJTU

  33. Types of Relationships • The type of a relationship is either • A class, like C. If so, an object with this relationship can be connected to only one C object. • Set< C >: the object is connected to a set of C objects. • Bag< C >, List< C >, Array< C >: the object is connected to a bag, list, or array of C objects. 33 Lu Chaojun, SJTU

  34. Multiplicity of Relationships • All ODL relationships are binary. • Many-many relationships have Set<…> for the type of the relationship and its inverse. • Many-one relationships have Set<…> in the relationship of the “one” and just the class for the relationship of the “many.” • One-one relationships have classes as the type in both directions. 34 Lu Chaojun, SJTU

  35. Example: Multiplicity Many-many uses Set<…> in both directions. Many-one uses Set<…> only with the “one.” class Student { … relationship Set<Course> takes inverse Course::takenBy; relationship Course favorite inverse Course::fans; } class Course { … relationship Set<Student> takenBy inverse Student::takes; relationship Set<Student> fans inverse Student::favorite; } 35 Lu Chaojun, SJTU

  36. Another Example: Multiplicity husband and wife are one-one and inverses of each other. buddies is many-many and its own inverse. Note no :: needed if the inverse is in the same class. class Person { attribute … ; relationship Person husband inverse wife; relationship Person wife inverse husband; relationship Set<Person> buddies inverse buddies; } 36 Lu Chaojun, SJTU

  37. Multiway Relationships • ODL does not support 3-way or higher relationships. • We may simulate multiway relationships by a “connecting” class, whose objects represent tuples of objects we would like to connect by the multiway relationship. 37 Lu Chaojun, SJTU

  38. Connecting Classes • Suppose we want to connect classes X, Y, and Z by a relationship R. • Devise a class C, whose objects represent a triple of objects (x, y, z) from classes X, Y, and Z, respectively. • We need three many-one relationships from (x, y, z) to each of x, y, and z. 38 Lu Chaojun, SJTU

  39. Example: Connecting Class • Given Student and Course classes, how to represent grade? • relationship attribute as in E/R? No. • One solution: create class Grade and a connecting class SCG. • Better solution: since Grade objects are just numbers, • Give SCG objects an attribute grade. • Use two many-one relationships between SCG and Student / Course. 39 Lu Chaojun, SJTU

  40. Example: the Declaration • Here is the definition of SCG: class SCG { attribute grade:int; relationship Student theS inverse Student::toSCG; relationship Course theC inverse Course::toSCG; } • Student and Course must be modified to include relationships, both called toSCG, and both of type Set<SCG>. 40 Lu Chaojun, SJTU

  41. Types in ODL • Type system • Basic types • Primitive types: integer, float, character, string, boolean, enumeration • Class names • Structured types using type constructors • Collection types: Set<T>, Bag<T>, List<T>, Array<T,i>, Dictionary<KeyType,RangeType> • Structures: Struct N {T1 F1, … , Tn Fn} Lu Chaojun, SJTU

  42. Type Rules in ODL • Type of an attribute 1. Primitive 2. Apply structure or collection to 1,2 • Type of a relationship 1. Class 2. Collection of 1. Lu Chaojun, SJTU

  43. Example: Struct and Enum class Teacher { attribute string name; attribute Struct Addr {string street, string city, int zip} address; attribute Enum Degrees { bachelor, master, doctorate } degree; relationship … } 43 Lu Chaojun, SJTU

  44. Subclasses in ODL • Usual OO subclasses • Subclass inherits all properties of its superclass, having some special properties. • Example: class GradStud extends Student{ attributestring advisor; }; • Multiple inheritance allowed: class TA extends Student:Teacher {…} 44 Lu Chaojun, SJTU

  45. Superclass-Subclass Hierarchy • superclass -- subclass C C C1 C2 D1 D2 D D E Lu Chaojun, SJTU

  46. Keys in ODL • Key for a class: attribute (set) K that distinguishes among objects. • We can declare any number of keys for a class. • Key vs. OID • No requirement for keys in OO. • Declaration: after the class name, add: (key <list of keys>) 46 Lu Chaojun, SJTU

  47. Example: Keys class Student (key sno) { … Student number class Teacher (key tno,ID) {… Teacher number and ID are both keys class Classes (key (school,number),(number,tno)){… School name + class number, or teacher number + class number, are keys for all the classes of all schools. 47 Lu Chaojun, SJTU

  48. ODL to Relations • General rules class relation attributes attributes relationship connecting relation objects tuples Lu Chaojun, SJTU

  49. Class to Relation: primitive type • Classes with only primitive type attributes • Like ES in E/R or UML class • May need to add an artificial key! (for OID) • Example class Person { attribute string name; attribute string address; } Person(name,address) Lu Chaojun, SJTU

  50. Class to Relation: Struct • Struct of primitive type fields • expand the structure, each field to an attribute eg. class R { ... attribute Struct S { T1 F1, T2 F2, T3 F3} a; … }; R( … F1 , F2 , F3 ,… ) • T1, T2, T3 are atomic • Field name conflicts of two Structs: renaming Lu Chaojun, SJTU

More Related