Computer Science, UML

UML – Analysis activities: From Use Case to Class Diagram

Computer science and programming

UML Analysis activities – From Use Case to Class Diagram

Miércoles 29 noviembre, 10:16 am


Object-Oriented Software Engineering

    1. Analysis p 173
    2. Identifying Associations pp 190
    3. Identifying Aggregates pp 192
    4. Identifying Attributes pp 193

Identifying Associations

In this section, we discuss the use of class diagrams for representing associations among objects. An association shows a relationship between two or more classes. For example, a FieldOfficer writes an EmergencyReport (see Figure 5-13).

Associations have several properties:

  • A name to describe the association between the two classes (e.g., Writes in Figure 5-13). Association names are optional and need not be unique globally.
  • A role at each end, identifying the function of each class with respect to the associations (e.g., author is the role played by FieldOfficer in the Writes association).
  • A multiplicity at each end, identifying the possible number of instances (e.g., *
  • indicates a FieldOfficer may write zero or more EmergencyReports, whereas 1
  • indicates that each EmergencyReport has exactly one FieldOfficer as author).

Initially, the associations between entity objects are the most important, as they reveal more information about the application domain. According to Abbott’s heuristics (see Table 5-1), associations can be identified by examining verbs and verb phrases denoting a state (e.g., has, is part of, manages, reports to, is triggered by, is contained in, talks to, includes). Every association should be named, and roles should be assigned to each end.

The object model will initially include too many associations if developers include all associations identified after examining verb phrases. In Figure 5-14, for example, we identify two relationships: the first between an Incident and the EmergencyReport that triggered its creation; the second between the Incident and the reporting FieldOfficer. Given that the EmergencyReport and FieldOfficer already have an association modeling authorship, the association between Incident and FieldOfficer is not necessary. Adding unnecessary associations complicates the model, leading to incomprehensible models and redundant information.

Most entity objects have an identifying characteristic used by the actors to access them. FieldOfficers and Dispatchers have a badge number. Incidents and Reports are assigned numbers and are archived by date. Once the analysis model includes most classes and associations, the developers should go through each class and check how it is identified by the actors and in which context.

Identifying Aggregates

Aggregations are special types of associations denoting a whole–part relationship. For example, a FireStation consists of a number of FireFighters, FireEngines, Ambulances, and a LeadCar. A State is composed of a number of Counties that are, in turn, composed of a number of Townships (Figure 5-15). An aggregation is shown as a association with a diamond on the side of the whole part.

There are two types of aggregation, composition and shared. A solid diamond denotes composition. A composition aggregation indicates that the existence of the parts depends on the whole. For example, a County is always part of exactly one State, a Township is always part of a County. As political boundaries do not change often, a Township will not be part of or shared with another County.

A hollow diamond denotes a shared aggregation relationship, indicating the whole and the part can exist independently. For example, although a FireEngine is part of at most one FireStation at the time, it can be reassigned to a different FireStation during its life time. Aggregation associations are used in the analysis model to denote whole–part concepts. Aggregation associations add information to the analysis model about how containment concepts in the application domain can be organized in a hierarchy or in a directed graph. Aggregations are often used in the user interface to help the user browse through many instances.

If you are not sure that the association you are describing is a whole–part concept, it is better to model it as a one-to-many association, and revisit it later when you have a better understanding of the application domain.

Identifying Attributes

Attributes are properties of individual objects. For example, an EmergencyReport, as described in Table 5-2, has an emergency type, a location, and a description property (see Figure 5-16).

These are entered by a FieldOfficer when she reports an emergency and are subsequently tracked by the system. When identifying properties of objects, only the attributes relevant to the system should be considered.

Properties that are represented by objects are not attributes. For example, every EmergencyReport has an author that is represented by an association to the FieldOfficer class. Developers should identify as many associations as possible before identifying attributes to avoid confusing attributes and objects. Attributes have:

  • A name identifying them within an object. For example, an EmergencyReport may have a reportType attribute and an emergencyType attribute. The reportType describes the kind of report being filed (e.g., initial report, request for resource, final report). The emergencyType describes the type of emergency (e.g., fire, traffic, other). To avoid confusion, these attributes should not both be called type.
  • A brief description.
  • A type describing the legal values it can take. For example, the description attribute of an EmergencyReport is a string. The emergencyType attribute is an enumeration that can take one of three values: fire, traffic, other. Attribute types are based on predefined basic types in UML

