Tema 1.

Dr. Edgar Cossio

 Tema 1.1
Agenda:

• UML
• Notación y semántica estándar
• Extensiones UML
• Tarjetas CRC
• DERE
 Tema 1.1

¿Qué es UML?
 Historia
En 1996, el Object Management Group (OMG),
un pilar estándar para la comunidad del diseño
orientado a objetos, publicó una petición con
propósito de un metamodelo orientado a
objetos de semántica y notación estándares.
UML, en su versión 1.0, fue propuesto como una
respuesta a esta petición en enero de 1997.

4
 Introducción
El Lenguaje Unificado de Modelado prescribe un
conjunto de notaciones y diagramas estándar
para modelar sistemas orientados a objetos, y
describe la semántica esencial de lo que estos
diagramas y símbolos significan. Mientras que
ha habido muchas notaciones y métodos usados
para el diseño orientado a objetos, ahora los
modeladores sólo tienen que aprender una
única notación.
5
 Usos
UML se puede usar para modelar distintos tipos de
sistemas: sistemas de software y arquitecturas
mediante patrones de diseño.

6
 Tipos
UML ofrece nueve diagramas en los cuales modelar sistemas.
• Diagramas de Casos de Uso para modelar los procesos.
• Diagramas de Secuencia para modelar el paso de mensajes entre objetos.
• Diagramas de Colaboración para modelar interacciones entre objetos.
• Diagramas de Estado para modelar el comportamiento de los objetos en el
sistema.
• Diagramas de Actividad para modelar el comportamiento de los Casos de
Uso, objetos u operaciones.
• Diagramas de Clases para modelar la estructura estática de las clases en el
sistema.
• Diagramas de Componentes para modelar componentes software.
• Diagramas de Nodos para modelar la distribución del sistema (hardware).

7
Creadores

8
Bases

9
Notaciones

10
 Tema 1.2

Notación y semántica
estándar

Mtro. Edgar Cossio

Ingeniería de software II
 Definiciones
Notación
1. f. Sistema de signos convencionales que se adopta para expresar conceptos
matemáticos, físicos, químicos, etc.

Semántica
1. adj. Perteneciente o relativo a la significación de las palabras.

Estándar
1. adj. Que sirve como tipo, modelo, norma, patrón o referencia.
Fuente: Real Academia Española

12
Por qué una notación…estándar

13
 Metodologías
• Shlaer-Mellor

14
 Metodologías
• Ejemplo Shlaer-Mellor

15
 Metodologías
• Fusión
Fusión, proporciona un método de desarrollo de software orientado a objeto, que
abarca desde la definición de requisitos a la implementación en un lenguaje de
programación.

Es considerada como una metodología de segunda generación, porque proviene de:

OMT: modelo de objetos.
CRC: interacción de objetos.
BOOCH: visibilidad.

Los métodos formales: pre y post condiciones.

Proporciona un proceso de desarrollo, que se divide en: Análisis, Diseño e
Implementación.
Ofrece notaciones para los modelos, que describen varios aspectos del software.
Proporciona herramientas de gestión.

16
Metodologías
• Responsabilidad Driven Design
• Análisis y diseño orientado a
objetos
• Análisis de software orientado a
objetos
• Análisis visual de objetos
OOPSLA:
• Object-Oriented Programming,
Systems, Languages & Applications

• OML:
Open Modeling Language

• SOMA:
Semantic Object Modelling Approach

• BPMN
Business Process Modeling Notation

• DSL
Domain-Specific Language

17
 UML ofrece notación y semántica
estándar
UML ofrece una notación estándar y semánticas
esenciales para el modelado de un sistema
orientado a objetos.
Previamente, un diseño orientado a objetos
podría haber sido modelado con cualquiera de
las metodologías populares, causando a los
revisores tener que aprender las semáticas y
notaciones de la metodología empleada antes
que intentar entender el diseño en sí.
18
Ahora con UML, diseñadores diferentes
modelando sistemas diferentes pueden
sobradamente entender cada uno los diseños de
los otros.

19
 Tema 1.3

Extensiones
UML

Mtro. Edgar Cossio

Ingeniería de software II
 Extensibility Mechanisms
The UML provides a standard language for writing
software blueprints, but it is not possible for one closed
language to ever be sufficient to express all possible
nuances of all models across all domains across all time.
For this reason, the UML is opened-ended, making it
possible for you to extend the language in controlled ways.
The UML's extensibility mechanisms include

· Stereotypes
· Tagged values
· Constraints
21
 Stereotypes
A stereotype extends the vocabulary of the UML, allowing you to
create new kinds of building blocks that are derived from existing
ones but that are specific to your problem. For example, if you are
working in a programming language, such as Java or C++, you will
often want to model exceptions. In these languages, exceptions
are just classes, although they are treated in very special ways.

