UML Advanced

  1. SuperClass
  1. Fuente. KULeuvenX: UMLx UML Class Diagrams for Software Engineering (Copia Textual – Literature Review).
    1. Superclass/Subclass/inheritance
    2. Generalisation sets
    3. Constraints on generalisation/specialisation
    4. Reading a diagram with Inheritance (Inherited Associations)
    5. AssociationClass


In this presentation we’ll explain the concept of generalization and specialization. This concept is actually a UML association construct. It relates to inheritance, fundamental concept of object oriented programming. This concept states that a class can inherit attributes and operations from a parent class.

In this example We have the general concept of account and two more specific concepts of checking account and saving account that inherit the characteristics of the more general concept of account. The more general concept is called generalization, superclass or supertype and the more specific concept is called the specialization, subclass or subtype. Graphically, the generalization/specialization association is drawn as a line connecting the super type to the subtype, and which is adorned with a triangle pointing towards the super type.

The principle of inheritance states that a subtype inherits the features of the super type. So, in this case, the superclass ‘account’, has defined two attributes: ‘IBAN number’ and ‘balance’. Those attributes will be inherited by checking account. So, also checking account will have an IBAN number and a balance. In addition, the checking account can extend what it inherited from account with its own attributes. And, in this case, checking account defines an additional attribute: ‘credit card’. Likewise, the savings account inherits from account that it has an IBAN number and a balance. But, it extends this with four attributes relating to a savings plan…Here, we graphically represent how a generalization/specialization is similar to a superset/subset relation.

Generalization sets.

Sometimes it is difficult to decide how to define the specialisations of a super type because different partitionings are possible. Take the example of vehicles. If you look at the transportation medium, you would have a partition like this:

This examples illustrates how in certain cases a single concept can be partitioned in two different ways. In UML, the concept of generalization set provides a way to group Specializations into orthogonal dimensions. Each group is represented by a generalization set. There are three different notations to represent generalisation sets.

First, by putting a name next to the Generalization relationship lines, that name designates a GeneralizationSet to which the Specialization belongs.

Second, two or more lines can be drawn to the same arrowhead and labelled by a single

generalization set name. This is called the “shared target” style.

With either of these two notations, if there are no labels on the Generalization arrows it cannot be determined from the diagram whether there are any generalization sets in the model.

Finally, a generalization set may be designated by drawing a dashed line across those lines with separate arrowheads that are meant to be part of the same set. Here, the generalization set is labelled with a single name, instead of each line labelled.

Constraints on Generalization/Specialization.

The concept of generalization/specialization comes with constraints and there are two types of constraints to consider. The first is whether the specialization is complete or incomplete. The question to ask is whether the subclasses cover all the elements of the superclass. Let’s consider an example where the superclass are the pet animals. That is the general concept. And you have three subtypes or specialized concepts namely cats, dogs and horses. The question to ask is: are there other pet animals than cats, dogs and horses? If yes, then the specialization of the subclasses is an incomplete specialization of the general concept. If there are no other pet animals than cats, dogs and horses, then the specialization is complete.

The other constraint to consider is whether or not subclasses are disjoint or overlapping. The question to ask here is: are there overlapping subclasses? For our example: Are there animals that can be dog and cat at the same time? Or cat and horse at the same time? Or dog and horse at the same time? If that’s not the case, then your classes are disjoint. If it is possible that an animal is a cat and a dog at the same time or a cat and a horse or a dog and a horse at the same time, then you have overlapping subclasses. If you don’t specify anything then by default it is assumed that your subclasses are disjoint.

The way to write these constraints down is simply by including the words that indicate the correct constraint between brackets next to the triangle.

Reading a diagram with inheritance (Inherited associations).

The general rule is that you have to read inheritance as an OR. So if you read the association between customer and account in this direction, the way to read the diagram is as follows.

A customer can have zero to many accounts and these accounts are either checking accounts or savings account because the specialization is complete and disjoint.

In the other direction, from account to customer, the way to read the diagram is that each account, be it the checking account or savings account, must have exactly one customer as an owner. In other words, checking account and savings account inherit from account that they belong to exactly one owner.