Attributes can be identified using Abbott’s heuristics (see Table 5-1). In particular, a noun

phrase followed by a possessive phrase (e.g., the description of an emergency) or an adjective phrase (e.g., the emergency description) should be examined. In the case of entity objects, any property that must be stored by the system is a candidate attribute.

Note that attributes represent the least stable part of the object model. Often, attributes are discovered or added late in the development when the system is evaluated by the users. Unless the added attributes are associated with additional functionality, the added attributes do not entail major changes in the object (and system) structure. For these reasons, the developers need not spend excessive resources in identifying and detailing attributes that represent less important aspects of the system.

Literature Review by: Larry Francis Obando – Technical Specialist

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.

Contact: Ecuador (Quito, Guayaquil, Cuenca)

WhatsApp: 00593984950376


Computer Science, UML

UML Analysis – Basics

Computer science and programming

Jueves 09 noviembre, 09:44 am


Object-Oriented Software Engineering

    1. Analysis p 173
    2. Overview of Analysis
    3. Analysis Concepts pp 176
    4. Analysis Activities pp 179


Analysis results in a model of the system that aims to be correct, complete, consistent, and unambiguous. Developers formalize the requirements specification produced during requirements elicitation and examine in more detail boundary conditions and exceptional cases. Developers validate, correct and clarify the requirements specification if any errors or ambiguities are found. The client and the user are usually involved in this activity when the requirements specification must be changed and when additional information must be gathered. In object-oriented analysis, developers build a model describing the application domain.

Formalization helps identify areas of ambiguity as well as inconsistencies and omissions in a requirements specification. Once developers identify problems with the specification, the address them by eliciting more information from the users and the client. Requirements elicitation and analysis are iterative and incremental activities that occur concurrently.

An Overview of Analysis

Analysis focuses on producing a model of the system, called the analysis model, which is correct, complete, consistent, and verifiable. Analysis is different from requirements elicitation in that developers focus on structuring and formalizing the requirements elicited from users (Figure 5-2).

This formalization leads to new insights and the discovery of errors in the requirements. As the analysis model may not be understandable to the users and the client, developers need to update the requirements specification to reflect insights gained during analysis, then review the changes with the client and the users. In the end, the requirements, however large, should be understandable by the client and the users.

The analysis model is composed of three individual models: the functional model, represented by use cases and scenarios, the analysis object model, represented by class and object diagrams, and the dynamic model, represented by state machine and sequence diagrams (Figure 5-3).

In the previous chapter, we described how to elicit requirements from the users and describe them as use cases and scenarios. In this chapter, we describe how to refine the functional model and derive the object and the dynamic model. This leads to a more precise and complete specification as details are added to the analysis model.

Analysis Object Model

The analysis model represents the system under development from the user’s point of view. The analysis object model is a part of the analysis model and focuses on the individual concepts that are manipulated by the system, their properties and their relationships. The analysis object model, depicted with UML class diagrams, includes classes, attributes, and operations. The analysis object model is a visual dictionary of the main concepts visible to the user.

Dynamic Model

The dynamic model focuses on the behavior of the system. The dynamic model is depicted with sequence diagrams and with state machines. Sequence diagrams represent the interactions among a set of objects during a single use case. State machines represent the behavior of a single object (or a group of very tightly coupled objects). The dynamic model serves to assign responsibilities to individual classes and, in the process, to identify new classes, associations, and attributes to be added to the analysis object model.

Entity, Boundary, and Control Objects

The analysis object model consists of entity, boundary, and control objects [Jacobson et al., 1999]. Entity objects represent the persistent information tracked by the system. Boundary objects represent the interactions between the actors and the system. Control objects are in charge of realizing use cases. In the 2Bwatch example, Year, Month, and Day are entity objects; Button and LCDDisplay are boundary objects; ChangeDateControl is a control object that represents the activity of changing the date by pressing combinations of buttons.Modeling the system with entity, boundary, and control objects provides developers with simple heuristics to distinguish different, but related concepts.

