DIAGRAMA DE CLASES DE ANALISIS Y DIAGRAMA DE COLABORACION

Presentación del tema: "DIAGRAMA DE CLASES DE ANALISIS Y DIAGRAMA DE COLABORACION"— Transcripción de la presentación:

1 DIAGRAMA DE CLASES DE ANALISIS Y DIAGRAMA DE COLABORACION
INGENIERIA DE SOFTWARE DIAGRAMA DE CLASES DE ANALISIS Y DIAGRAMA DE COLABORACION Ing. Sanchez Castillo Eddye Arturo Sesión 11

2 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo
Temario ... Diagramas de Clases de Análisis Diagramas de Colaboración Diagrama de Paquetes Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

3 Modelado basado en Clases
¿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álisis Examinar 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. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos.

4 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. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos.

5 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: 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. Servicios requeridos. La clase potencial debe tener un conjunto de operaciones identificables que puedan cambiar el valor de sus atributos de alguna manera. 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. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos.

6 Modelado basado en Clases
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. 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. 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. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos.

7 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. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos.

8 operaciones que realizan un cómputo,
Definición de operaciones Las operaciones definen el comportamiento de un objeto. Grandes categorías: operaciones que manipulan los datos de alguna manera (por ejemplo, al agregar, borrar, reformatear, seleccionar), operaciones que realizan un cómputo, operaciones que preguntan acerca del estado de un objeto, y 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. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos.

9 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. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos.

10 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. Estereotipos del UML para representar una Clase: Clase entidad Clase borde o límite Clase control

11 Diagrama de Clases Ejemplos
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: Clase Cuenta Bancaria Clase Cuenta Bancaria saldoDelaCuenta depósito() retiro() Ejemplos 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 Bancaria Cuando no hay ambigüedad, UML permite usar, una notación más breve: cuenta bancaria

12 Diagramas de Colaboraciones
Las 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 : la relación es-parte-de, la relación tiene-conocimiento-de, y 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. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos.

13 Relaciones entre Clases
Asociaciones y dependencias En 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. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos.

14 Diagramas de Colaboraciones
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. Clase Automóvil Ejemplos Clase Chasis Clase Motor Clase Llantas Clase Asientos “Un automóvil se compone de un chasis, un motor, llantas y asientos”

15 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. Clase Automóvil Ejemplos * * Clase Chasis Clase Motor Clase Llantas Clase Techo Corredizo Clase Dados Clase Asientos “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”

16 Diagramas de Colaboraciones Clase Tablero de Ajedrez
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

17 Diagramas de Colaboraciones
Generalización La herencia es una función de la OO y es un caso especial de generalización. Clase Activo Ejemplos tipoDeActivo Clase Hipoteca Clase Inversión 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

18 Ejemplos Generalización
Es 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

19 Diagramas de Colaboraciones
Asociación Hay 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. Clase Cantante Clase Odontólogo servicio Clase Odontólogo Clase Cantante servicio Ejm. Una asociación Clase Servicios Ejemplos fechaDeServicio tipoDeServicio Ejm. Una clase de asociación

20 Asociación La 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. Ejemplos

21 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.

22 Diagrama de Paquetes 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

23 Hacia el Modelo de Diseño
Arquitectura de aplicación del SW Interfaz con el usuario Funcionalidad general del sistema (aplicando SW, HW, Datos, Humanos) Modelo de Diseño Modelo de Análisis Estructura en el nivel de componentes Descripción del sistema (llena el vacío entre una descripción al nivel de sistemas y el diseño de software) Y, otros elementos del sistema (Ejm: seguridad, rendimiento)

24 Análisis y Diseño de Sistemas
Fin de la Presentación GRACIAS Análisis y Diseño de Sistemas