And here’s another example. Reading from student to course means that a student can follow zero to many courses and that these courses are advanced or intermediate or both, or just courses. Because inheritance is overlapping and incomplete.

In the other direction, reading from course to student we can see that each course is followed by zero to many students. And, because of the inheritance relationship, the advanced course and intermediate course inherit from course the fact that they are followed by zero to many students. So each course, advanced or intermediate, or just course is followed by zero to many students.

In the case of multiple inheritance trees in a single diagram, extra care is required. Consider this example. The association between Flight and Airplane seems to read as a general rule “Each flight has to be done with an airplane, and each Airplane can serve for zero to many flights.” While this seems a logical interpretation, the actual meaning is different.

The blue part of the model should be read as “A Flight, which could be either a cargo flight or a passenger flight” Similarly, the orange part of the model should be read as “An airplane, which could either be a passenger airplane or a cargo airplane.” In combination with the association, the true meaning of the model is: A flight of any kind, be it cargo or passenger flight, is always done with one airplane of any kind, be it a passenger or a cargo plane. So if you want to capture that passenger flights can only be done with passenger planes, and that cargo flights can only be done with cargo planes, then you need to model this at the level of the specialisations. And obviously, the association at the level of the super type then needs to be removed.

And what if cargo flights can be done with any kind of planes? Then the association connects “Cargo Flight” to the superclass “Airplane” rather than to the subclass. And the model looks like this.


Let’s take a look again at the example of projects, products and suppliers. Suppose that prior to buying a product for a project, you need to be able to look up the different prices different suppliers ask for a product. So, next to keeping track of which product has been sourced from which supplier for a project, you also want to know which supplier offers which product.

So, where would you keep the price attribute? Would you model this as an attribute of supplier? Definitively not. Is it an attribute of product? Since each supplier has its own price for a given product, you can’t model it as an attribute of product either.

The price is rather an attribute of the combination of supplier and product. It’s therefore an attribute of the association between supplier and product. As a result, the association exhibits the characteristics of a class. In UML this is capture by the concept of associationclass.

An association class is both an association and a class at the same time. The association class is therefore named like a Class, and it can have attributes and operations. In this example, a good name for the association class is “ProductOffer”. And next to the price, this association class could also contain other attributes such as shipping conditions, average shipping time, etcetera.

In the example of the projects, products and suppliers, also the other associations may be converted to association classes, depending on required attributes. For example, the association that models which products are required by which projects, may be turned into an association class ProductRequirement capturing the required quantity, the maximum price that should be paid and the deadline by which products should be available.

The use of the concept of association class adds complexity to a model, in the sense that it is an extra symbol one needs to understand. To a large extent, a model using only classes and associations can express the same thing. For example, the product offer can also be modelled as a conventional class, related to a single supplier and a single product.


Larry Francis Obando – Technical Specialist

Escuela de Ingeniería Eléctrica de la Universidad Central de Venezuela, CCs.

Escuela de Ingeniería Electrónica de la Universidad Simón Bolívar, Valle de Sartenejas.

Escuela de Turismo de la Universidad Simón Bolívar, Núcleo Litoral.

Contact: Ecuador (Quito, Cuenca, Guayaquil)

WhatsApp: 00593984950376


Copywriting, Content Marketing, Tesis, Monografías, Paper Académicos, White Papers (Español – Inglés)

Use Case Diagram – Basics

Descargar PDF: Use Case Diagram – Basics

  1. Use Case Definition
  1. Fuente. Object-Oriented Software Engineer (Copia Textual – Literature Review).
    1. 2.3.1 Systems, Models, and Views
    2. 2.4.1 Use Case Diagrams. Use cases and actors


Definition of Systems, Models and Views

A system is an organized set of communicating parts. We focus here on engineered systems, which are designed for a specific purpose, as opposed to natural systems, such as a planetary system, whose ultimate purpose we may not know. A car, composed of four wheels, a chassis, a body, and an engine, is designed to transport people. A watch, composed of a battery, a circuit, wheels, and hands, is designed to measure time. A payroll system, composed of a mainframe computer, printers, disks, software, and the payroll staff, is designed to issue salary checks for employees of a company. Parts of a system can in turn be considered as simpler systems called subsystems. The engine of a car, composed of cylinders, pistons, an injection module, and many other parts, is a subsystem of the car. Similarly, the integrated circuit of a watch and the mainframe computer of the payroll system are subsystems. This subsystem decomposition can be recursively applied to subsystems. Objects represent the end of this recursion, when each piece is simple enough that we can fully comprehend it without further decomposition.