To distinguish between different types of objects, UML provides the stereotype mechanism to enable the developer to attach such meta-information to modeling elements.

For example, in Figure 5-5, we attach the «control» stereotype to the ChangeDateControl object. In addition to stereotypes, we may also use naming conventions for clarity and recommend distinguishing the three different types of objects on a syntactical basis: control objects may have the suffix Control appended to their name; boundary objects may be named to clearly denote an interface feature (e.g., by including the suffix Form, Button, Display, or Boundary); entity objects usually do not have any suffix appended to their name.

Generalization and Specialization

Modeling with UML, inheritance enables us to organize concepts into hierarchies. At the top of the hierarchy is a general concept, and at the bottom of the hierarchy are the most specialized concepts.

Generalization is the modeling activity that identifies abstract concepts from lower-level ones.

Specialization is the activity that identifies more specific concepts from a high-level one.

In some instances, modelers call inheritance relationships generalization-specialization relationships. In this book, we use the term “inheritance” to denote the relationship and the terms “generalization” and “specialization” to denote the activities that find inheritance relationships.

Analysis Activities: From Use Cases to Objects

In this section, we describe the activities that transform the use cases and scenarios produced during requirements elicitation into an analysis model. Analysis activities include:

  1. Identifying Entity Objects
  2. Identifying Boundary Objects
  3. Identifying Control Objects
  4. Mapping Use Cases to Objects with Sequence Diagrams
  5. Modeling Interactions among Objects with CRC Cards
  6. Identifying Associations
  7. Identifying Aggregates
  8. Identifying Attributes
  9. Modeling State-Dependent Behavior of Individual Objects
  10. Modeling Inheritance Relationships
  11. Reviewing the Analysis Model

Identifying Entity Objects

Participating objects form the basis of the analysis model. Natural language analysis is an intuitive set of heuristics for identifying objects, attributes, and associations from a requirements specification. Abbott’s heuristics maps parts of speech (e.g., nouns, having verbs, being verbs, adjectives) to model components (e.g., objects, operations, inheritance relationships, classes). Table 5-1 provides examples of such mappings by examining the ReportEmergency use case:

The following heuristics can be used in conjunction with Abbott’s heuristics:

As it was mentioned before, Entity Objects represent the persistent information tracked by the system. For entity objects we recommend always to start with the names used by end users and application domain specialists. Describing objects, even briefly, allows developers to clarify the concepts they use and avoid misunderstandings (e.g., using one object for two different but related concepts).

For example, after a first examination of the ReportEmergency use case (Figure 5-7), we use application domain knowledge and interviews with the users to identify the objects Dispatcher, EmergencyReport, FieldOfficer, and Incident. Note that the EmergencyReport object is not mentioned explicitly by name in the ReportEmergency use case. Step 4 of the use case refers to the emergency report as the “information submitted by the FieldOfficer.” After review with the client, we discover that this information is usually referred to as the “emergency report” and decide to name the corresponding object EmergencyReport.

The definition of entity objects leads to the initial analysis model described in Table 5-2.

Identifying Boundary Objects

Boundary objects represent the system interface with the actors. In each use case, each actor interacts with at least one boundary object. The boundary object collects the information from the actor and translates it into a form that can be used by both entity and control objects.

We find the boundary objects of Table 5-3 by examining the ReportEmergency use case.

We have made progress toward describing the system. We now have included the interface between the actor and the system. We are, however, still missing some significant pieces of the description, such as the order in which the interactions between the actors and the system occur. In the next section, we describe the identification of control objects.

Identifying Control Objects

Control objects are responsible for coordinating boundary and entity objects. Control objects usually do not have a concrete counterpart in the real world. Often a close relationship exists between a use case and a control object; a control object is usually created at the beginning of a use case and ceases to exist at its end. It is responsible for collecting information from the boundary objects and dispatching it to entity objects. For example, control objects describe the behavior associated with the sequencing of forms, undo and history queues, and dispatching information in a distributed system.

