I NGENIERÍA DE S OFTWARE L ABORATORIO VI Diseño - Diagrama de clases Eduardo Saavedra A. 07/10/2009.

Presentación del tema: "I NGENIERÍA DE S OFTWARE L ABORATORIO VI Diseño - Diagrama de clases Eduardo Saavedra A. 07/10/2009."— Transcripción de la presentación:

1 I NGENIERÍA DE S OFTWARE L ABORATORIO VI Diseño - Diagrama de clases Eduardo Saavedra A. 07/10/2009

2 T ÓPICOS 1. ¿ Qué es un diagrama de Clases? 2. Conceptos 1. Clase 2. Atributo 1. Visibilidad 2. Tipo de dato 3. Operación (Método) 4. Relaciones 3. Como confeccionar un modelo de clases

3 ¿ Q UÉ ES UN DIAGRAMA DE CLASES ?

4 Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro. Fuente: Wikipedia

5 C LASE Similares Conceptos: Una clase es una entidad que representa la abstracción a la realidad que se quiere representar. Descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Una clase es una plantilla o un prototipo para crear objetos. Nombre de clase – Comienza en mayúscula. Nombre de atributo Tipo de dato de atributo Operaciones Visibilidad

6 A TRIBUTO Los atributos son las características particulares de las clases y describe un rango de valore que se podrá contener en los objetos. 1. Visibilidad 1. Publica 1. Cualquier clase externa A con visibilidad hacia la clase B, puede utilizar la característica (atributo) de la clase la B. 2. Especificación: 1. Rational rose los especifica de esta forma: 2. UML 2.0 la especifica con un signo + antes del atributo (ej: +cantidad : Integer) 2. Protegida 1. Si la clase A tiene un atributo protegido, solo los descendientes pueden utilizar este atributo (herencia). 2. Especificación: 1. Rational rose los especifica de esta forma: 2. UML 2.0 la especifica con un signo # antes del atributo (ej: #cantidad : Integer) 3. Privada 1. Ninguna clase puede utilizar el atributo excepto la que contiene el atributo. 2. Especificación: 1. Rational rose los especifica de esta forma: 2. UML 2.0 la especifica con un signo - antes del atributo (ej: - tipo : String)

7 A TRIBUTO 2. Tipo de dato 1. Se tratan de utilizar los objetos, o tipos de datos más genéricos: 1. Integer 2. String 3. Boolean 4. Etc 3. Por convención: 1. Si el atributo consta de una sola palabra, se escribirá en minúsculas, pero, si el nombre contiene más de una palabra, cada palabra será unida a la anterior y comenzará con mayúscula a excepción de la primera.

8 O PERACIÓN Modela las características del comportamiento de la clase. Son los métodos de la clase. El nivel de detalle puede ser el que se requiera. Por ejemplo es posible incluso identificar argumentos y retornos. Al igual que los atributos poseen visibilidad. Por convención: Los métodos se escriben igual que los atributos.

9 R ELACIONES Asociación Es la relación “base” de un diagrama de clases. Posee navegación y cardinalidad (Al igual que un diagrama E/R de base de datos!) Clases Estas clases nacen cuando se necesita mantener información relevante de una asociación.

10 R ELACIONES Clase de asociación:

11 R ELACIONES Agregación – Composición La agregación se utiliza cuando una clase “contiene” a la otra La composición da al mismo concepto pero más “fuerte” Generalización Se basa en la herencia de clases Todo Partes

12 C OMO CONFECCIONAR UN MODELO DE CLASES Es posible generar el modelo de clases en base al modelo de casos de uso. El modelo de casos de uso representa una perspectiva relativamente abstracta de lo que se implementará. Además, entrega información relevante de cómo se comportará el sistema, tanto desde el punto de vista de negocio como funcionalidad. En base a este punto, es posible identificar las clases que inciden y participan en el transcurso de los escenarios de los casos de uso. Se debe pensar además en la información relevante que ha de ser mantenida en el tiempo.

13 B IBLIOGRAFÍA I. Jacobson J. Rumbaugh and G. Booch. El Lenguaje Unificado de Modelado. Addison-Wesley, 2000. Roger S. Pressman. Ingeniería del Software. MC Graw Hill, 2000, Sexta Edición. Wikipedia: http://es.wikipedia.org/wiki/Diagrama_de_clases