Many systems are made of numerous subsystems interconnected in complicated ways, often so complex that no single developer can manage its entirety. Modeling is a means for dealing with this complexity. Complex systems are generally described by more than one model, each focusing on a different aspect or level of accuracy. Modeling means constructing an abstraction of a system that focuses on interesting aspects and ignores irrelevant details… Modeling allows us to deal with complexity through a divide-and-conquer approach: For each type of problem we want to solve (e.g., testing aerodynamic properties, training pilots), we build a model that only focuses on the issues relevant to the problem… Modeling also helps us deal with complexity by enabling us to incrementally refine simple models into more detailed ones that are closer to reality. In software engineering, as in all engineering disciplines, the model usually precedes the system. During analysis, we first build a model of the environment and of the common functionality that the system must provide, at a level that is understandable by the client. Then we refine this model, adding more details about the forms that the system should display, the layout of the user interface, and the response of the system to exceptional cases. The set of all models built during development is called the system model. If we did not use models, but instead started coding the system right away, we would have to specify all the details of the user interface before the client could provide us with feedback. Thus we would lose much time and resources when the client then introduces changes.

Use Case Function

Use cases are used during requirements elicitation and analysis to represent the functionality of the system. Use cases focus on the behavior of the system from an external point of view. A use case describes a function provided by the system that yields a visible result for an actor. An actor describes any entity that interacts with the system (e.g., a user, another system, the system’s physical environment). The identification of actors and use cases results in the definition of the boundary of the system, that is, in differentiating the tasks accomplished by the system and the tasks accomplished by its environment. The actors are outside the boundary of the system, whereas the use cases are inside the boundary of the system.

Use cases and actors

Actors are external entities that interact with the system. Examples of actors include a user role (e.g., a system administrator, a bank customer, a bank teller) or another system (e.g., a central database, a fabrication line). Actors have unique names and descriptions. Use cases describe the behavior of the system as seen from an actor’s point of view. Behavior described by use cases is also called external behavior. A use case describes a function provided by the system as a set of events that yields a visible result for the actors. Actors initiate a use case to access system functionality. The use case can then initiate other use cases and gather more information from the actors. When actors and use cases exchange information, they are said to communicate. We will see later that we represent these exchanges with communication relationships.

For this example, in an Accident Management System, field officers (such as a police officer or a firefighter) have access to a wireless computer that enables them to interact with a dispatcher. The dispatcher in turn can visualize the current status of all its resources, such as police cars or trucks, on a computer screen and dispatch a resource by issuing commands from a workstation. In this example, field officer and dispatcher can be modeled as actors. Figure 2-13 depicts the actor FieldOfficer who invokes the use case ReportEmergency to notify the actor Dispatcher of a new emergency. As a response, the Dispatcher invokes the OpenIncident use case to create an incident report and initiate the incident handling. The Dispatcher enters preliminary information from the FieldOfficer in the incident database (FRIEND) and orders additional units to the scene with the AllocateResources use case. For the textual description of a use case, we use a template composed of six fields (see Figure 2-14) adapted from [Constantine & Lockwood, 2001]:

• The name of the use case is unique across the system so that developers can unambiguously refer to the use case.

• Participating actors are actors interacting with the use case.

• Entry conditions describe the conditions that need to be satisfied before the use case is initiated.

We organize the steps in the flow of events in two columns, the left column representing steps accomplished by the actor, the right column representing steps accomplished by the system. Each pair of actor–system steps represents an interaction.

Use cases are written in natural language. This enables developers to use them for communicating with the client and the users, who generally do not have an extensive knowledge of software engineering notations. The use of natural language also enables participants from other disciplines to understand the requirements of the system. The use of the natural language allows developers to capture things, in particular special requirements, that cannot easily be captured in diagrams.

