Sesión 11

DIAGRAMA DE CLASES DE ANALISIS Y DIAGRAMA DE

COLABORACION

INGENIERIA DE SOFTWARE

Ing. Sanchez Castillo Eddye Arturoeddiesanchez0710@gmail.com

www.ceneinnova/eddyesanchez

Temario ...

• Diagramas de Clases de Análisis

• Diagramas de Colaboración

• Diagrama de Paquetes

Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo02

¿Qué se debe hacer para desarrollar los elementos basados en clases de un modelo de análisis: clases y objetos, atributos, operaciones, paquetes, y diagramas de colaboración?

Identificación de clases de análisisExaminar el enunciado del problema (“análisis gramatical”) sobre las narrativas desarrolladas para el sistema que se va a construir o de los CdU.Las clases se determinan al reconocer cada sustantivo. Las clases se manifiestan en una de las siguientes formas:• Entidades externas (como, otros sistemas, dispositivos, personas)

que producen o consumen información que usará un sistema. • Cosas (por ejemplo, reportes, despliegues, letras, señales) que son

parte del dominio de la información para el problema.

Modelado basado en Clases

• Sucesos o eventos (como, una transferencia de propiedad) que ocurren dentro del contexto de la operación del sistema.

• Roles (por ejemplo, gerente, ingeniero, personal de ventas) que desempeñan personas que interactúan con el sistema.

• Unidades organizacionales (ejem, división, grupo) relevantes para alguna aplicación.

• Sitios (como, el piso de manufactura o el puerto de carga) que establecen el contexto del problema y la función global del sistema.

• Estructuras (por ejemplo, sensores, vehículos de cuatro ruedas o computadoras) que definen una clase de objetos o clases de objetos relacionadas.

Modelado basado en Clases

Coad y Yourdon sugieren seis características de selección que se deben usar cuando un analista considera cada clase potencial para incluirlas en el modelo de análisis:

1. Información referida. La clase potencial será útil durante el análisis sólo si la información acerca de ella debe recordarse para que el sistema pueda funcionar.

2. Servicios requeridos. La clase potencial debe tener un conjunto de operaciones identificables que puedan cambiar el valor de sus atributos de alguna manera.

3. Atributos múltiples. Durante el análisis de requisitos el enfoque debe estar en la información “importante”; una clase con un solo atributo puede, de hecho, ser útil durante el diseño, pero probablemente es mejor representarla como un atributo de otra clase durante la actividad de análisis.

Modelado basado en Clases

4. Atributos comunes. Es posible definir un conjunto de atributos para la clase potencial, y estos atributos pueden aplicarse en toda las instancias de la clase.

5. Operaciones comunes. Es posible definir un conjunto de operaciones para la clase potencial, y estas operaciones pueden aplicarse en todas las instancias de la clase.

6. Requisitos esenciales. Las entidades externas que aparecen en el espacio del problema, y que producen o consumen información esencial para la operación de cualquier solución para el sistema, se definirán casi siempre como clases en el modelo de requisitos.

Modelado basado en Clases

Especificación de atributos

Los atributos describen una clase que ha sido seleccionada para incluirla en el modelo de análisis.En esencia, los atributos son los que definen la clase, lo cual clarifica qué significa la clase en el contexto del espacio del problema.

Modelado basado en Clases

Definición de operacionesLas operaciones definen el comportamiento de un objeto.

Grandes categorías:

1) operaciones que manipulan los datos de alguna manera (por ejemplo, al agregar, borrar, reformatear, seleccionar),

2) operaciones que realizan un cómputo,3) operaciones que preguntan acerca del estado de un objeto, y4) operaciones que monitorean un objeto para la ocurrencia de

un evento de control.

Como una primera iteración en la obtención de un conjunto de operaciones para una clase de análisis, el analista puede estudiar otra vez la narrativa de un procesamiento (o caso de uso) y seleccionar aquellas operaciones que pertenezcan de manera razonable a la clase. Esto se logra estudiando de nuevo el análisis gramatical y aislando los verbos.

Clases Categorías de clases:

