5 - Curso Arquitecturas - Clases 494462

Curso de Arquitecturas de Software

Programación Orientada a Objetos Diagramas de Clases y el Modelo Conceptual

Diagramas de Clases

Modelo de Análisis (Modelo Conceptual) „

„ „

Diagramas de Clase „

„

„

Un diagrama de clases muestra un resumen de un sistema mostrando sus clases y las relaciones entre ellas. Son los diagramas más comunes en el modelado de sistemas orientados a objetos.

Explica los conceptos más significativos del dominio del problema, identificando los atributos y las asociaciones, y es el modelo más importante del análisis orientado a objetos. Representa cosas del mundo real, no componentes del software En UML se representa mediante un grupo de diagramas de estructura estática

„ „ „

Son estáticos, muestran que elementos interactúan pero no que sucede cuando ellos hacen la interacción. Contiene elementos esenciales para entender la vista del problema. Visualización, Especificación y documentación del modelo estructural Construcción „

Diagrama de Clases Contenido „

Un diagrama de clases contiene básicamente: „ „ „ „ „ „ „

Clases Relaciones Interfaces Dependencias Navegabilidad, multiplicidad, roles Restricciones Notas de comentarios, aclaración.

Ingeniería hacia adelante e ingeniería inversa.

Clases „

La notación de clase de UML es un rectángulo dividido en tres partes : Nombre de la clase: cada clase tiene un nombre único (La convención son nombres en mayúscula combinada y en singular) „ Atributos : Características ó propiedades de la clase. „ Operaciones: qué puede hacer la clase. „

1

Clases „

En cuanto a visibilidad, la clase puede ser pública, en cuyo caso se declara public, de otro modo sólo se conocerá en el archivo donde se encuentre. También existe visibilidad a nivel de paquete.

Operaciones „

Las operaciones tienen la forma: <nombre> (<lista de parámetros)> : La lista de parámetros tiene el tipo del parámetro y el nombre, y van separados por comas.

„

La visibilidad puede ser : „ „ „

„

+ : publica - : privada # : protegida

Puede existir visibilidad a nivel de paquetes

Operaciones

Atributos

Las operaciones pueden ser:

„

Los atributos tienen la forma:

„

La visibilidad del atributo aparece al comienzo:

Estáticas: esto es, se pueden utilizar sin instanciar un objeto, en el diagrama estas operaciones van subrayadas

<nombre> „

„ „

„

Constructores: llevan el mismo nombre de la clase y pueden tener sobrecarga. Métodos Modificadores (métodos set ) que cambian el valor de un atributo. (no se muestran en el diagrama). Métodos Analizadores (métodos get ) que devuelven el valor de un atributo. (no se muestran en el diagrama).

Atributos

„ „

„ „ „

+ : publica - : privada # : protegida

El atributo puede tener un valor inicial. Puede existir visibilidad a nivel de paquetes Si el atributo es estático va subrayado.

Clase en UML Order

Se deben evitar los atributos públicos por que violan el concepto de encapsulamiento „ Una clase puede tener cualquier número de atributos o no tenerlos „

-status:int -date:String +calcTotal:double +calcTax:double +cancel:void

2

Relaciones „ „ „

Las relaciones entre las clases son los links conectándolos. Recuerde: las relaciones se convertirán en atributos de las clases. Existen varias clases de relaciones: „ „ „ „ „

„

Asociación Agregación Composición Generalización ( Herencia) Dependencia

Asociación „ „

„

Una relación entre instancias de dos clases Hay una asociación entre dos clases si una instancia de una clase debe conocer de la otra para poder ejecutar su trabajo Es una conexión bidireccional , esto es, ambas se conocen. Sin embargo es deseable restringir la navegación a una dirección (ver navegabilidad).

Las relaciones tienen roles, cardinalidad, navegabilidad, calificadores

Asociación Se presenta cuando dos clases son independientes „ Pueden existir relaciones de asociación entre la misma clase „ En un diagrama se representa como un línea conectando dos clases „

Asociación „

Otros ejemplos: Universidad – Estudiante Persona – Compañía „ Persona – Persona „ Departamento – Profesor „ Biblioteca - Libro

Asociación En el siguiente ejemplo la clase Orden conoce el cliente y el cliente conoce sus órdenes Order Customer -name:String -address:String

1

0..*

+calcTotal:double +calcTax:double +cancel:void

Cardinalidad „

„ „

-status:int -date:String

„

La cardinalidad o multiplicidad de una relación es el número de posibles instancias de la clase asociada con una instancia de la otra clase. Las cardinalidades pueden ser: 0..1 n..m 0..* 1 1..* 2,4,6

Cero o una instancia n a m instancias Sin límite de instancias incluido 0 Exactamente una instancia Al menos una instancia Exactamente 2,4 o 6 instancias

3

Navegabilidad (Direccionalidad)

Cardinalidad La cardinalidad >= 1 establece una restricción de existencia. „ En el ejemplo anterior una orden tiene un cliente, y el cliente puede tener 0 ó más ordenes sin límite. „

Navegabilidad

+calcWeight:double +calcSubTotal:double