Use case diagrams can include four types of relationships: communication, inclusion, extension, and inheritance. We describe these relationships in detail next. Communication relationships: Actors and use cases communicate when information is exchanged between them. Communication relationships are depicted by a solid line between the actor and use case symbol… Communication relationships between actors and use cases can be used to denote access to functionality. In the case of our example, a FieldOfficer and a Dispatcher are provided with different interfaces to the system and have access to different functionality. Include relationships: When describing a complex system, its use case model can become quite complex and can contain redundancy. We reduce the complexity of the model by identifying commonalities in different use cases. For example, assume that the Dispatcher can press at any time a key to access a street map. This can be modeled by a use case ViewMap that is included by the use cases OpenIncident and AllocateResources. Extend relationships: are an alternate means for reducing complexity in the use case model. A use case can extend another use case by adding events. An inheritance relationship is a third mechanism for reducing the complexity of a model. One use case can specialize another more general one by adding more detail.

Los libros de donde extraje imágenes, ecuaciones e información, que recomiendo para iniciar este estudio, son los siguientes:

Object Oriented Software Engineering, Bernd Bruegge & Allen H. Dutoit


Larry Francis Obando – TSU

Escuela de Ingeniería Eléctrica de la Universidad Central de Venezuela, Caracas.

Escuela de Ingeniería Electrónica de la Universidad Simón Bolívar, Valle de Sartenejas.

Escuela de Turismo de la Universidad Simón Bolívar, Núcleo Litoral.


WhatsApp: 00593984950376


Copywriting, Content Marketing.

UML Introduction

Download PDF: UML Introduction

  1. Class Definition
  1. Fuente. KULeuvenX: UMLx UML Class Diagrams for Software Engineering (Copia Textual – Literature Review).
    1. UML Class Diagrams for Software Engineering
    2. Welcome
    3. Modelling languages
    4. A class is an abstraction
    5. Why are class definitions important?

The Unified Modelling Language was first proposed as a standard in 1996. Since then, UML has become the most widely used language to draw up plans for software systems. It is used by software engineers, requirements engineers, and business analysts. Knowledge of UML has become a much sought-after skill in software development and engineering. Some of the today’s top jobs require UML knowledge. Think about business analysts, enterprise architects, but also developers, technical consultants, and solutions architects…In this course we’ll focus on UML Class diagrams and their use for conceptual data modeling… we look at the essential aspects of conceptual domain modeling.

“” defines a model as “A systematic description of an object or phenomenon that shares important characteristics with the object or phenomenon.” So, models present a systematic and most often simplified description of what they represent.

Each business is unique and will, therefore, yield a different domain model, adapted to its specific needs. UML class diagrams is the prime modeling instrument used to map out specific business domains. Creating a UML class diagram for a business will enable to pinpoint what makes this business unique and will provide a good starting point for developing an information system.

Creating a domain model allows a deeper understanding of that domain. And, this deeper understanding is crucial for creating software systems that can adapt to the ever changing requirements of their users.,,So, the lesson to remember is that you need to understand the core concept of a business. The domain model that captures these core concepts need to be at the heart of your information system to ensure adaptability.

Class definition

In computer terms, a concept that groups objects with similar characteristics is called a ‘Class’… in order to be able to handle the objects in the universe of an organisation, these objects need to be categorized into concepts. Example: University has the following classes: Student and Study Program

Modeling is abstracting, it means that you make the transition from level 0 to level 1. You go from the instances to the definition of the concepts. On the other hand when you want to validate the model you have to do the reverse. So you will take the model and reason on an example.

A ‘Class’ has two functions.

  1. On the one hand, the class will be the template or a model for a group of real world objects that are similar. It defines a type of instances and therefore we also call it an object type. This is called the “intent” of the class; it is the definition of the concept that defines class membership. The template will capture characteristics that are relevant about the objects in the class. The class definition will omit the irrelevant aspects.
  2. At the same time, the class represents a collection of objects that conform to its intent. This is called the ‘extent’ of the class. Notice that classes can represent both tangible and intangible objects.
  1. Attributes and Data Type
  1. Fuente. KULeuvenX: UMLx UML Class Diagrams for Software Engineering (Copia Textual – Literature Review).
    1. Attributes and Data types
    2. Respresenting Instances in MSAccess or MSExcel