• Clases de entidad, también llamadas clases de modelo o negocios, se extraen de manera directa del enunciado del problema

De manera típica, estas clases representan clases que se almacenarán en una base de datos y que persisten durante la aplicación.

• Clases de frontera. Se utilizan para crear la interfaz (por ejemplo, pantallas interactivas o reportes impresos) que el usuario ve y con la cual interactúa cuando se utiliza el software.

Las clases de frontera están diseñadas para manejar la forma en que los objetos de entidad se presentan a los usuarios.

• Las clases de controlador manejan una “unidad de trabajo” desde el inicio hasta el final. Esto es, las clases de controlador se pueden diseñar para manejar:

1) la creación o actualización de los objetos de entidad; 2) la inmediatez de objetos de frontera conforme éstos obtienen información de objetos de entidad; 3) la comunicación compleja entre conjuntos de objetos; y 4) la validación de datos comunicados entre los objetos o entre el usuario y la aplicación.

Categorías de Clases: entidad, borde y control• Una clase entidad es un modelo de la información perdurable. Ejm. La Clase Cuenta es una entidad porque la información sobre las cuentas tiene que permanecer en el S.I. Bancario.

• Una clase borde (límite) modela la interacción entre el S.I. y sus actores. Generalmente, se asocia con la entrada y la salida. Ejm. Una Interfaz de Usuario y los Reportes de Estado de Cuenta del cliente

• Una clase control es un modelo de los cálculos y algoritmos complejos. Ejms. Clase Calcular Monto de Préstamo, Clase Calcular Cuotas a Pagar Las clases control representan coordinación, secuenciado, transacciones y control de otros objetos.

Clase entidad

Estereotipos del UML para representar una Clase:

Clase

borde o límiteClase

control

Diagrama de Clases

• Un diagrama de clases representa las clases y sus interrelaciones. Una clase representa un concepto discreto dentro de la aplicación que se está

modelando: una cosa física, de negocios, lógica, de una aplicación, del computador, o una cosa del comportamiento.

• Son diagramas de clase válidos:

• Esta libertad de notación se hace extensiva a los objetos: Notación UML completa: cuenta bancaria : Clase Cuenta Bancaria

cuenta bancaria es un objeto, una instancia de una clase denominada Clase Cuenta BancariaCuando no hay ambigüedad, UML permite usar,una notación más breve: cuenta bancaria

Clase Cuenta Bancaria Clase Cuenta Bancaria

saldoDelaCuenta

depósito() retiro()

Ejemplos

Diagramas de ColaboracionesColaboracionesLas colaboraciones identifican las relaciones entre clases. Para ayudarse en la identificación de los colaboradores, el analista puede examinar tres relaciones genéricas diferentes entre las clases :

1) la relación es-parte-de, 2) la relación tiene-conocimiento-de, y 3) la relación depende-de. Todas las clases que son parte de una clase agregada se conectan a ésta a través de una relación del tipo es-parte-de. Cuando una clase debe obtener información de otra clase se establece la relación tiene-conocimiento-de. La relación depende-de implica que dos clases tienen una dependencia que no se logra mediante las relaciones tiene-conocimiento-de o es-parte-de.

Asociaciones y dependenciasEn muchos casos, dos clases de análisis se relacionan entre si de alguna manera parecida a la forma en que se relacionan dos objetos de datos. En UML, estas relaciones se llaman asociaciones.

En algunos casos, una asociación se puede definir en forma más extensa al indicar multiplicidad.

En muchos casos existe una relación cliente-servidor entre dos clases de análisis.En tales casos, una clase de cliente depende de alguna manera de la clase de servidor y se establece una relación dependencia. Las dependencias se definen mediante un estereotipo.

Un estereotipo es un “mecanismo de extensibilidad” dentro del UML que permite a un ingeniero de software definir un elemento de modelado especial cuya semántica define el cliente.

Relaciones entre Clases

• Agregación

La agregación es el término del UML para la relación parte-todo. En la notación gráfica, el diamante se coloca en el extremo del todo.

EjemplosClase Automóvil

Clase Chasis Clase Motor Clase Llantas Clase Asientos