Typically, you only want to allow them to be thrown and caught,

nothing else. You can make exceptions first class citizens in your
models• meaning that they are treated like basic building blocks•
by marking them with an appropriate stereotype.

22
 Stereotypes

Especificación
* Nombre: include
* Aplica a: dependencias entre casos de uso
* Significado: El caso de uso base refiere al caso
de uso incluido como parte de su flujo de eventos.
Note
When you define an icon for a stereotype, consider using color as an accent to
provide a subtle visual cue (but use color sparingly). The UML lets you use any shape
for such icons, and if your implementation permits it, these icons might appear as
primitive tools so that users who create UML diagrams will have a palette of things 23
that look basic to them and speak the vocabulary of their domain.
 Tagged values
A tagged value extends the properties of a UML building
block, allowing you to create new information in that
element's specification.

For example, if you are working on a product that undergoes

many releases over time, you often want to track the
version and author of certain critical abstractions. Version
and author are not primitive UML concepts. They can be
added to any building block, such as a class, by introducing
new tagged values to that building block. In Figure 2-19, for
example, the class EventQueue is extended by marking its
version and author explicitly. 24
Tagged values

25
 Constraints
A constraint extends the semantics of a UML
building block, allowing you to add new rules or
modify existing ones.

For example, you might want to constrain the

Event-Queue class so that all additions are done in
order. As Figure 2-19 shows, you can add a
constraint that explicitly marks these for the
operation add.

26
Example

27
 Constraints

Note
Constraints may be written as free-form text. If you want to specify your
semantics more precisely, you can use the UML's Object Constraint Language
(OCL), described further in The The Unified Modeling Language Reference 28
Manual.
Stereotypes, Tagged Values, and Constraints

29
Stereotypes, Tagged Values, and Constraints

30
 Conclusions
Collectively, these three extensibility mechanisms allow you to shape and grow
the UML to your project's needs. These mechanisms also let the UML adapt to
new software technology, such as the likely emergence of more powerful
distributed programming languages. You can add new building blocks, modify the
specification of existing ones, and even change their semantics.
Naturally, it's important that you do so in controlled ways so that through these
extensions, you remain true to the UML's purpose• the communication of
information.

31
 Tema 1.5

Análisis guiado por responsabilidades

Tarjetas CRC

Mtro. Edgar Cossio

Ingeniería de software II
 Tema 1.4

El modelado de clases-responsabilidades
colaboraciones (CRC) aporta un medio sencillo de
identificar y organizar las clases que resulten
relevantes al sistema o requisitos del producto.

Un modelo CRC es realmente una colección de tarjetas

índice estándar que representan clases. Las tarjetas
están divididas en tres secciones. A lo largo de la
cabecera de la tarjeta usted escribe el nombre de la
clase. En el cuerpo se listan las responsabilidades de la
clase a la izquierda y a la derecha los colaboradores.
Las responsabilidades son los atributos y operaciones
relevantes para la clase. Puesto de forma simple, una
responsabilidad es «cualquier cosa que conoce o hace
la clase».
Los colaboradores son aquellas clases necesarias para
proveer a una clase con la información necesaria para
completar una responsabilidad. En general, una
colaboración implica una solicitud de información o
una solicitud de alguna acción.
Responsabilidades

Los atributos representan características estables de una clase,

esto es, información sobre la clase que debe retenerse para llevar
a cabo los objetivos del software especificados por el cliente.
Los atributos pueden a menudo extraerse del planteamiento de
alcance o discernirse a partir de la comprensión de la naturaleza
de la clase. Las operaciones pueden extraerse desarrollando un
análisis gramatical sobre la narrativa de procesamiento del
sistema.
Los verbos se transforman en candidatos a operaciones.
Cada operación elegida para una clase exhibe un
comportamiento de la clase.
Colaboradores

Las colaboraciones representan solicitudes de un cliente a un

servidor en el cumplimiento de una responsabilidad del cliente.
Una colaboración es la realización de un contrato entre el cliente
y el servidor. Decimos que un objeto colabora con otro, si para
ejecutar una responsabilidad necesita enviar cualquier mensaje
al otro objeto. Una colaboración simple fluye en una dirección,
representando una solicitud del cliente al servidor.
Desde el punto de vista del cliente, cada una de sus
colaboraciones está asociada con una responsabilidad particular
implementada por el servidor.
La colaboración implica el paso de mensajes.
Fortalezas

•Por la sencillez del método se ha incorporado a diferentes

metodologías. Es una herramienta que ayuda para la transición
procedural a OO.
•Es muy visual para todos los participantes y no tiene una
simbología especial.
•Permite centrarse en la importancia del objeto y sus operaciones
en el sistema.
Debilidades