Attributes / Data Types

The characteristics that we want to information about for every individual object in a class, are called the ‘attributes’ of that class. The list of attributes for a class is obviously specific for a particular domain.

For a university, the mentioned attributes in the figure are relevant. Each object has its own values for the attributes: attribute values are specific for the instance they belong to. Moreover each attribute has a data type. Examples of data types are integer, float, text, string, and boolean. The data type constraints the values that can be given for a particular attribute.

When an instance is given a value for an attribute, this value has to follow the constraints implied by the data type. By the fact that the data types constrain the permissible values for an attribute, they also define the permissible operations. In a UML class diagram the attributes and their data types are written in a box below the class’s name,

  1. Associations
    1. Fuente. KULeuvenX: UMLx UML Class Diagrams for Software Engineering (Copia Textual – Literature Review).
      1. Association Basics
      2. Unary association
      3. Ternary association
      4. Aggregation


Following the principle of abstraction means that similar relationships or links between instances at level 0 need to be abstracted into a higher level concept at level 1. Such abstract concept is called an association. An Association is therefore a level 1 concept that relates classes and that represents a collection of links between the objects of those classes. It represents a type of link with specific characteristics. The first of these characteristics is whether it is optional or mandatory to have a link with other objects. So for example is it optional or mandatory for a student to be registered for a program? The other important characteristic is the maximum number of objects we will find at the other side of the association. In this example maximum number of programs a student can be subscribed to at a any single point in time? The combination of the minimum and maximum is represented as an interval: minimum .. maximum. The minimum can be 0 or 1, and the maximum can be 1 or many and the many is represented as a star:

Let’s look at the following association example as we must remember the rule Modelling is abstracting, it means that you make the transition from level 0 to level 1. You go from the instances to the definition of the concepts. On the other hand when you want to validate the model you have to do the reverse. So you will take the model and reason on an example:

An association can be read in two directions. here: from the student to the program, and from the program to the student. These individual directions are called the ‘roles’ of the association. In this example, the role from the student to the program has been named ‘Registered for’ and the role name is put next to the destination class of the role, so next to the class Program. In the other direction a program has registered students, so we put the role name ‘registered students’ next to the class Student.

When you have two classes in a UML class diagram you can have two different associations between those two same classes.

In some cases an association connects a class to itself. This is called a unary association. An example is when people are related to each other.

Sometimes binary and unary associations are not able to correctly capture the relationships between objects. Consider the following example. Assume we have Suppliers, Products and Projects, and we want to capture which supplier supplied what construction material for which construction project.

So the combination of the three tables just doesn’t give you enough information to answer that question. The only way to correctly capture which supplier supplied which product for which project, is to use a three-way association. like this, also called a ternary association.

The interpretation of cardinality constraints for a ternary association requires however some care. If you put a zero to many cardinality next to supplier, what does it mean? Does it mean that each product and each project each can have zero to many suppliers? This is what the UML manual says about the interpretation of multiplicities: Using the same example:

So, to determine the multiplicity on the side of supplier, you take a pair of one project and one product. And then you look at the set of suppliers that match with this (project, product) pair. The (project, product) pair could have been sourced from no, one or several suppliers. If the product has not been used in that project, you won’t find any supplier. If it has been supplied by only one supplier, then you’ll find one supplier. If the product has been sourced from two or more, then you’ll find many suppliers. You have to do this for all project-product pairs to determine the general rule that is applicable. If your model allows to distinguish, for example, different orders at the same supplier, then a (project, product) pair may match several times with the same supplier. In such case additional identifying attributes will be required to distinguish the different links from each other. We’ll come back to this when discussing the concept of AssociationClass. So for this example, in order to determine what to write next to the “supplied_by” role, we need to consider all project, product pairs, and see how many suppliers we find. The role will most likely not be mandatory: some products will not be used by all projects. For those pairs, we won’t find any suppliers. So the minimum is 0. For the maximum, it depends on the rules. If within a project, a product always has to be supplied by the same supplier, then the maximum is one. If you can source a product from many suppliers within the context of a single project, it may be many.

