TECNOLOGICO DE ESTUDIOS SUPERIORES DE COACALCO

NOMBRE DEL TRABAJO

ACTIVIDAD INVESTIGACION

NOMBRE DE LOS ALUMNOS

REYES CASTAÑEDA DANIEL

NOMBRE DEL DOCENTE

DAVILA FLORES FILIBERTO RUBEN

MATERIA
FUNDAMENTOS DE ING. DE SOFTWARE

MAYO 2020
INDICE
DIAGRAMAS DE CLASE………………………………… 1

Diagramas de Casos de Uso.………………………….2

DOMINIO……………………………………………………...3
DIAGRAMAS DE CLASE
UML

Lenguaje de modelado unificado

• Es un lenguaje visual de propósito general para representar modelos.

• Pretende proporcionar una forma estándar de representar el diseño de un sistema.

• Dispone de numerosos tipos de diagramas.

• Cada tipo de diagrama muestra un aspecto diferente del modelo.

• Actualmente disponible la versión 2.5. Existen algunas diferencias respecto a las versiones
1.x.

UML: Tipos de diagramas (I)

• diagramas de estructura (aspecto estático)

• diagramas de comportamiento (aspecto dinámico)

UML: Tipos de diagramas (II)

Tipos de diagramas

UML: Diagramas de estructura

Los más utilizados son:

• Diagramas de clases

• Diagramas de paquetes

• Diagramas de componentes

• Diagramas de implementación

Diagramas de clases

Diagrama introductorio
Clases

Clase

Clase con compartimentos

Objetos

Objeto anónimo

Objeto
Interfaces

Interface

Interface con compartimentos

Relaciones

• Asociación

o Agregación

o Composición

• Dependencia

• Generalización

• Realización

Asociación
Asociación

Instancia de asociación

Nota

Agregación

Agregación

Composición

Composición

Composición opcional
Dependencia

Dependencia de instanciación

Dependencia de uso de clase

Dependencia de uso de paquete

Generalización (herencia)
Generalización separada

Generalización compartida

Realización (implementación de interfaces)

Realización bola

Realización
Diagramas de Casos de Uso
Empezaremos a escribir diagramas UML al final de la fase de inicio o al principio de la fase de
elaboración. El primer tipo de diagrama que realizaremos es un diagrama de casos de uso. Es un
diagrama que presenta a los usuarios finales del sistema y que trata de recoger todas las formas
en la que los usuarios interactuarán con la aplicación.

Este diagrama es parte de los diagramas de comportamiento, que muestran de forma sencilla y
visual cómo funciona el sistema para que todas las personas involucradas en el proyecto lo
entiendan.

Se trata de entender el sistema como una historia. Una historia tiene personajes, unas acciones, y
un contexto. Un diagrama de casos de usos es la representación en UML de una historia.

Ya estás familiarizado con casos de uso, aunque no te des cuenta. Un caso de uso describe lo que
siempre tiene que pasar dentro de nuestro sistema y los pasos para llegar a ello, pero también
debe contemplar casos menos comunes. Por ejemplo, en caso de una avería o si el usuario cambia
de idea a lo largo de su interacción

Ejemplo de un caso de uso

Vamos a ver algunos casos de uso para una tienda online.

1. Un vendedor de libros se conecta a la web para subir el artículo que tiene a la venta.

2. Un cliente se conecta a la página web de una tienda online para comprar un libro. Escribe
el título del libro en la barra de búsqueda y busca el mejor precio entre los resultados.
Cuando encuentra una oferta que le interesa, le añade al carrito de la compra. Tiene que
haber iniciado una sesión para poder hacerlo.

Los casos de uso siempre deben comportar un verbo.

Este es un caso de uso muy sencillo. Muchas veces, la descripción será más larga si el proyecto es
más complejo.

Ahora tratemos de traducir nuestro caso de uso a un diagrama de casos de uso.

Este diagrama incluye lo siguiente:

• Un actor o varios actores.

• Acciones.

• Relaciones de "include" y "extend".