We model the control flow of the ReportEmergency use case with a control object for each actor: ReportEmergencyControl for the FieldOfficer and ManageEmergency-Control for the Dispatcher, respectively (Table 5-4).

The decision to model the control flow of the ReportEmergency use case with two control objects stems from the knowledge that the FieldOfficerStation and the DispatcherStation are actually two subsystems communicating over an asynchronous link.

Literature Review by: Larry Francis Obando – Technical Specialist

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.

Contact: Caracas, Valladolid, Quito, Guayaquil, Jaén, Villafranca de Ordizia

WhatsApp: +34633129287



Computer Science, UML

UML – Requirements Elicitation

The client, the developers, and the users identify a problem area and define a system that addresses the problem. Such a definition is called a requirements specification and serves as a contract between the client and the developers…The requirements specification is structured and formalized during analysis to produce an analysis model…(August 7, 2017).

The first step of requirements elicitation is the identification of actors. This serves both to define the boundaries of the system and to find all the perspectives from which the developers need to consider the system…(September 18, 2017).

Actividad WBS (Overview)


  1. Object-Oriented Software Engineering
    1. Requirement Elicitation concepts – Functional requirements
    2. Requirement Elicitation activities -Identifying actors – Identifying scenarios – Identifying Use Cases – Identifying relationships between actors and Use Cases – Identifying Initial Analysis Objects -Identifying Non-functional requirements – Documenting Requirements Elicitation- (p 152).
A requirement is a feature that the system must have or a constraint that it must satisfy to be accepted by the client. Requirements engineering aims at defining the requirements of the system under construction. Requirements engineering includes two main activities; Requirements Elicitation, which results in the specification of the system that the client understands, and analysis, which results in an analysis model that the developers can unambiguously interpret. Requirements elicitation is the more challenging of the two because it requires the collaboration of several groups of participants with different backgrounds. On the one hand, the client and the users are experts in their domain and have a general idea of what the system should do, but they often have little experience in software development. On the other hand, the developers have experience in building systems, but often have little knowledge of the everyday environment of the users.

Requirement elicitation


A requirement is a feature that the system must have or a constraint that it must satisfy to be accepted by the client. Requirements engineering aims at defining the requirements of the system under construction. Requirements engineering includes two main activities; Requirements Elicitation, which results in the specification of the system that the client understands, and analysis, which results in an analysis model that the developers can unambiguously interpret. Requirements elicitation is the more challenging of the two because it requires the collaboration of several groups of participants with different backgrounds. On the one hand, the client and the users are experts in their domain and have a general idea of what the system should do, but they often have little experience in software development. On the other hand, the developers have experience in building systems, but often have little knowledge of the everyday environment of the users.

Scenarios and use cases provide tools for bridging this gap. A scenario describes an example of system use in terms of a series of interactions between the user and the system. A use case is an abstraction that describes a class of scenarios. Both scenarios and use cases are written in natural language, a form that is understandable to the user. In this chapter, we focus on scenario-based requirements elicitation.,,Requirements elicitation is about communication among developers, clients, and users to define a new system…Requirements elicitation methods aim at improving communication among developers, clients, and users…Developers construct a model of the application domain by observing users in their environment. Developers select a representation that is understandable by the clients and users (e.g., scenarios and use cases). Developers validate the application domain model by constructing simple prototypes of the user interface and collecting feedback from potential users…Requirements elicitation focuses on describing the purpose of the system. The client, the developers, and the users identify a problem area and define a system that addresses the problem. Such a definition is called a requirements specification and serves as a contract between the client and the developers…The requirements specification is structured and formalized during analysis to produce an analysis model:

Both requirements specification and analysis model represent the same information. They differ only in the language and notation they use; the requirements specification is written in natural language, whereas the analysis model is usually expressed in a formal or semiformal notation.