Some associations convey a meaning of a “part of” relation or composition. For example, this course is “composed of” a number of modules, an orderline is “part of” an order, a parcel is “composed of” items, and so on. In the UML, you can adorn the association end at the side of the “whole” with a diamond to clarify that the association has a “whole-part” meaning.

The diamond comes with two flavours: a white diamond representing a “shared” aggregation and a black. The white diamond represents a shared aggregation. Intuitively, this means that the parts can be shared by different wholes. If course modules can be shared across courses, then this would be an example of a shared aggregation.

The black diamond represents a composite aggregation, which is intended as a stronger form of ownership, meaning that the parts are owned by only one whole. The order lines being part of an order, and the items being part of a parcel are examples of a composite aggregation.

So the advice for good modelling is to use conventional binary associations with appropriate role names to avoid confusion in a model reader’s mind.

  1. Implicit Associations – Navigation and Parallel Paths
    1. Fuente. KULeuvenX: UMLx UML Class Diagrams for Software Engineering (Copia Textual – Literature Review).
      1. Derived/implicit association.
      2. Navigation & information need satisfaction
      3. Parallel paths

Implicit Associations

 The fact that you can navigate over several consecutive associations implies that there are implicit associations between classes. In this example, there is an implicit association from the student to faculty that represents to which faculty a student belongs and which students a faculty has.

So, we have an association between students and faculty that represents which faculty a student belongs to and which students a faculty has. Note that such implicit association is not drawn on the diagram. But you have to be aware of its existence while reading a diagram.


By connecting multiple associations in a chain we can navigate from one end of the model to another. This navigability of associations determines the navigability of information in an information system: when applications are built based on a UML class diagram the associations in that diagram will define how in an application a user can navigate from one piece of information to another. As a result of this, the navigation paths will also impact the possibilities to satisfy information needs.

Let’s look at an example. I have logged into the ERP system of my university and this means that in the class professor one instance has been selected, namely me. Now what I want to do in the ERP application is to find the students I’m teaching to. In order to navigate to my students the first thing I will have to do is to navigate to my courses. In the ERP-system I have a button ‘Search via courses’. This corresponds to navigating in the UML diagram from the professor to the class courses:

Now, I will select one course: I choose for the first one, the “business information systems” course. By clicking the ‘show’ button, I will navigate to the students who follow that course. And what do I see? The application offers me a list of students but not just a flat list. It will group the students according to the program these students are subscribed to. At the right appears a version which returns a wrong answer to the question the professor asked.

So, we see that clearly the non-availability of the grey link going directly from course to students hampers the satisfaction of the need to know how many students are subscribed in the course business information systems. So, wrong associations and missing associations are detrimental to information need satisfaction.

Parallel Path

An important thing we have to take into account when reading a UML class diagram, is that –based on our domain knowledge- we may assume that certain ‘intuitive’ constraints are imposed, but which in fact are not part of the UML class diagram. This is particularly the case when a UML class diagram contains parallel paths to navigate from one class to another.

For example, here we can see that we can navigate along the blue path from course to students. This gives us the students that are subscribed to a course. We can also navigate along the green path. In the first leg of this path, we navigate from course to program and we find all the programs the course is a part of. In the second leg, we navigate from program to student, and so we find all the students of that program. So, this green path gives us the students that are subscribed to a program the course is part of. Clearly, navigating along the blue path will give you another set of students than when navigating along the green path.

Let’s illustrate this with a concrete Level 0 example. Here you find 3 students, 3 programs and 6 courses. The orange lines indicate the relationships between students and courses: which student has taken which course in his or her individual study program. The purple lines show the relationships between courses and programs: which course is part of what program. And the black lines tell which student is registered for what program. Let us now start from the course Object Oriented Programming. Navigating along the blue path, means navigating from the course to the students taking that course. We find Maria Haven. Navigating along the green path, means first navigating to the programs this course is part of. We find the bachelor of Computer Science. We then navigate to the students registered for this program and We find Peter Martens and Elisa Smith. So the two paths yield a different set of students.

This paper continues in UML ADVANCED

Copia textual by Ing. Larry Obando


WhatsApp: 00593984950376


Copywriting, Content Marketing.