Topics

Sub Classes, Super Classes Specialization and Generalization Participation Constraints UML Class Diagram

Subclasses and Superclasses (1)

An entity type may have additional meaningful subgroupings of its entities
Example: EMPLOYEE may be further grouped into:
SECRETARY, ENGINEER, TECHNICIAN,
Based on the EMPLOYEEs Job

MANAGER
EMPLOYEEs who are managers

SALARIED_EMPLOYEE, HOURLY_EMPLOYEE
Based on the EMPLOYEEs method of pay

EER diagrams extend ER diagrams to represent these additional subgroupings, called subclasses or subtypes

Subclasses and Superclasses

Subclasses and Superclasses (2)

Each of these subgroupings is a subset of EMPLOYEE entities Each is called a subclass of EMPLOYEE EMPLOYEE is the superclass for each of these subclasses These are called superclass/subclass relationships:
EMPLOYEE/SECRETARY EMPLOYEE/TECHNICIAN EMPLOYEE/MANAGER

Subclasses and Superclasses (3)

These are also called IS-A relationships
SECRETARY IS-A EMPLOYEE, TECHNICIAN IS-A EMPLOYEE, .

Note: An entity that is member of a subclass represents the same real-world entity as some member of the superclass:
The subclass member is the same entity in a distinct specific role

Representing Specialization in EER Diagrams

Attribute Inheritance in Superclass / Subclass Relationships

An entity that is member of a subclass inherits All attributes of the entity as a member of the superclass All relationships of the entity as a member of the superclass Example: In the previous slide, SECRETARY (as well as TECHNICIAN and ENGINEER) inherit the attributes Name, SSN, , from EMPLOYEE Every SECRETARY entity will have values for the inherited attributes

Specialization (1)
Specialization is the process of defining a set of subclasses of a superclass The set of subclasses is based upon some distinguishing characteristics of the entities in the superclass Example: {SECRETARY, ENGINEER, TECHNICIAN} is a specialization of EMPLOYEE based upon job type. May have several specializations of the same superclass

Specialization (2)
Example: Another specialization of EMPLOYEE based on method of pay is {SALARIED_EMPLOYEE, HOURLY_EMPLOYEE}.
Superclass/subclass relationships and specialization can be diagrammatically represented in EER diagrams Attributes of a subclass are called specific or local attributes.
For example, the attribute TypingSpeed of SECRETARY

The subclass can also participate in specific relationship types.

For example, a relationship BELONGS_TO of HOURLY_EMPLOYEE

Specialization (3)

Generalization
Generalization is the reverse of the specialization process Several classes with common features are generalized into a superclass;
original classes become its subclasses

Example: CAR, TRUCK generalized into VEHICLE;

both CAR, TRUCK become subclasses of the superclass VEHICLE. We can view {CAR, TRUCK} as a specialization of VEHICLE Alternatively, we can view VEHICLE as a generalization of CAR and TRUCK

Generalization (2)

Generalization and Specialization (1)

Diagrammatic notation are sometimes used to distinguish between generalization and specialization Arrow pointing to the generalized superclass represents a generalization Arrows pointing to the specialized subclasses represent a specialization We do not use this notation because it is often subjective as to which process is more appropriate for a particular situation We advocate not drawing any arrows

Generalization and Specialization (2)

Data Modeling with Specialization and Generalization A superclass or subclass represents a collection (or set or grouping) of entities It also represents a particular type of entity Shown in rectangles in EER diagrams (as are entity types) We can call all entity types (and their corresponding collections) classes, whether they are entity types, superclasses, or subclasses

Displaying an attribute-defined specialization in EER diagrams

Relationships
Relationships between entities can be optional or compulsory. Total participation Partial participation In an ER diagram, we indicate total participation with a double line between the entity box and the relationship diamond.

Total Participation

Example

Partial Participation

Example