„ „

Navegabilidad „

OrderDetail -taxStatus:int -quantity:int

Item 0..*

1

-description:String +priceForQuantity:double

Roles y Calificadores „

„

„

Muestra en cual dirección la asociación puede ser recorrida ó consultada Indica quien es el propietario de la implementación de la asociación Las asociaciones sin flechas de navegabilidad son bidireccionales

„

Una relación define roles que juega cada clase: Ej: una persona es empleado de una compañía, una compañía es el empleador de una persona. Una relación tiene dos puntos finales, estos pueden tener un nombre de rol para clarificar la naturaleza de la asociación. Los calificadores describen la relación. Por ejemplo un cliente “tiene” muchas ordenes y una orden “está asociada” a un cliente. Un médico conoce a sus pacientes, una biblioteca guarda libros. Persona trabaja para la compañía.

En el ejemplo anterior, una detalle de orden puede ser consultado sobre su ítem (producto), pero no al contrario, el ítem no sabe de que detalle de orden es, pero el detalle de orden sabe sus productos.

Roles y Calificadores „

„

„

Los roles y los calificadores junto con la navegabilidad son opcionales y se colocan en el diagrama para clarificarlo. Otro ejemplo: Hombre y Mujer, los roles serían el hombre es el marido y la mujer es la esposa, los calificadores serían un hombre “tiene” una mujer y una mujer “tiene” un hombre. Se puede tener un solo calificador con dirección para la relación. Por ejemplo, si se tiene una clase aerolínea y una clase vuelo se podría tener un calificador “programa” desde aerolínea a vuelo.

4

Relación de Composición Agregación

Roles y Calificadores

„ Person

Person *

Creates Workorders

Son relaciones de asociación especializadas y están relacionados con los conceptos de: „ „

Person

inspector Creates Workorders * repairperson

Person

Relación de Agregación „

„ „ „ „

„

Relación de Agregación

Una asociación en la cual una clase pertenece a una colección, un objeto es “parte de” un todo. (tiene – un) Distingue una parte de un todo. La multiplicidad en el todo es diferente de 1. Una agregación tiene una punta de diamante sin rellenar hacia la parte que contiene el todo. En el siguiente ejemplo un equipo tiene una colección de personas, ó está conformado por personas.

Relación de Agregación „

„

Otros ejemplos: Polígono – Punto „ Compañía – Departamento „ Edificio - Apartamento „ Almacén - Cliente

Todo/una parte Consiste de Está formado por Tiene un

Equipo

Persona 0..*

est・conformado

1..*

Relación de Composición „

„

„

Es una asociación fuerte (pertenencia fuerte) en la cual la parte pertenece a un todo, ella no puede existir sin el todo El tiempo de vida del todo es por lo general igual que el de la parte Pertenece al objeto con que se relaciona, nace y muere con él (dependencia existencial)

5

Relación de Composición „

„ „

Los objetos contenidos no son compartidos, esto es, no hacen parte del estado de otro objeto La multiplicidad en el lado todo es 0,1 y en el lado parte un intervalo. La composición es denotada por una punta de diamante rellena hacia la parte del todo.

Relación de Composición „

Relación de Composición Order

Almacén – Cuentas Departamento – Habitación „ Carro – Ruedas „ Mano - Dedos „

„

„ „

Payment

Relación de Generalización „

Ejemplo 1 „ „

Credit

Cash -cashTendered:double

Check -name:String -bankId:long

+calcWeight:double +calcSubTotal:double

Indica que una clase es una superclase de otra (es – un) Implica el factorizar las propiedades comunes de un conjunto de clases en una clase más general La generalización tiene un triángulo apuntando a la superclase En el siguiente ejemplo pago es una superclase de efectivo, cheque y crédito.

-amount:double

-number:int -type:String -expDate:String

1..*

Relación de Generalización

„

Relación de Generalización

-taxStatus:int -quantity:int 1

+calcTotal:double +calcTax:double

„

Otros ejemplos:

OrderDetail

-status:int -date:String

„

Superclase: trabajador Subclases: directivo, istrativo, servicios.

Ejemplo 2 „ „

Superclase: vehículo Subclase: barco, avión, camión.

+authorized:boolean +authorized:boolean

6

Relación de Generalización ƒ

El Principio de Sustitución de Liskow (1987) afirma que: “Debe ser posible utilizar cualquier objeto instancia de una subclase en el lugar de cualquier objeto instancia de su superclase sin que la semántica del programa escrito en los términos de la superclase se vea afectado.”

Relación de Dependencia „

En el siguiente ejemplo la clase Operaciones de compañía depende de compañía, cuando la última cambie aquella también debe cambiar.

Relación de Dependencia „ „

„

„

Es una relación entre dos clases en la cual un cambio en una puede forzar cambios en la otra. Relación entre dos cosas en la cual el cambio de una de las cosas (la parte independiente) afecta la semántica de la otra cosa (parte dependiente) Por lo general ocurre cuando la clase independiente es utilizada (como parámetro) o creada dentro de un método de la clase dependiente. La clase dependiente no es un atributo de la clase independiente