Los actores son los diferentes participantes en nuestro escenario. Son los que llevan a cabo
las acciones que describimos en los casos de uso. Los actores se representan como figuras de palo.
No hace falta ser muy buen dibujante
¡Los actores no son necesariamente personas! Pueden representar organizaciones o incluso
componentes del software.

Las acciones son aquello que hacen los actores con el sistema. Son funcionalidades que deberán
ser luego implementadas.

En el centro, dibujamos el sistema. Es el escenario dónde nuestros actores interactúan. Lo

representaremos como un rectángulo, y dibujaremos los casos de uso dentro del sistema.

Primera etapa del diseño de un diagrama de casos de uso

Empecemos con las primeras acciones descritas en el caso de uso textual: el comprador buscando
un artículo. Podemos añadir “ver artículos” en el sistema. Dibujamos una línea entre el comprador
y la acción para significar quien lleva a cabo la acción. También añadimos la acción “subir artículo”
y dibujamos una línea entre el vendedor y la acción.
Actores y acciones

Para poder elegir la mejor oferta, el comprador tiene que ser capaz de ordenar los artículos por
precio. Usaremos la palabra clave <<extend>> para designar una acción que puede derivar de
otra, dibujando una línea punteada entre los casos de uso con la palabra<<extend>>en la línea.
Añadimos la palabra clave <<extend>>

Ahora pasamos a la acción “comprar artículo”. Esta acción involucra el comprador, así como
el vendedor. También hemos de añadir otro actor, ya que, para efectuar el pago, necesitamos usar
el sistema de pagos. Lo añadiremos como otro actor (¡recordar que los actores no son
necesariamente humanos!). Dibujamos una línea entre cada actor y la acción.

añadimos la acción "comprar artículo"

Finalmente, hemos de asegurarnos de que, para poder comprar, un usuario este registrado en la
plataforma. Este requerimiento lo modelamos con la palabra clave<<include>>con una flecha
desde “comprar artículo” hacía “iniciar sesión”.
Añadimos una acción con la palabra clave <>

Con esto hemos visto los principales elementos de un diagrama de casos de uso. Es bastante
sencillo, ¿no? Pero no te dejes engañar: esta etapa es muy importante para entender el contexto
del trabajo que vamos a realizar, y nos permite enfocarnos solo en lo importante y descartar el
resto. Recuerda que los elementos que siempre debe llevar un diagrama de casos de uso son

• Actores

• Acciones

• Líneas entre los actores y las acciones que les corresponden

Adicionalmente, puede comportar

• relaciones <<include>> entre acciones cuando una acción es prerrequisito de otra

• relaciones <<extend>> entre acciones cuando una acción es una opción después de
realizar otra.
DOMINIO

Un Modelo de Dominio es un artefacto de la disciplina de análisis , construido con las reglas de

UML durante la fase de concepción, en la tarea construcción del modelo de dominio, presentado
como uno o más diagramas de clases y que contiene, no conceptos propios de un sistema de
software sino de la propia realidad física.

Los modelos de dominio puede utilizarse para capturar y expresar el entendimiento ganado en un
área bajo análisis como paso previo al diseño de un sistema, ya sea de software o de otro tipo.
Similares a los mapas mentales utilizados en el aprendizaje, el modelo de dominio es utilizado por
el analista como un medio para comprender el sector industrial o de negocios al cual el sistema va
a servir.

El modelo de dominio puede ser tomado como el punto de partida para el diseño del sistema. Esto
es así ya que cuando se realiza la programación orientada a objetos, se supone que el
funcionamiento interno del software va a imitar en alguna medida a la realidad, por lo que el
mapa de conceptos del modelo de domino constituye una primera versión del sistema.

En la aproximación llamada Desarrollo Guiado por Modelos al modelo de dominio se le conoce

como Modelo Independiente del Computador o CIM, por sus siglas en inglés. El CIM es el que da
inicio al proceso de desarrollo y ocupa el rol, tanto de modelo de requisitos como de modelo
análisis.

Por otra parte, cuando se sigue una aproximación Centrada en Casos de Uso como RUP/UP, el
modelo de dominio es utilizado como entrada en la tarea análisis de los casos de uso en la
construcción de los llamados escenarios de análisis.