“Un automóvil se compone de un chasis, un motor, llantas y asientos”

Diagramas de Colaboraciones

• Multiplicidad

La agregación es el término del UML para la relación parte-todo. En la notación gráfica, el diamante se coloca en el extremo del todo.

Ejemplos Clase Automóvil

Clase Chasis Clase Motor Clase Llantas Clase AsientosClase Techo Corredizo

Clase Dados

1 1 1 1 1 1

1 1 4 .. 5 0 ..1 * 2 .. *

“Un automóvil se compone de un chasis, un motor, 4 ó 5 llantas, un techo corredizo, cero ó más dados que cuelgan del espejo retrovisor y 2 ó más asientos”

Diagramas de Colaboraciones

• Composición

La composición es una extensión de la agregación, pero más marcada.

Cuando hay composición, es posible que cada parte pertenezca a un solo todo, y si el todo se borra entonces las partes también se borran.

Ejemplos

Clase Tablero de Ajedrez

Clase Casilla

1 64

Diagramas de Colaboraciones

• Generalización

La herencia es una función de la OO y es un caso especial de generalización.

Ejemplos

Clase Hipoteca Clase Inversión

Clase Activo

tipoDeActivo

Ejemplo de generalización (herencia) con un discriminador explícito.

La notación tipoDeActivo significa que cada instancia de la Clase Activo o sus subclases tiene un atributo tipoDeActivo

Diagramas de Colaboraciones

• GeneralizaciónEs la relación en la que un elemento de un tipo específico (subclase o hijo) hereda los atributos y el comportamiento de un elemento general (superclase ó padre)

Ejemplos

AsociaciónHay casos donde la asociación entre dos clases puede por si misma requerir que se modele como una clase.Ejm. Un cantante es atendido por un odontólogo en varias ocasiones, en cada una de ellas la atención es por diferentes servicios (curaciones, extracciones, implantes, otros). El modelamiento de la facturación por cada servicio requiere que la asociación servicios se convierta en una clase, la Clase Servicios, que es identificada como una clase de asociación, porque es tanto una asociación como una clase.

Ejemplos

Clase Cantante

Clase Odontólogo

Clase Cantante

Clase Odontólogo

Clase Servicios

servicioservicio

fechaDeServicio

tipoDeServicio

Ejm. Una asociación

Ejm. Una clase de asociación

Diagramas de Colaboraciones

Ejemplos

AsociaciónLa clase Asociación se presenta cuando la propia relación de asociación entre dos clases tiene propiedades. Y, se representa con el símbolo de clase unido por una línea discontinua a una relación de asociación.

Diagrama de Paquetes

Paquete de análisis

Una parte importante del modelado del análisis es la

categorización. Esto es, los diferentes elementos del modelo de

análisis (por ejemplo, casos de uso, clases de análisis) se clasifican

de una manera que los empaquete como una agrupación –

llamada un paquete de análisis-, a la cual se le asigna un nombre

representativo.

Ejemplo.Considere el análisis de un video juego.

Al desarrollar el modelo de análisis para el video juego se obtiene un gran numero de clases. Algunas se enfocan en el ambiente de juego, como las escenas visuales que el usuario ve mientras se desarrolla el juego.

Otras se enfocan en los personajes dentro del juego al describir sus características físicas, acciones y restricciones.

Además, otras describen las reglas del juego: como navega el jugador a través del ambiente. Pueden existir muchas otras categorías. El agrupamiento de estas clases pueden representarse como paquete de análisis. Y, el Diagrama de Paquetes como la visualización de estos paquetes

Diagrama de Paquetes

Hacia el Modelo de Diseño

Descripción del sistema

Modelo de Análisis

Modelo de Diseño

Funcionalidad general del sistema

(aplicando SW, HW,Datos, Humanos)

Y, otros elementos del sistema

(Ejm: seguridad, rendimiento)

Arquitectura de aplicación del SW

Interfaz con el usuario

Estructura en el nivel de componentes

(llena el vacío entre una descripción al nivel de sistemas y

el diseño de software)

Fin de la Presentación

GRACIAS

Análisis y Diseño de Sistemas 024