Está en la página 1de 4

Diagrama de clases

Ejemplo de diagrama de clases de una Universidad. 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. Representación de: - Requerimientos en entidades y actuaciones. - La arquitectura conceptual de un dominio - Soluciones de diseño en una arquitectura - Componentes de software orientados a objetos

[editar] YESTER

Propiedades también llamados atributos o características, son valores que corresponden a un objeto, como color, material, cantidad, ubicación. Generalmente se conoce como la información detallada del objeto. Suponiendo que el objeto es una puerta, sus propiedades serían: la marca, tamaño, color y peso. Operaciones comúnmente llamados métodos, son aquellas actividades o verbos que se pueden realizar con/para este objeto, como por ejemplo abrir, cerrar, buscar, cancelar, acreditar, cargar. De la misma manera que el nombre de un atributo, el nombre de una operación se escribe con minúsculas si consta de una sola palabra. Si el nombre contiene más de una palabra, cada palabra será unida a la anterior y comenzará con una letra mayúscula, a excepción de la primera palabra que comenzará en minúscula. Por ejemplo: abrirPuerta, cerrarPuerta, buscarPuerta, etc. Interfaz es un conjunto de operaciones que permiten a un objeto comportarse de cierta manera, por lo que define los requerimientos mínimos del objeto. Hace referencia a polimorfismo. Herencia se define como la reutilización de un objeto padre ya definido para poder extender la funcionalidad en un objeto hijo. Los objetos hijos heredan todas las operaciones y/o propiedades de un objeto padre. Por ejemplo: Una persona puede especializarse en Proveedores, Acreedores, Clientes, Accionistas, Empleados; todos comparten datos básicos como una persona, pero además cada uno tendrá información adicional que depende del tipo de persona, como saldo del cliente, total de inversión del accionista, salario del empleado, etc.

Al diseñar una clase se debe pensar en cómo se puede identificar un objeto real, como una persona, un transporte, un documento o un paquete. Estos ejemplos de clases de

por lo que tendrá un número de cuenta. Durante el proceso del diseño de las clases se toman las propiedades que identifican como único al objeto y otras propiedades adicionales como datos que corresponden al objeto. género. dirección postal. moneda en la que se maneja la cuenta. que pueden ser:      Abrir Cerrar Depósito Retiro Acreditar Intereses Estos ejemplos constituyen diferentes clases de objetos que tienen propiedades y/u operaciones que contienen un contexto y un dominio. del móvil. posiblemente también tenga número de teléfono de casa. la herencia de propiedades de otro objeto. El diagrama de clases incluye mucha más información como la relación entre un objeto y otro. apellidos. . Con los siguientes ejemplos se definen tres objetos que se incluyen en un diagrama de clases: Ejemplo 1: Una persona tiene número de documento de identificación.objetos reales. dónde las operaciones bancarias de una cuenta (como en el ejemplo 2) se manejarán realizando diferentes operaciones que en el diagrama de clases de balurdes sólo se representan como operaciones. Ejemplo 2: Un sistema informático puede permitir administrar la cuenta bancaria de una persona. Ejemplo 3: Otro objeto pueden ser "Manejo de Cuenta". los primeros dos ejemplos son clases de datos y el tercero clase de lógica de negocio. fecha de nacimiento. saldo actual. nombres. es sobre lo que un sistema se diseña. conjuntos de operaciones/propiedades que son implementadas para una interfaz gráfica. FAX y correo electrónico. dependiendo de quién diseñe el sistema se pueden unir los datos con las operaciones. número de identificación del propietario de la cuenta.

UML no define estándares para que el formato escrito describa los casos de uso. Veamos una revisión de ellas a continuación: [editar] Inclusión (include o use) Es una forma de interacción o creación. Esta relación indica que el comportamiento del caso de la extensión se utiliza en casos de uso. Aqui tambien podemos decir que éste va de padre a hijo. un caso de uso dado puede "incluir" otro. con la etiqueta "«include»". desde el caso de uso. desde el caso de uso extensión al caso de uso extendido. El primer caso de uso a menudo depende del resultado del caso de uso incluido. los casos de uso son mucho más detallados que los diagramas de casos de uso. es una flecha de punta abierta con línea discontinua. [editar] Extensión (Extend) Es otra forma de interacción. un caso de uso a otro caso siempre debe tener extensión o inclusión. Esto es útil para extraer comportamientos verdaderamente comunes desde múltiples casos de uso a una descripción individual. o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensión . UML mejorado El Lenguaje de Modelado Unificado define una notación gráfica para representar casos de uso llamada modelo de casos de uso. . Relaciones de Casos de Uso Las tres relaciones principales entre los casos de uso son soportadas por el estándar UML. Mientras la notación gráfica y las descripciones son importantes. un caso de uso dado (la extensión) puede extender a otro.DIAGRAMA DE CASOS DE USO En el Lenguaje de Modelado Unificado. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. La notación es de una flecha de punta abierta con línea discontinua desde el caso de uso que lo incluye hasta el caso de uso incluido. Mucha gente sufre la equivocación pensando que un caso de uso es una notación gráfica (o es su descripción). pero no el formato para describir casos de uso. La notación. Mientras los dos conceptos están relacionados. sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. con la etiqueta «extend». El caso de uso extensión puede ser insertado en el caso de uso extendido bajo ciertas condiciones. y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso. ellos forman parte de la documentación de un caso de uso --un propósito para el que el actor puede usar el sistema. Este uso se asemeja a una expansión de una macro. No hay parámetros o valores de retorno. el cual describe notación gráfica para esas relaciones. Esto puede ser útil para lidiar con casos especiales. donde el comportamiento del caso incluido es colocado dentro del comportamiento del caso de uso base. El estándar de Lenguaje de Modelado Unificado de OMG define una notación gráfica para realizar diagramas de casos de uso. un diagrama de casos de uso es una especie de diagrama de comportamiento.

es el conjunto de objetos a los que se aplica un concepto. Esto se asemeja al concepto orientado a objetos de sub-clases. Las subclases conceptuales son conformes con las superclases conceptuales en cuanto a la intención y extensión. La notación es una línea sólida terminada en un triángulo dibujado desde el caso de uso especializado al caso de uso general."La extensión. Es una manera de construir clasificaciones taxonómicas entre conceptos que entonces se representan en jerarquías de clases. y enfrentarse a los detalles excepcionales en los casos de uso especializados." [editar] Generalización "Entonces la Generalización es la actividad de identificar elementos en común entre conceptos y definir las relaciones de una superclase (concepto general) y subclase (concepto especializado). describirlos una vez. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. existe una relación generalización/especialización." En la tercera forma de relaciones entre casos de uso. en la práctica puede ser útil factorizar comportamientos comunes. . restricciones al caso de uso general. Los objetos de la extensión son los ejemplos o instancias de los conceptos.