Example
We could decide that a person is considered to be a customer only if they have bought a product. On the other hand, we could say that a customer is a person whom we know about and whom we hope might buy something that is, we can have people listed as customers in our database who never buy a product. In the first case, the customer entity has total participation in the bought relationship (all customers have bought a product, and we cant have a customer who hasnt bought a product), while in the second case it has partial participation (a customer can buy a product). These are referred to as the participation constraints of the relationship.

Participation Constraints
Recall that a key constraint requires that each entity of a set be required to participate in at most one relationship. Dual to this, we may ask whether each entity of a set be required to participate in at least one relationship. If this is required, we call this a total participation constraint; otherwise the participation is partial. In our ER diagrams, we will represent a total participation constraint by using a double or thick line.

Example

UML

What is UML?
The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems. The UML is a very important part of developing object oriented software and the software development process. The UML uses mostly graphical notations to express the design of software projects. Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software.

Goals of UML
The primary goals in the design of the UML were: Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models. Provide extensibility and specialization mechanisms to extend the core concepts. Be independent of particular programming languages and development processes. Provide a formal basis for understanding the modeling language. Encourage the growth of the OO tools market. Support higher-level development concepts such as collaborations, frameworks, patterns and components. Integrate best practices.

Why Use UML?

As the strategic value of software increases for many companies, the industry looks for techniques to automate the production of software and to improve quality and reduce cost and time-to-market. These techniques include component technology, visual programming, patterns and frameworks. Businesses also seek techniques to manage the complexity of systems as they increase in scope and scale. In particular, they recognize the need to solve recurring architectural problems, such as physical distribution, concurrency, replication, security, load balancing and fault tolerance. Additionally, the development for the World Wide Web, while making some things simpler, has exacerbated these architectural problems. The Unified Modeling Language (UML) was designed to respond to these needs.

Types of UML Diagrams

Use Case Diagram: displays the relationship among actors and use cases.1 Class Diagram: models class structure and contents using design elements such as classes, packages and objects. It also displays relationships such as containment, inheritance, associations and others. 1 Interaction diagrams Sequence Diagram displays the time sequence of the objects participating in the interaction. This consists of the vertical dimension (time) and horizontal dimension (different objects).1 Collaboration Diagram displays an interaction organized around the objects and their links to one another. Numbers are used to show the sequence of messages.1

Class diagrams
Class diagrams are widely used to describe the types of objects in a system and their relationships. Class diagrams describe three different perspectives when designing a system, conceptual, specification, and implementation. These perspectives become evident as the diagram is created and help solidify the design.

Classes
Classes are composed of three things: a name, attributes, and operations. Below is an example of a class.

UML Class Diagram

Represent classes (similar to entity types) as large rounded boxes with three sections:
Top section includes entity type (class) name Second section includes attributes Third section includes class operations (operations are not in basic ER model)

Relationships (called associations) represented as lines connecting the classes

Other UML terminology also differs from ER terminology

Used in database design and object-oriented software design

Relationship
The association relationship is the most common relationship in a class diagram. The association shows the relationship between instances of classes.

Example
For example, the class Order is associated with the class Customer. The multiplicity of the association denotes the number of objects that can participate in then relationship. For example, an Order object can be associated to only one customer, but a customer can be associated to many orders.

Class Hierarchies

As with object-oriented programming, it is often convenient to classify an entity sets as a subclass of another. In this case, the child entity set inherits the attributes of the parent entity set. We will denote this scenario using an "ISA" triangle, as in the next slide ER diagram:

ER diagram

Aggregation
Define new relationship which associates some entity with some other existing relationship. To do this, we will introduce a new feature to our model called aggregation. Identifying an existing relationship set by enclosing it in a larger dashed box, and then we will allow it to participate in another relationship set.

Example

ER Model for library information system

Entity type BOOK(ISBN,title,author,publisher,date-ofpub,{keywords}) Notice {keywords} is a multi-valued attribute. The key is ISBN. Entity type STUDENT(SSN,fname,lname,address,telephone) The key is SSN. Relation type BORROW(SSN,ISBN,date-of-borrow,no-ofrenewal,fine) The BORROW relation type is one-to-many. Participation of BOOK is partial Participation of STUDENT is partial