Paquetes Son usados para agrupar elementos Observe las relaciones de dependencia entre los paquetes representados por la flecha punteada Un paquete depende de otro si al cambiar uno de ellos cambia el otro.

„ „

„ Compania -nombre:String

OperacionesCompania -semestre:int +tomarCompania:Compania

Paquetes

Identificando Clases

A su vez los paquetes pueden dividirse en otros paquetes, por ejemplo, el paquete de negocio podría dividirse en los paquetes de compra, venta, inventario.

„ „

„ Modelo del Mundo

Presentacion

Revise los requerimientos capturados en el diagrama de casos de uso Extraiga los nombres: Nombre común Æ podría identificar a una Clase, por ejemplo Profesor. Elimine nombres que: „ „

Persistencia

„

Son redundantes Representan instancias: un nombre propio podría identificar a un Objeto (Julio) No son necesarios en la aplicación, esto es, son irrelevantes.

7

Identificando Clases Categoría

Identificando Clases (cont) Ejemplo Categoría

Ejemplo

Objetos Tangibles o Físicos

Registro, Avion

Especificaciones, Diseños o Descripciones de las Cosas

EspecificaionDelProducto DescripcionDelVuelo

Procesos (Normalmente no se representan como conceptos, pero podría ocurrir)

VentadeUnProducto ReservaUnAsiento

Lugares

Tienda

Reglas y Políticas

Transacciones

Venta, Pago, Reserva

PoliticaDeReintegro PoliticaDeCancelacion

Catálogos

CatalogoDeProductos CatalogoDePiezas

Registros de Finanzas, Trabajo, Contratos, Cuestiones Legales

Recibo, LibroMayor, ContratoEmpleo, RegistroMantenimiento

Grupos de Transacciones

Factura

Roles de Personas

Cajero, Piloto

Contenedores de Otras Cosas

Tienda, Lata ,Avion

Cosas en un Contenedor

Articulo, Pasajero

Otros Sistemas Externos al Sistema

SistemaAutorizacionCredito

Instrumentos y servicios Financieros

LineaDeCredito, Stock

Conceptos Abstractos

Ansia, Acrofobia

Organizaciones

DepartamentoVentas

Manuales, documentos, Artículos de Referencia, Libros

ListaDeCambiosDePreciosDiarios ManualReparaciones

Hechos

Venta, Pago, Reunion, Vuelo, Colision

Identificando Clases y Relaciones entre Clases „ „ „

Los actores pueden indicar posibles clases. Los tipos de actores pueden indicar posibles relaciones de herencia. Una relación podría existir entre las clases, si una clase: „ „ „ „ „ „ „ „ „

„

Identificando Atributos

Posee Controla Está conectada a Está relacionada con Es parte de Tiene como partes a Es miembro de Tiene como a Es un tipo de

„ „ „ „

Los verbos podrían indicar operaciones de las clases

Identificando Atributos

Verifique la información que debe mantenerse en cada clase. Verifique características de la clase. Nombres que se descartaron como clases pueden ser atributos. Un atributo debe ser atómico, esto es debe tener un sólo valor, los atributos multivaluados deben ser creados en otra clase. Por ejemplo si un persona tiene muchas direcciones, veamos las posibles alternativas de clases

Ejemplo Asociación Customer

Person

Person

Person

name addresses

name street1 municipality1 provOrState1 country1 postalCode1 street2 municipality2 provOrState2 country2 postalCode2

name

Bad due to a plural attribute

Bad due to too many attributes, and inability to add more addresses

Address

* addresses *

rentedVideos: List of Video

street municipality provOrState country postalcode type

Good solution. The type indicates whether it is a home address, business address etc.

Video

Worse

Customer Better

...

1

renter : Customer

Rents4

1..*

Video ...

8

Ejemplo Completo VideoStore Modelo del Dominio

Ejemplo Sencillo

Pays-for-overdue-charges 4 VideoRental CashPayment

RentalTransaction 1 date 1

Pays-for 4 1

1

amount : Money

*

1

*

Initiates 4 1

1

Rents4

Customer address name phoneNumber

1..*

VideoStore Rents-from 4

*

1

address name phoneNumber

Video

Stocks4 1

*

ID

Records-rental-of 6

1

Rents4

Customer

1..*

VideoStore Rents-from 4 address name 1 phoneNumber

address name phoneNumber

1 Maintains6

Video

Stocks4 1

*

1 Has 6

*

ID

1

*

*

1 Owns-a 4 1

1

*

hip

Catalog

ID startDate

1 Described-by 6

1

1..* VideoDescription

LoanPolicy perDayRentalCharge perDayLateCharge 1..*

0..1

dueDate returnDate returnTime

1..*

1

Defines3 1..*

1

title subjectCategory Determines-rental-charge 4

Referencias „ „

„ „

Larman C., “UML y Patrones”, Prentice Hall, Segunda Edición, 2003 Bruegge B., “Ingenieria de Software Orientada a Objetos,” Ed. Prentice Hall, Mexico 2002 www.omg.org (Object Modeling Group) www.bruceeckel.com (Página oficial de Bruce Eckel)

9