Requirements elicitation and analysis focus only on the user’s view of the system. For example, the system functionality, the interaction between the user and the system, the errors that the system can detect and handle, and the environmental conditions in which the system functions are part of the requirements. The system structure, the implementation technology selected to build the system, the system design, the development methodology, and other aspects not directly visible to the user are not part of the requirements.

Requirements elicitation includes the following activities:

  1. Identifying actors
  2. Identifying scenarios
  3. Identifying use cases
  4. Refining use cases
  5. Identifying relationships among use cases
  6. Identifying nonfunctional requirements

Elicitation concepts

Functional requirements describe the interactions between the system and its environment independent of its implementation. The environment includes the user and any other external system with which the system interacts… The functional requirements focus only on the possible interactions between the system and its external world. This description does not focus on any of the implementation details.

Nonfunctional requirements describe aspects of the system that are not directly related to the functional behavior of the system. Nonfunctional requirements include a broad variety of requirements that apply to many different aspects of the system, from usability to performance. The FURPS+ model2 used by the Unified Process [Jacobson et al., 1999] provides the following categories of nonfunctional requirements:

Elicitation Activities

Identifying Actors: Actors represent external entities that interact with the system. An actor can be human or an external system. In the SatWatch example, the watch owner, the GPS satellites, and the Webify Watch serial device are actors (see Figure 4-4). They all exchange information with the SatWatch.

Figure 4-4 Actors for the SatWatch system. WatchOwner moves the watch (possibly across time zones) and consults it to know what time it is. SatWatch interacts with GPS to compute its position. Webify Watch upgrades the data contained in the watch to reflect changes in time policy.

The first step of requirements elicitation is the identification of actors. This serves both to define the boundaries of the system and to find all the perspectives from which the developers need to consider the system. When the system is deployed into an existing organization (such as a company), most actors usually exist before the system is developed: they correspond to roles in the organization. During the initial stages of actor identification, it is hard to distinguish actors from objects. For example, a database subsystem can at times be an actor, while in other cases it can be part of the system. Note that once the system boundary is defined, there is no trouble distinguishing between actors and such system components as objects or subsystems. Actors are outside of the system boundary; they are external. Subsystems and objects are inside the system boundary; they are internal.

Thus, any external software system using the system to be developed is an actor. When identifying actors, developers can ask the following questions:

Questions for identifying actors:

• Which user groups are supported by the system to perform their work?

• Which user groups execute the system’s main functions?

• Which user groups perform secondary functions, such as maintenance and administration?

• With what external hardware or software system will the system interact?

Identifying Scenarios: A scenario is “a narrative description of what people do and experience as they try to make use of computer systems and applications” [Carroll, 1995]. A scenario is a concrete, focused, informal description of a single feature of the system from the viewpoint of a single actor. Scenarios cannot (and are not intended to) replace use cases, as they focus on specific instances and concrete events (as opposed to complete and general descriptions). However, scenarios enhance requirements elicitation by providing a tool that is understandable to users and clients…

Figure 4-6 is an example of scenario for the FRIEND system, an information system for incident response. In this scenario, a police officer reports a fire and a Dispatcher initiates the incident response.

Scenarios can have many different uses during requirements elicitation and during other activities of the life cycle. Below is a selected number of scenario types taken from [Carroll, 1995]:

As-is scenarios describe a current situation. During reengineering, for example, the current system is understood by observing users and describing their actions as scenarios.

Visionary scenarios describe a future system. Visionary scenarios are used both as a point in the modeling space by developers as they refine their ideas of the future system and as a communication medium to elicit requirements from users.

Evaluation scenarios describe user tasks against which the system is to be evaluated. The collaborative development of evaluation scenarios by users and developers also improves the definition of the functionality tested by these scenarios.

Training scenarios are tutorials used for introducing new users to the system. These are step-by-step instructions designed to hand-hold the user through common tasks.

In requirements elicitation, developers and users write and refine a series of scenarios in order to gain a shared understanding of what the system should be. Initially, each scenario may be high level and incomplete, as the warehouseOnFire scenario is. The following questions can be used for identifying scenarios.

Questions for identifying scenarios

• What are the tasks that the actor wants the system to perform?