•Su simplicidad también es una debilidad, falta mucho para

completar el análisis y el diseño.
•El éxito del proceso depende del que esté dirigiendo la actividad
ó el que la lleve a cabo.
 Tarjeta CRC

Nombre de la Abstracción (Clase)

Responsabilidades Colaboradores
(operaciones y atributos) (relaciones)

Mantener un estado Elementos con los que va

Llevar a cabo alguna a interactuar la
tarea abstracción
•Ejemplo: sistema de reservaciones

•Un empleado debe crear, recuperar, actualizar y borrar una

reservación de hotel. Por lo tanto, una reservación tiene una
fecha de llegada, de salida y un ID.

•Una reservación está asociada con un solo cliente. En este

caso hay una colaboración entre la Reservación y un Cliente.
 Tarjeta CRC para el cuarto

Reservación

Responsabilidades Colaboradores
(operaciones y atributos) (relaciones)
Reservar un cuarto Cuarto
Cliente
Status (nueva, confirmada)
Fecha llegada
Fecha salidas
Forma pago
Número reservación
 Modelado de datos con el enfoque
entidad-relación (E-R)

Conceptos del modelo E-R

Entidades y atributos

Entidad: Algo del mundo real con existencia independiente, pudiendo ser un
objeto con existencia física (persona, automóvil, casa, o un empleado) o bien un objeto
con existencia conceptual (curso universitario, puesto de trabajo). Cada entidad contiene
propiedades específicas llamadas atributos.
 Modelado de datos con el enfoque
entidad-relación (E-R)

Conceptos del modelo E-R

Entidades y atributos

Atributos:
Simples: no divisible o atómicos (estado, municipio, etc.)
Compuestos: se pueden dividir en componentes más pequeños que representan
atributos más básicos con su propio significado independiente (domicilio,
nombre, etc.).
Monovaluados: tienen un solo valor (edad, sexo, etc.)
Multivaluados: tienen más de un valor (colores, teléfonos, etc.)
Derivado: derivable de otro u otros atributos (edad puede derivarse a partir de la
fecha de nacimiento)
Clave: su valor es distinto para cada registro individual, a aquellas entidades que
no tienen atributos clave se les denomina entidades débiles.
 Modelado de datos con el enfoque
entidad-relación (E-R)

Conceptos del modelo E-R

Grados de los vínculos (cardinalidad)

Grado de un vínculo: es el número de tipos de entidades que participan en el mismo

vinculo.
a) 1:1
b) 1:N
c) M:N
 Modelado de datos con el enfoque
entidad-relación (E-R)

Conceptos del modelo E-R

Tipos de vínculos con grado mayor de dos

Aquellos vínculos con grado mayor que dos se representan gráficamente asignando
al menos uno de los identificadores de cada uno de los tipos de entidades y colocando la
relación de M:N en los extremos de dicho rombo.
 Modelado de datos con el enfoque
entidad-relación (E-R)

Conceptos del modelo E-R

Notación para los diagramas E-R

Entidad Atributo clave

Vínculo Atributo
derivado

Atributo simple

Fuente: Elmasri,
Atributo
Navathe
compuesto
Modelado de datos con el enfoque
entidad-relación (E-R)

¿Es posible modelar OO

mediante DER?
 Modelado de datos con el enfoque
entidad-relación (E-R)

Diagrama Entidad-Relación Extendido

Subclases, superclases y especialización

Herencia de atributos

Generalización

Restricciones sobre especialización y generalización

 Diagrama Entidad-Relación
Extendido
(Superclase, subclase, generalización
y especialización)
Conceptos
Los registros que son miembros de una entidad sea por ejemplo EMPLEADO pueden agruparse en
entidades SECRETARIA, INGENIERO, GERENTE, TÉCNICO, EMPLEADO_ASALARIADO,
EMPLEADO_POR_HORA, etc. El conjunto de registros de cada una de estas agrupaciones, es un
subconjunto del total de registros de que pertenecen a EMPLEADO, lo que significa que todo registro que sea
miembro de una de estas subagrupaciones también será un empleado. Cada una de estas subagrupaciones es
una subclase de EMPLEADO, y EMPLEADO es la superclase de cada una de estas subclases.
A la relación entre una superclase y cualquiera de sus subclases le llamamos vínculo superclase/subclase o
simplemente clase/subclase.
Asimismo, llamaremos especialización al proceso de definir un conjunto de subclases que se definen a
partir de alguna característica distintiva de las entidades de la superclase. En nuestro ejemplo SECRETARIA,
INGENIERO y TÉCNICO es una especialización de la superclase EMPLEADO, y la razón de su agrupación
dependió según el tipo de trabajo de cada uno de los empleados
De igual forma puede concebirse un proceso inverso de abstracción en el que se suprime la diferencia entre
entidades, identificamos sus rasgos comunes y entonces los generalizamos para formar una superclase,
llamamos entonces a esto una generalización. En nuestro ejemplo, EMPLEADO es una generalización de
SECRETARIA, INGENIERO y TÉCNICO.
 Diagrama Entidad-Relación
