Embed Size (px)
DESCRIPTION
Todo lo de Ingenieria de Software
Citation preview
UNIVERSIDA NACIONAL DE CHIMBORAZO
FACULTAD DE INGENIERIA
ESCUELA DE SISTEMAS Y COMPUTACION
Integrantes: Nancy cantuña,Alex Asitimbay,Alexis Santos
Fecha: 18-12-2015
Semestre: 6to
Tema: Diagramas
Modelo de Clases
Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el
sistema, las cuales pueden ser asociativas, de herencia, de uso y de consentimiento.
Un diagrama de clases está
compuesto por los siguientes elementos:
Clase: atributos, métodos y visibilidad.
Relaciones: Herencia, Composición, Agregación, Asociación y Uso.
Elementos
Clase
Es la unidad básica que encapsula toda la información de un Objeto (un objeto es
una instancia de una clase). A través de ella podemos modelar el entorno en estudio
(una Casa, un Auto, una Cuenta Corriente, etc.).
En UML, una clase es representada por un rectángulo que posee tres divisiones:
En donde:
o Superior: Contiene el nombre de la Clase
o Intermedio: Contiene los atributos (o variables de instancia) que caracterizan
a la Clase (pueden ser private, protected o public).
o Inferior: Contiene los métodos u operaciones, los cuales son la forma como
interactúa el objeto con su entorno (dependiendo de la visibilidad: private,
protected o public).
Ejemplo:
Una Cuenta Corriente que posee como característica:
o Balance
Puede realizar las operaciones de:
o Depositar
o Girar
o y Balance
El diseño asociado es:
Atributos y Métodos:
o Atributos:
Los atributos o características de una Clase pueden ser de tres tipos, los que
definen el grado de comunicación y visibilidad de ellos con el entorno, estos
son:
public (+, ): Indica que el atributo será visible tanto dentro
como fuera de la clase, es decir, es accsesible desde todos lados.
private (-, ): Indica que el atributo sólo será accesible desde
dentro de la clase (sólo sus métodos lo pueden accesar).
protected (#, ): Indica que el atributo no será accesible desde
fuera de la clase, pero si podrá ser accesado por métodos de la clase
además de las subclases que se deriven (ver herencia).
o Métodos:
Los métodos u operaciones de una clase son la forma en como ésta
interactúa con su entorno, éstos pueden tener las características:
public (+, ): Indica que el método será visible tanto dentro como
fuera de la clase, es decir, es accsesible desde todos lados.
private (-, ): Indica que el método sólo será accesible desde
dentro de la clase (sólo otros métodos de la clase lo pueden accesar).
protected (#, ): Indica que el método no será accesible desde
fuera de la clase, pero si podrá ser accesado por métodos de la clase
además de métodos de las subclases que se deriven (ver herencia).
Relaciones entre Clases:
Ahora ya definido el concepto de Clase, es necesario explicar cómo se pueden
interrelacionar dos o más clases (cada uno con características y objetivos
diferentes).
Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la
cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en
cada extremo de la relación y éstas pueden ser:
o uno o muchos: 1..* (1..n)
o 0 o muchos: 0..* (0..n)
o número fijo: m (m denota el número).
iv. Herencia (Especialización/Generalización):
Indica que una subclase hereda los métodos y atributos especificados por
una Super Clase, por ende la Subclase además de poseer sus propios
métodos y atributos, poseerá las características y atributos visibles de la
Super Clase (public y protected), ejemplo:
En la figura se especifica que Auto y Camión heredan de Vehículo, es decir,
Auto posee las Características de Vehículo (Precio, VelMax, etc) además
posee algo particular que es Descapotable, en cambio Camión también
hereda las características de Vehiculo (Precio, VelMax, etc) pero posee
como particularidad propia Acoplado, Tara y Carga.
Cabe destacar que fuera de este entorno, lo único "visible" es el método
Caracteristicas aplicable a instancias de Vehículo, Auto y Camión, pues
tiene definición publica, en cambio atributos como Descapotable no son
visibles por ser privados.
v. Agregación:
Para modelar objetos complejos, n bastan los tipos de datos básicos que
proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se
requiere componer objetos que son instancias de clases definidas por el
desarrollador de la aplicación, tenemos dos posibilidades:
Por Valor: Es un tipo de relación estática, en donde el tiempo de vida
del objeto incluido esta condicionado por el tiempo de vida del que
lo incluye. Este tipo de relación es comunmente llamada
Composición (el Objeto base se contruye a partir del objeto incluido,
es decir, es "parte/todo").
Por Referencia: Es un tipo de relación dinámica, en donde el tiempo
de vida del objeto incluido es independiente del que lo incluye. Este
tipo de relación es comunmente llamada Agregación (el objeto base
utiliza al incluido para su funcionamiento).
Un Ejemplo es el siguiente:
En donde se destaca que:
Un Almacen posee Clientes y Cuentas (los rombos van en el objeto
que posee las referencias).
Cuando se destruye el Objeto Almacen también son destruidos los
objetos Cuenta asociados, en cambio no son afectados los objetos
Cliente asociados.
La composición (por Valor) se destaca por un rombo relleno.
La agregación (por Referencia) se destaca por un rombo
transparente.
La flecha en este tipo de relación indica la navegabilidad del objeto
refereniado. Cuando no existe este tipo de particularidad la flecha se
elimina.
vi. Asociación:
La relación entre clases conocida como Asociación, permite asociar objetos
que colaboran entre si. Cabe destacar que no es una relación fuerte, es decir,
el tiempo de vida de un objeto no depende del otro.
Ejemplo:
Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio
una orden de compra solo puede tener asociado un cliente.
vii. Dependencia o Instanciación (uso):
Representa un tipo de relación muy particular, en la que una clase es
instanciada (su instanciación es dependiente de otro objeto/clase). Se denota
por una flecha punteada.
El uso más particular de este tipo de relación es para denotar la dependencia
que tiene una clase de otra, como por ejemplo una aplicación grafica que
instancia una ventana (la creación del Objeto Ventana esta condicionado a la
instanciación proveniente desde el objeto Aplicacion):
Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se
almacena dentro del objeto que lo crea (en este caso la Aplicación).
Casos Particulares:
o Clase Abstracta:
Una clase abstracta se denota con el nombre de la clase y de los métodos con
letra "itálica". Esto indica que la clase definida no puede ser instanciada
pues posee métodos abstractos (aún no han sido definidos, es decir, sin
implementación). La única forma de utilizarla es definiendo subclases, que
implementan los métodos abstractos definidos.
o Clase parametrizada:
Una clase parametrizada se denota con un subcuadro en el extremo superior
de la clase, en donde se especifican los parámetros que deben ser pasados a
la clase para que esta pueda ser instanciada. El ejemplo más típico es el caso
de un Diccionario en donde una llave o palabra tiene asociado un
significado, pero en este caso las llaves y elementos pueden ser genéricos.
La genericidad puede venir dada de un Template (como en el caso de C++)
o bien de alguna estructura predefinida (especialización a través de clases).
En el ejemplo no se especificaron los atributos del Diccionario, pues ellos
dependerán exclusivamente de la implementación que se le quiera dar.
DIAGRAMAS DE CASOS DE USO.
Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para
llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso de uso
se denominan actores. En el contexto de ingeniería del software, un caso de uso es una
secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a
un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de
uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su
interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra
la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión
entre los elementos del modelo, por ejemplo la especialización y la generalización son
relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del
sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.
Los más comunes para la captura de requisitos funcionales, especialmente con el desarrollo
del paradigma de la programación orientada a objetos, donde se originaron, si bien puede
utilizarse con resultados igualmente satisfactorios con otros paradigmas de programación.
TIPOS DE RELACIONES
Comunica (<<communicates>>): Relación (asociación) entre un actor y un caso de
uso que denota la participación del actor en dicho caso de uso.
Usa (<<uses>>) (o <<include>> en la nueva versión de UML): Relación de
dependencia entre dos casos de uso que denota la inclusión del comportamiento de
un escenario en otro.
Extiende (<<extends>>): Relación de dependencia entre dos casos de uso que
denota que un caso de uso es una especialización de otro. Por ejemplo, podría
tenerse un caso de uso que extienda la forma de pedir azúcar, para que permita
escoger el tipo de azúcar (normal, dietético o moreno) y además la cantidad en las
unidades adecuadas (cucharadas o bolsas).
Se utiliza una relación de tipo <<extends>> entre casos de uso cuando nos encontramos con
un caso de uso similar a otro pero que hace algo más que éste (variante). Por contra,
utilizaremos una relación tipo <<uses>> cuando nos encontramos con una parte de
comportamiento similar en dos casos de uso y no queremos repetir la descripción de dicho
comportamiento común.
En una relación <<extends>>, un actor que lleve a cabo el caso de uso base puede realizar o
no sus extensiones. Mientras, en una relación <<include>> el actor que realiza el caso de
uso base también realiza el caso de uso incluido.
En general utilizaremos <<extends>> cuando se presenta una variación del comportamiento
normal, y <<include>> cuando se repite un comportamiento en dos casos de uso y
queremos evitar dicha repetición.
Por último en un diagrama de casos de uso, además de las relaciones entre casos de uso y
actor (asociaciones) y las dependencias entre casos de uso (<<include>> y <<extends>>),
pueden existir relaciones de herencia ya sea entre casos de uso o entre actores.
Llamamos modelo de casos de uso a la combinación de casos de uso y sus correspondientes
diagramas. Los modelos de casos de uso se suelen acompañar por un glosario que describe
la terminología utilizada. El glosario y el modelo de casos de uso son importantes puntos de
partida para el desarrollo de los diagramas de clases.
Por último se debe tener en cuenta, que aunque cada caso de uso puede llevar a diferentes
realizaciones, es importante reflejar en cada representación el motivo que nos ha llevado a
descartarla, si es el caso.
Pasos para la Definición de un Caso de Uso:
ID
NOMBRE
REFERENCIAS CRUZADAS
CREADO POR
ULTIMA ACTUALIZACIÓN POR
FECHA DE CREACIÓN
FECHA DE ULTIMA ACTUALIZACIÓN
ACTORES
DESCRIPCIÓN
TRIGGER
PRE-CONDICIÓN
POST-CONDICIÓN
FLUJO NORMAL
FLUJOS ALTERNATIVOS
INCLUDES
FRECUENCIA DE USO
REGLAS DE NEGOCIO
REQUERIMIENTOS ESPECIALES
NOTAS Y ASUNTO
DIAGRAMAS DE ACTIVIDAD
En UML un diagrama de actividades se usa para mostrar la secuencia de actividades. Los
diagramas de actividades muestran el flujo de trabajo desde el punto de inicio hasta el
punto final detallando muchas de las rutas de decisiones que existen en el progreso de
eventos contenidos en la actividad. Estos también pueden usarse para detallar situaciones
donde el proceso paralelo puede ocurrir en la ejecución de algunas actividades. Los
Diagramas de Actividades son útiles para el Modelado de Negocios donde se usan para
detallar el proceso involucrado en las actividades de negocio.
Un ejemplo de un diagrama de actividades se muestra a continuación
Las siguientes secciones describen los elementos que constituyen un diagrama de
actividades.
Actividades
Una actividad es la especificación de una secuencia parametrizada de comportamiento. Una
actividad muestra un rectángulo con las puntas redondeadas adjuntando todas las acciones,
flujos de control y otros elementos que constituyen la actividad.
Acciones
Una acción representa un solo paso dentro de una actividad. Las acciones se denotan por
rectángulos con las puntas redondeadas.
Restricciones de Acción
Las restricciones se pueden adjuntar a una acción. El siguiente diagrama muestra una
acción con pre y post condiciones locales.
Flujo de Control
Un flujo de control muestra el flujo de control de una acción a otra. Su notación es una
línea con una punta de flecha.
Nodo Inicial
Un nodo inicial o de comienzo se describe por un gran punto negro, como se muestra a
continuación.
Nodo Final
Hay dos tipos de nodos finales: nodos finales de actividad y de flujo. El nodo final de
actividad se describe como un círculo con un punto dentro del mismo.
El nodo final de flujo se describe como un círculo con una cruz dentro del mismo.
La diferencia entre los dos tipos de nodos es que el nodo final del flujo denota el final de un
solo flujo de control, y el nodo final de actividad denota el final de todos los flujos finales
dentro de la actividad.
Flujos de Objetos y Objeto
Un flujo de objeto es la ruta a lo largo de la cual pueden pasar objetos o datos. Un objeto se
muestra cómo un rectángulo.
Un flujo de objeto se muestra como un conector con una punta de flecha denotando la
dirección a la cual se está pasando el objeto.
Un flujo de objeto debe tener un objeto en por lo menos uno de sus extremos. Una notación
de acceso rápido para el diagrama de arriba sería usar los pins de salidas y entradas.
Un almacén de clave se muestra como un objeto con las clave «datastore».
Nodos de Decisión y Combinación
Los nodos de decisión y combinación tienen la misma notación: una forma de diamante.
Los dos se pueden nombrar. Los flujos de control que provienen de un nodo de decisión
tendrán condiciones de guarda que permitirán el control para fluir si la condición de guarda
se realiza. El siguiente diagrama muestra el uso de un nodo de decisión y un nodo de
combinación.
Nodos de Bifurcación y Unión
Las bifurcaciones y uniones tienen la misma notación: tanto una barra horizontal como
vertical (la orientación depende de si el flujo de control va de derecha a izquierda o hacia
abajo y arriba. Estos indican el comienzo y final de hilos actuales de control. El siguiente
diagrama muestra un ejemplo de su uso.
Una unión es diferente de una combinación ya que la unión sincroniza dos flujos de entrada
y produce un solo flujo de salida. El flujo de salida desde una unión no se puede ejecutar
hasta que todos los flujos se hayan recibido. Una combinación pasa cualquier flujo de
control directamente a través de esta. Si dos o más flujos de entrada se reciben por un
símbolo de combinación, la acción a la que el flujo de salida apunta se ejecuta dos o más
veces.
Región de Expansión
Una región de expansión es una región de actividad estructurada que se ejecuta muchas
veces. Los nodos de expansión de salida y entrada se dibujan como un grupo de tres casillas
representando una selección múltiple de ítems. La clave reiterativa, paralelo, o flujo se
muestra en la esquina izquierda arriba de la región.
Gestores de Excepción
Los gestores de Excepción se pueden modelar en diagramas de actividad como en siguiente
ejemplo.
Región de Actividad Interrumpible
Una región de actividad interrumpible rodea un grupo de acciones que se pueden
interrumpir. En un ejemplo simple como el siguiente, la acción Procesar Orden se ejecutará
hasta su cumplimiento cuando pase control a la acción Cerrar Orden, a menos que una
interrupción Cancelar Pedido se reciba, la cual pasará el control a la acción Cancelar Orden.
Partición
Una partición de una actividad se muestra como calles horizontales o verticales. En el
siguiente diagrama, las particiones se usan para separar acciones dentro de una actividad en
aquellas realizadas por el departamento de contabilidad y aquellas realizadas por el cliente.
DIAGRAMA DE SECUENCIA
Un diagrama de secuencia es una forma de diagrama de interacción que muestra los objetos
como líneas de vida a lo largo de la página y con sus interacciones en el tiempo
representadas como mensajes dibujados como flechas desde la línea de vida origen hasta la
línea de vida destino. Los diagramas de secuencia son buenos para mostrar qué objetos se
comunican con qué otros objetos y qué mensajes disparan esas comunicaciones. Los
diagramas de secuencia no están pensados para mostrar lógicas de procedimientos
complejos.
Línea de Vida
Una línea de vida representa un participante individual en un diagrama de secuencia. Una
línea de vida usualmente tiene un rectángulo que contiene el nombre del objeto. Si el
nombre es self entonces eso indica que la línea de vida representa el clasificador que posee
el diagrama de secuencia.
Algunas veces un diagrama de secuencia tendrá una línea de vida con un símbolo del
elemento actor en la parte superior. Este usualmente sería el caso si un diagrama de
secuencia es contenido por un caso de uso. Los elementos entidad, control y límite de los
diagramas de robustez también pueden contener líneas de vida.
Mensajes
Los mensajes se muestran como flechas. Los mensajes pueden ser completos, perdidos o
encontrados; síncronos o asíncronos: llamadas o señales. En el siguiente diagrama, el
primer mensaje es un mensaje síncrono (denotado por una punta de flecha oscura),
completo con un mensaje de retorno implícito; el segundo mensaje es asíncrono (denotado
por una punta de flecha en línea) y el tercero es un mensaje de retorno asíncrono (denotado
por una línea punteada).
Ocurrencia de ejecución
Un rectángulo fino a lo largo de la línea de vida denota la ocurrencia de ejecución o
activación de un foco de control. En el diagrama anterior hay tres ocurrencias de ejecución.
El primero es el objeto origen que envía dos mensajes y recibe dos respuestas, el segundo
es el objeto destino que recibe un mensaje asíncrono y retorna una respuesta, y el tercero es
el objeto destino que recibe un mensaje asíncrono y retorna una respuesta.
Mensaje Self
Un mensaje self puede representar una llamada recursiva de una operación, o un método
llamando a otro método perteneciente al mismo objeto. Este se muestra como cuando crea
un foco de control anidado en la ocurrencia de ejecución de la línea de vida.
Mensajes perdidos y encontrados
Los mensajes perdidos son aquellos que han sido enviados pero que no han llegado al
destino esperado, o que han llegado a un destino que no se muestra en el diagrama actual.
Los mensajes encontrados son aquellos que llegan de un remitente no conocido, o de un
remitente no conocido en el diagrama actual. Ellos se denotan yendo o llegando desde un
elemento de punto final.
Inicio y final de línea de vida
Una línea de vida se puede crear o destruir durante la escala de tiempo representada por un
diagrama de secuencia. En el último caso, la línea de vida se termina por un símbolo de
detención, representado como una cruz. En el primer caso, el símbolo al inicio de la línea
de vida se muestra en un nivel más bajo de la página que el símbolo del objeto que causó la
creación. El siguiente diagrama muestra un objeto que fue creado y destruido.
Restricciones de tiempo y duración
En forma predeterminada, un mensaje se muestra como una línea horizontal. Ya que la
línea de vida representa el pasaje de tiempo hacia abajo, cuando se modela un sistema en
tiempo real, o incluso un proceso de negocios en tiempo límite, puede ser importante
considerar el tiempo que toma realizar las acciones. Al configurar una restricción de
duración para un mensaje, el mensaje se mostrará como una línea inclinada.
Fragmentos combinados
Se estableció anteriormente que no se espera que los diagramas de secuencia muestren
lógicas de procedimientos complejos. Siendo este el caso, hay un número de mecanismos
que permiten agregar un grado de lógicas de procedimientos a los diagramas y que a la vez
vienen bajo el encabezado de fragmentos combinados. Un fragmento combinado es una o
más secuencias de procesos incluidas en un marco y ejecutadas bajo circunstancias
nombradas específicas. Los fragmentos disponibles son:
El fragmento Alternative (denotedo “alt”) modela estructuras if…then…else.
El fragmento Option (denotado “opt”) modela estructuras switch.
El fragmento Break modela una secuencia alternativa de eventos que se procesa en
lugar de todo del resto del diagrama.
El fragmento Parallel (denotado “par”) modela procesos concurrentes.
El fragmento de secuenciado Weak (denotado “seq”) incluye un número de
secuencias para las cuales todos los mensajes se deben procesar en un segmento
anterior, antes de que el siguiente segmento pueda comenzar, pero que no impone
ningún secuenciado en los mensajes que no comparten una línea de vida.
El fragmento de secuenciado Strict (denotado “strict”) incluye una serie de
mensajes que se deben procesar en el orden proporcionado.
El fragmento Negative (denotado “neg”) incluye una serie de mensajes inválidos.
El fragmento Critical incluye una sección crítica.
El fragmento Ignore declara un mensaje o mensajes que no son de ningún interés si
este aparece en el contexto actual.
El fragmento Consider es el opuesto del fragmento Ignore: cualquier mensaje que
no se incluya en el fragmento Consider se debería ignorar.
El fragmento Assertion (denotado “assert”) designa que cualquier secuencia que no
se muestra como un operando de la aserción es inválida.
El fragmento Loop incluye una serie de mensajes que están repetidos.
El siguiente diagrama muestra un fragmento loop.
También hay una ocurrencia de interacción, que es similar a un fragmento combinado. Una
ocurrencia de interacción es una referencia a otro diagrama que tiene la palabra “ref” en la
esquina izquierda arriba del marco, y tiene el nombre del diagrama referenciado que se
muestra en el medio del marco
Puerta
Una puerta es un punto de conexión para conectar un mensaje dentro de un fragmento con
un mensaje fuera del fragmento. EA muestra una puerta como un cuadro pequeño en un
marco del fragmento.
Descomposición en parte
Un objeto puede tener más de una línea de vida que viene de ésta. Esto permite mensajes de
entre e intra objetos para que se muestren en el mismo diagrama.
Continuaciones / Invariantes de Estado
Una invariante de estado es una restricción ubicada en una línea de vida que debe ser
verdadera en el tiempo de ejecución. Esta se muestra como un rectángulo con los extremos
en semi-circulos.
Una continuación tiene la misma notación que una invariante de estado pero se usa en
fragmentos combinados y puede extenderse a través de más de una línea de vida.