• What information does the actor access? Who creates that data? Can it be modified or removed? By


• Which external changes does the actor need to inform the system about? How often? When?

• Which events does the system need to inform the actor about? With what latency?

Identifying Use Cases: A scenario is an instance of a use case; that is, a use case specifies all possible scenarios for a given piece of functionality. A use case is initiated by an actor. After its initiation, a use case may interact with other actors, as well. A use case represents a complete flow of events through the system in the sense that it describes a series of related interactions that result from its initiation…Figure 4-7 depicts the use case ReportEmergency of which the scenario warehouseOnFire (see Figure 4-6) is an instance

Generalizing scenarios and identifying the high-level use cases that the system must support enables developers to define the scope of the system. Initially, developers name use cases, attach them to the initiating actors, and provide a high-level description of the use case as in Figure 4-7. The name of a use case should be a verb phrase denoting what the actor is trying to accomplish. The verb phrase “Report Emergency” indicates that an actor is attempting to report an emergency to the system (and hence, to the Dispatcher actor). This use case is not called “Record Emergency” because the name should reflect the perspective of the actor, not the system. It is also not called “Attempt to Report an Emergency” because the name should reflect the goal of the use case, not the actual activity

Attaching use cases to initiating actors enables developers to clarify the roles of the different users. Often, by focusing on who initiates each use case, developers identify new actors that have been previously overlooked.

Describing the flow of events of a use case enables developers and clients to discuss the interaction between actors and system. This results in many decisions about the boundary of the system, that is, about deciding which actions are accomplished by the actor and which actions are accomplished by the system.

Identifying relationships between actors and Use Cases: Communication relationships between actors and use cases represent the flow of information during the use case. The actor who initiates the use case should be distinguished from the other actors with whom the use case communicates. By specifying which actor can invoke a specific use case, we also implicitly specify which actors cannot invoke the use case. Similarly, by specifying which actors communicate with a specific use case, we specify which actors can access specific information and which cannot. Thus, by documenting initiation and communication relationships among actors and use cases, we specify access control for the system at a coarse level.

Identifying Initial Analysis Objects: To establish a clear terminology, developers identify the participating objects for each use case. Developers should identify, name, and describe them unambiguously and collate them into a glossary.3 Building this glossary constitutes the first step toward analysis, which we discuss in the next chapter. The glossary is included in the requirements specification and, later, in the user manuals. Developers keep the glossary up to date as the requirements specification evolves. The benefits of the glossary are manyfold: new developers are exposed to a consistent set of definitions, a single term is used for each concept (instead of a developer term and a user term), and each term has a precise and clear official meaning. The identification of participating objects results in the initial analysis object model. The identification of participating objects during requirements elicitation only constitutes a first step toward the complete analysis object model.

During requirements elicitation, participating objects are generated for each use case. If two use cases refer to the same concept, the corresponding object should be the same. If two objects share the same name and do not correspond to the same concept, one or both concepts are renamed to acknowledge and emphasize their difference. This consolidation eliminates any ambiguity in the terminology used.

Identifying Non-functional requirements: Nonfunctional requirements describe aspects of the system that are not directly related to its functional behavior. Nonfunctional requirements span a number of issues, from user interface look and feel to response time requirements to security issues. Nonfunctional requirements are defined at the same time as functional requirements because they have as much impact on the development and cost of the system.

Documenting Requirements Elicitation: The results of the requirements elicitation and the analysis activities are documented in the Requirements Analysis Document (RAD). This document completely describes the system in terms of functional and nonfunctional requirements.Figure 4-16 is an example template for a RAD:

Written by: Larry Francis Obando – Technical Specialist

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.

Contact: Caracas, Quito, Guayaquil, Jaén – +34633129287

WhatsApp: +34633129287


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

Computer Science, UML

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 Electrónica de la Universidad Simón Bolívar, Valle de Sartenejas.

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

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

Contact: Caracas, Quito, Guayaquil, Jaén – tlf. +34 633129287

WhatsApp: +34 633129287


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

Computer Science, UML

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.

Computer Science, UML

UML Class Diagram – 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.