Extendido
(Herencia de atributos y restricciones
de generalización/especialización)
Conceptos
En el modelo Entidad-Relación Extendido se hace uso de la herencia de atributos en los vínculos
superclase/subclase, en el sentido de que una subclase hereda tanto los atributos como los registros de la
superclase a la que pertenece. En nuestro ejemplo, SECRETARIA, INGENIERO y TÉCNICO heredan los
atributos y registros de EMPLEADO.
La descripción de la notación usada en un diagrama entidad-relación extendido es la siguiente:
a) Para las restricciones de generalización/especialización:
a.1) Disyunción: se hace uso de una d para indicar que las subclases son disjuntas (Un registro de
EMPLEADO puede ser miembro de cuando más una subclase de la especialización)
a.2) Conjunción: se hace uso de una o para indicar que las subclases no son disjuntas (Si un registro de
EMPLEADO pudiera ser miembro de más una subclase de la especialización, que no es parte del ejemplo
siguiente)
 Diagrama Entidad-Relación
Extendido
(Herencia de atributos y restricciones
de generalización/especialización)
Conceptos
b) Para las restricciones de compleción :
b.1) Se hace uso de una línea doble que conecte la superclase con el círculo para indicar especialización
total, que especifica que todo registro de la superclase debe ser miembro de alguna subclase de la
especialización (la suma de los registros de EMPLEADO_ASALARIADO y EMPLEADO POR HORA
corresponderá al total de registros de EMPLEADO)
b.2) Se hace uso de una línea sencilla que conecte la superclase con el círculo para indicar especialización
parcial, que permite que algún registro de la superclase no deba ser miembro necesariamente de alguna
subclase de la especialización (la suma de los registros de SECRETARIA, TÉCNICO e INGENIERO no
corresponderá al total de registros de EMPLEADO)
 Diagrama Entidad-Relación
Extendido
(Con Disyunción)

NombrePila ApePat Apemat

NSS Nombre FechaNacim Domicilio CveEdif Ubicación

EMPLEADO N Se localiza 1 EDIFICIO

d d

RapidezTecleo GradoTec TipoIng Salario Pagohora

SECRETARIA TÉCNICO INGENIERO EMPLEADO EMPLEADO

ASALARIADO
POR HORA
 Diagrama Entidad-Relación
Extendido
(Con Conjunción)

Numcomp Descripción CveAlmacénf Ubicación

COMPONENTE N Se localiza 1 ALMACÉN

NúmDibujo FechaFabricación NúmLote Proveedor PrecioLista

COMPONENTE_FABRICADO COMPONENTE_COMPRADO
 Diagrama Entidad-Relación
Extendido

Ejercicio
Diseñar un diagrama entidad-relación que muestre los datos relacionados
con un desastre natural, pudiendo ser un huracán, terremoto o bien
maremoto. Para los tres anteriores se registra el valor económico por los
daños causados y el número de fallecidos, asimismo el país o países que
afectó y la fecha en que sucedió. Para el caso del huracán, además de los
datos anteriores se registra la fecha en que se predijo (cuándo se comenzó a
formar), nombre (“Paulina”, “Alberto”, etc.) y tipo, para el caso del
terremoto se registra asimismo la duración, el radio de acción y la intensidad
en la escala Richter, mientras que para el maremoto la penetración del agua a
tierra (dada en metros).
 Ejercicio
• Instalar StarUML

• Modelar en StarUML un diagrama donde se muestre lo

siguiente:
• Valor etiquetado
• Restricción
• Estereotipo

56
 Ejercicio
- Visite la página:
- https://youtu.be/aPVllnncWdY, la conferencia “Procesos
de arquitectura de software y su impacto en la
satisfacción de los objetivos de negocio de las
organizaciones” y una vez visto el video en ella, conteste
lo siguiente:
- ¿Qué es un objetivo de negocio?
- ¿Cuáles son los atributos de calidad?
- ¿Qué es la arquitectura de software?
- ¿Quién es la ponente?
- En sus palabras, ¿es importante la arquitectura de software?

57
 Actividad de Clase
Tres equipos e investigar:

1. ¿Existe alguna certificación para UML?

2. Las siguientes características de UML:

•Clave de examen
•Duración
•Preguntas
•Porcentaje mínimo para pasar
•Costo
•Prerrequisitos

58