Uml

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 EMPLOYEE’s Job

• MANAGER– EMPLOYEEs who are managers

• SALARIED_EMPLOYEE, HOURLY_EMPLOYEE– Based on the EMPLOYEE’s 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 can’t have a customer who hasn’t 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-of-pub,{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-of-renewal,fine)

• The BORROW relation type is one-to-many. Participation of BOOK is partial Participation of STUDENT is partial