Parte I: Introducción al Java 2 Enterprise Edition Ignacio Ramos Zapata Departamento de Ingeniería Telemática Universidad Carlos III de Madrid nacho_ramos@it.uc3m.es
Introducción Contenido Evolución de las aplicaciones Web Arquitecturas cliente-servidor y multi-tier Integración de aplicaciones corporativas: la plataforma Java 2, Enterprise Edition (J2EE) Diagramas de clases en UML 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 2
Requisitos de las aplicaciones empresariales Almacenamiento y acceso de datos (Back-end integration): empleo de sistemas de bases de datos (DBMS), conexión a la base de datos, representación de los datos en la base de datos Mapping de datos y persistencia: representación de los datos en los programas (clases) y correspondencia (mapping) con su representación en la base de datos, actualización de la base de datos tras cambios por el programa Consistencia de datos: control de acceso concurrente a los datos, monitores de transacción Interacción con el usuario: autentificación, control de acceso, coordinación de accesos concurrentes Acceso a datos comunes: aislamiento de los distintos accesos, cache de datos 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 3
Requisitos de las aplicaciones empresariales Performance: tiempo de respuesta, interacción eficiente entre los distintos componentes Escalabilidad: posibilidad de incorporar nuevos servidores, distribución de carga Disponibilidad: seguridad frente a caídas de la aplicación (ideal disponibilidad 24 x 7), sistemas de tolerancia a fallos, clustering de servidores y datos Diseño software: mantenibilidad y portabilidad? modularidad, diseño en niveles, reducción de dependencias externas (por ejemplo, en la base de datos) 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 4
Evolución de las aplicaciones Web - Contenido estático Las organizaciones pretenden ofrecer información a tantos clientes como sea posible Gracias a la web, se puede mostrar información en páginas HTML estáticas almacenadas en el File System 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 5
Evolución de las aplicaciones Web - CGIs Extensiones (plug-ins) a los servidores Web que invocan aplicaciones de servidor Scripts CGI-BIN: No proporcionan encapsulación estructurada de los procesos y entidades de negocio Difíciles de desarrollar, mantener y gestionar Mezclan la lógica de negocio con la lógica de presentación Difícil mantenimiento de las reglas de negocio (distribuidas por varios cgi-bins en varios servidores) 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 6
Evolución de las aplicaciones Web - Applets Usando páginas HTML estáticas, los usuarios ven páginas pasivas que no cambian Usando Applets Java u otros programas en el lado cliente se pueden producir contenidos dinámicos 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 7
Evolución de las aplicaciones Web - Servlets Los applets no pueden acceder directamente a la información de los back-end systems El Web Container puede proporcionar componentes en el servidor (p.e. Servlets) para generar contenidos dinámicos 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 8
Evolución de las aplicaciones Web - JSPs Pobre separación entre lógica de negocio y lógica de presentación Esta separación se mejora con las JSPs y los JavaBeans 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 9
Evolución de las aplicaciones Web - EJBs EJBs: Se puede acceder a ellos remotamente a través de la red Encapsulan reglas de negocio, lógica específica de aplicación y acceso a datos Pueden ser usados por diferentes aplicaciones de manera concurrente Representan un repositorio central de lógica de negocio 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 10
Evolución de las aplicaciones Web - Escalabilidad Las aplicaciones empresariales suelen requerir alta disponibilidad Incremento en el rendimiento a medida que crece el negocio Estos dos requerimientos se pueden alcanzar incrementando el nº de servidores: Para proporcionar redundancia en el sistema Compartiendo la carga para aumentar el rendimiento 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 11
El patrón MVC: Model-View-Controller Es un patrón para el diseño de aplicaciones Ampliamente extendido como un concepto clave en el desarrollo de aplicaciones J2EE Aporta grandes beneficios (veremos más adelante) Facilita la reutilización de código Reduce el tiempo de desarrollo The Model Representa los datos y la lógica de negocio No contiene información acerca de la interfaz de usuario The View La interfaz de usuario - aquello que ve el usuario y a lo que puede responder Representa una ventana dentro del modelo The Controller Conecta el modelo y la vista Se usa como comunicación entre el modelo y la vista En ocasiones aparece una cuarta capa de persistencia - que se añade al patrón 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 12
MVC Aplicación J2EE 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 13
Model-View-Controller (MVC) 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 14
MVC - Beneficios Promueve la reutilización de código El propósito del modelo es el de proporcionar la lógica de negocio y de acceso a la información desde un único lugar Esta lógica puede ser reusada por múltiples aplicaciones al mismo tiempo sin necesidad de ningún código adicional Reduce el tiempo de desarrollo El Model, el View y el Controller de pueden desarrollar en paralelo Facilita el mantenimiento El View puede cambiar sin afectar al Model En una página web se puede poner un gráfico en lugar de una tabla sin que afecte al Model El Model puede cambiar sin afectar al View La forma de calcular la prima de un seguro podría cambiar manteniendo la interfaz en la lógica de negocio Los datos pueden cambiar sin afectar al View o al Model 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 15
Arquitecturas para aplicaciones empresariales Las aplicaciones complejas basadas en componentes se subdividen en niveles lógicos Cada nivel cubre un área de tareas y puede estar compuesto de una o varias partes La división en niveles es una abstracción lógica 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 16
Arquitecturas cliente/servidor Reparto funcional y físico de la aplicación en dos niveles 1. Parte del cliente, en el ordenador del usuario: Elementos de un programa clásico: lógica de ejecución, preparación y presentación de información, interacción con el usuario 2. Parte del servidor: Datos de negocio (en una base de datos o, en general, en el Enterprise Information System (EIS) ) Cliente y servidor están débilmente acoplados y se comunican solamente mediante mensajes La solicitud de servicio (iniciación de la comunicación) proviene siempre del cliente. El servidor reacciona mediante una respuesta Gran parte de la aplicación corre en el lado del cliente ( Fat Client )? modelo descentralizado 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 17
Arquitecturas cliente/servidor Nivel Cliente Nivel Servidor Cliente Servidor Fat client Lógica de negocio Datos 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 18
Inconvenientes arquitectura cliente/servidor En general, falta de escalabilidad Problemas de integridad en la base de datos Alta carga en la red: Gran número de pasos de comunicación necesarios Cantidad de resultados devueltos por la base de datos mayor de lo necesario Costosa distribución y actualización del software (cientos o miles de clientes) El diseñador de la aplicación precisa un conocimiento profundo de muchas áreas críticas Control de transacciones Modelo de seguridad Acceso a datos eficiente 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 19
Arquitecturas multi-tier (multi-nivel) En las arquitecturas multi-tier, se añaden niveles (tiers) software adicionales que se encargan de realizar ciertas tareas críticas Los Fat client se convierten en Thin client Los niveles intermedios extienden la responsabilidad del lado del servidor Aunque pueden estar situados en ordenadores o sistemas independientes Cada nivel comunica sólo con los niveles contiguos a través de interfaces claramente definidas 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 20
Ejemplo de distribución básica multi-nivel Nivel cliente (Client tier): Interfaz de usuario e interacción con el usuario (aplicaciones o applets Java, o páginas Web) Nivel medio (Middle tier): Servidor de aplicaciones: parte principal de la aplicación (lógica de la aplicación y de negocio, preparación de la información para el usuario) Procesado de datos basado en transacciones Acceso seguro Middleware: software especializado para la realización de determinadas tareas: Monitores, sistemas de nombres, sistemas de colas de mensajes, etc. Procesado de la presentación, por ejemplo Web-servers Nivel de datos (Back-end tier): Bases de datos o Enterprise Information Systems Responsable de la administración, acceso rápido y persistencia de los datos 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 21
Arquitecturas multi-nivel (multi-tier) Nivel Cliente Nivel Medio Nivel EIS Thin client Cliente Lógica de negocio Servidor Servicios Datos 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 22
Arquitectura tradicional en tres niveles Nivel Cliente Nivel Medio Nivel EIS Servidor Lógica de presentación Lógica de negocio Datos 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 23
Arquitectura tradicional en tres niveles El mivel medio aumenta la escalabilidad reutilizando recursos mejora rendimiento Mejora la seguridad y gestión de aplicación Problemas: Complejidad (distribución, multithreading, seguridad) Falta de portabilidad (distintas APIs) Soporte limitado (distintos protocolos, herramientas, vendedores) Incompatibilidad con la Web 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 24
Ejemplo: arquitectura multi-nivel Nivel Cliente Thin client Windows Macintosh Unix Java Browser Nivel Medio Presentación Lógica de negocio Componente banco Componente cuenta cliente Componente movimiento Driver base de datos Conector Nivel Datos Back End SAP/R3 server DBMS server Sevicio transacciones Servidor Web Servidor Aplicación 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 25
Ventajas de las arquitecturas multi-nivel Las partes críticas de la aplicación se encuentran en el nivel medio, más cercanos a nivel de datos? acceso más eficiente Sólo los datos necesarios son transferidos al cliente? menor carga de red Problema: al aumentar el número de niveles aumenta el número de comunicaciones, aumentando el tiempo de respuesta Mayor flexibilidad y escalabilidad. Además: Menores costes de instalación Facilidad en el cambio de la base de datos Aislamiento frente a cambios Seguridad Administración central de recursos Localización de fallos 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 26
Java 2 Platform, Enterprise Edition (J2EE) Colección de especificaciones y directivas de programación para facilitar el desarrollo de aplicaciones de servidor distribuidas multi-nivel, alineada fuertemente con Internet Un poco de historia 1996: Java Development Kit (JDK) 1.02: colección ordenada de bibliotecas de clases y paquetes 1999: JDK 1.2? Java 2 Platform: adicional al JDK, paquetes opcionales para mensajes, generación dinámica de páginas Web o programas de email en Java. Dividida en 3 ediciones: Java 2 Platform, Standard Edition (J2SE): contiene el JDK actual y las APIs estándar. Desarrollo de aplicaciones de Desktop y applets Java 2 Platform, Enterprise Edition (J2EE): basada en J2SE, extiende el lado del servidor. Version 1.3, 3er Trimestre 2001. Java 2 Platform, Micro Edition (J2ME): especial para móviles, pagers, palmtops (embedded systems) 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 27
Elementos de la especificación J2EE J2EE Platform: estándar representado por un conjunto de APIs y directivas, soportadas por un servidor de aplicación (java.sun.com/j2ee/download.html) J2EE Blueprints: consejos para el desarrollo de aplicaciones J2EE, patrones de diseño y un ejemplo de aplicación (java.sun.com/blueprints/) J2EE Server: implementación de referencia de un servidor de aplicaciones para J2EE, incluido en J2EE SDK (java.sun.com/j2ee/download.html) J2EE Testsuite: J2EE Compatibility Testsuite (CTS), tests de compatibilidad (java.sun.com/j2ee/compatibility.html) 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 28
Componentes J2EE J2EE define cuatro tipos de componentes Tienen que estar soportados por cualquier producto J2EE El despliegue puede ser gestionado usando "deployment descriptors" (excepto applets) Aplicaciones cliente Programas Java que se ejecuten en una máquina cliente desde los que se puede acceder a otros componentes J2EE Applets Componentes gráficos que se ejecutan tipicamente en un browser Pueden proporcionar una avanzada interfaz de usuario para otros componentes J2EE Componentes Web Servlets y JSPs Enterprise Java Beans Componenetes distribuidos y transaccionales que comtienen lógica de negocio y de acceso a datos 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 29
Containers (contenedores) Ofrecen el entorno de ejecución para todos los componentes de aplicación Proporcionan una vista uniforme de los servicios solicitados en la especificación Herramientas adicionales (Deployment Tools) para la instalación y configuración de componentes (también en tiempo de ejecución) Las tareas principales de los componentes del lado del servidor son la gestión de recursos y del ciclo de vida Applet Container Applets Applic. Client Container (J2SE) Servlet/JSP Container JSP Tools ServletEngine JSP: JSP: JSP: Servicios EJB Container Enterprise JavaBeans Gestión recursos Servicios 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 30
Arquitectura J2EE 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 31
Servidor de aplicaciones Es un sistema de soporte para componentes de servidor Proporciona un entorno de desarrollo para los componentes, que a su vez proporcionan la lógica de negocio Los componentes de servidor utilizan los servicios del servidor de aplicaciones Los elementos constitutivos del servidor de aplicaciones se denominan también componentes y pueden instalarse y administrase de forma independiente Tareas de infraestructura: Instanciación de componentes Comunicación Sincronización de acceso concurrentes Preparación de un entorno seguro Disponibilidad Seguridad de transacciones 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 32
Enterprise JavaBeans Enterprise JavaBeans (EJB) es una completa especificación de arquitectura para componentes de servicio Permite el desarrollo en Java de aplicaciones multi-nivel, basadas en componentes y orientadas a transacciones, que se apoyan en servidores de aplicación y otros productos middleware Objetivos de la arquitectura de componentes EJB: Facilitar el desarrollo de aplicaciones, concentrándose en la lógica de negocio: desarrollo, aplicación y aspectos de tiempo de ejecución Independencia del proveedor de componentes mediante la especificación de interfaces Independencia de la plataforma gracias al principio: Write Once Run Anywhere (WORA) y a su realización en Java Compatibilidad con Java-APIs existentes, con sistemas de servidor de terceros y con protocolos CORBA 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 33
J2EE Muti-Tier Model 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 34
Servicios J2EE Los servicios J2EE estándard incluyen lo siguiente: HTTP (Hipertext Transfer Protocol) RMI-IIOP (Remote Method Invocation over the Internet Inter- ORB Protocol) Java IDL (Java Interface Definition Language) JTA (Java Transaction API) JDBC JMS (Java Message Service) JavaMail JAF (JavaBeans Activation Framework) JNDI (Java Naming and Directory Interface) JAXP (Java API for XMl Parsing) JCA (J2EE Connector Architecture) JAAS (Java Authentication and Authoritation Service) 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 35
Servicios J2EE Servicio de nombres: acceso a componentes y recursos mediante nombres lógicos portabilidad y mantenibilidad Java Naming and Directory Interface (JNDI) Servicio de transacciones: ejecución de una serie de pasos de forma atómica y aislada concepto declarativo de límite de transacción mediante descriptores posibilidad de control de transacción programada mediante un interfaz de programación Java Transaction Service (JTS) Servicio de seguridad: directivas de seguridad para recursos protegidos control de acceso en J2EE en dos pasos: autentificación y autorización realización declarativa o programada Java Athentication & Authorization Service (JAAS) 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 36
Servicios J2EE Persistencia: almacenamiento persistente de objetos y estados de objetos, normalmente realizado en bases de datos relacionales JDBC Comunicación: distintas técnicas de comunicación, proporcionadas por el proveedor de servicio de aplicación o de containers Comunicaciones Web: TCP/IP, UDP/IP, HTTP 1.0 y HTTPS (con SSL adicionalmente) Procesado de objetos distribuidos: RMI (Remote Method Invocation), basado en Java Remote Method Protocol (JRMP). Extensión a RMI que soporta además el protocolo CORBA-IIOP para interoperabilidad entre J2EE y sistemas CORBA. Servicios de configuración y administración: empaquetamiento, instalación y configuración flexible de componentes y la administración de aplicaciones descripción mediante esquemas XML de las características de servidores, containers, aplicaciones, componentes y servicios. 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 37
Convención gráfica UML 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 38
Clases en UML nombre Ventana atributos origen dimensión abre() cierra() mueve() operaciones 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 39
Nombres de clase Toda clase tiene un nombre que la distingue del resto de clases en el ámbito del modelo Nombre de clase = [paquete::]nombre-simple Ejemplos: Negocio::Cliente,SensorTemperatura El nombre de la clase es una cadena de cualquier longitud que contiene letras y números y signos de puntuación (salvo ::) Habitualmente los nombres de clases son sustantivos o frases con esa función gramatical Cliente SensorTemperatura Display Java::awt:applet Contrato Libro Fichero 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 40
Atributos de clase Un atributo representa una propiedad característica compartida por todos los objetos de la clase. Una clase puede tener cualquier número de atributos: Atributo = nombre[:tipo][=valorpordefecto] Ejemplos: fechanacimiento, estatura : float El nombre de un atributo es una cadena de cualquier longitud que contiene letras y números Habitualmente los nombres de atributo son sustantivos o frases con esa función gramatical Rectángulo altura: Float base: Float relleno: Boolean = false 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 41
Operaciones Una operación es un servicio básico ofrecido por los objetos de una clase: Operación = nombre([arg:tipo],...)[:tiporetorno] Ejemplo = new(), new(origen:punto) La implementación concreta que una clase hace de una operación se llama método Con frecuencia la invocación de una operación provoca un cambio de estado en el objeto Habitualmente los nombres de operación son verbos o frases con esa función gramatical Rectángulo new() mueve(destino: Punto) calculaarea(): Float 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 42
Responsabilidades Una responsabilidad es un contrato u obligación de una clase en el contexto de un modelo Atributos y operaciones son las características de la clase a través de las cuales las responsabilidades se llevan a cabo Expresión informal de la semántica mediante texto libre La responsabilidad global del modelo debe repartirse de forma equilibrada entre sus clases Algunos métodos ayudan a determinar las responsabilidades de las clases: e.g. CRC Rectángulo Responsabilidades -Representación gráfica de rectángulo a partir de su origen y dimensiones -Cálculo de valores geométricos como área, perímetro,... Comportamiento extra (adorno). También pueden utilizarse notas de comentario 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 43
Relaciones Los sistemas OO se estructuran en forma de abstracciones (clases) interrelacionadas. En UML hay tres tipos de interrelaciones básicas: Dependencia: Expresa una relación de uso entre clases Generalización: Relaciona clases generales con clases especializadas a partir de ellas o, viceversa, clases generalizadas a partir de características comunes de clases más concretas (herencia) Asociación: Relaciones estructurales genéricas entre clases. Entidades Dependencia Generalización Asociación Realización 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 44
Dependencia Relación de dependencia entre dos elementos estructurales de UML que establece que un cambio en uno de ellos (el independiente) puede afectar al otro (el dependiente) puede afectar al otro (el dependiente). La relación suele ser unidireccional. La interpretación más frecuente es la de relación de uso entre clases: una clase utiliza a otra como argumento en la signatura de una operación. UML distingue otros tipos de dependencia: Derivación Instanciación Refinamiento, etc. Applet MiApplet paint(g:graphics) Dependencia (uso) Graphics 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 45
Generalización Relación entre una abstracción general (superclase) y una abstracción más concreta del mismo tipo (subclase). Taxonomía ejemplo: empleado, secretario, informático, directivo,... Una clase puede tener cero, una (herencia simple) o más superclases (herencia múltiple) Una clase sin superclases es una clase raíz Una clase sin subclases es una clase hoja Figura paint(g:graphics) Línea extremos Elipse semiejes area() perímetro() Polígono vértices mueve() perímetro() 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 46
Asociación Relación estructural entre abstracciones que implica interconexión o enlace entre los objetos representados por las abstracciones: Una biblioteca almacena libros Es una relación, por lo general, simétrica Las asociaciones más comunes son las binarias, pero las hay n- arias La representación básica es una línea enlazando las clases, pero puede incluir otros adornos: nombre, roles, multiplicidad y agregación Biblioteca Nombre almacena > Dirección de nombre Libro 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 47
Asociación Nombre. Describe la asociación. Normalmente un verbo. Puede incluir dirección de lectura Rol. Describe el papel específico que una clase juega en una asociación. Una clase puede jugar distintos roles en diferentes asociaciones Multiplicidad. Especifica por cada clase de la asociación el número de objetos de la clase opuesta que se relacionan con un solo objeto de dicha clase a través de la asociación: Uno (1), cero o uno (0..1), tres (3), muchos (*), al menos uno (1..*), dos, cuatro o cinco (2,4,5),... Multiplicidad Persona 1..* Trabaja para > * empleado empleador Empresa Roles 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 48
Agregación Tipo especial de asociación que representa la relación es parte de. Es decir, una de las clases es una abstracción compuesta de otras que son sus diferentes partes (componentes) Si la relación de agregación es fuerte, de tal forma que los componentes no pueden existir independientemente, se denomina composición La agregación no implica diferencia semántica respecto de una asociación genérica. La composición liga la existencia de los componentes a la de la clase compuesta Clase agregada Cadena 1 agregación Clase compuesta Proceso 1 composición Clase componente 2..* Eslabón Clase componente * Hilo 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 49
Diagramas de clases Son los diagramas más frecuentes en el modelado OO. Constan de clases, interfaces y colaboraciones y sus relaciones En sistemas complejos los elementos lógicamente relacionados del diagrama se agrupan en paquetes Representan la visión estática del modelo o diseño de un sistema, dando soporte a la formalización de requisitos funcionales Se utilizan para el diseño de esquemas lógicos de BD (superconjunto de los diagramas E-R) 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 50
Ejemplo de diagramas de clases Escuela Departamento 0..1 nombre: Nombre tiene nombre: Nombre nuevoestudiante() buscaestudiante() listadepartamentos() 1..* 1 1..* nuevoprofesor() elimprofesor() listaprofesores() 1..* organiza 0..1 asignado a {subset} * matriculado en 1..* 1..* 0..1 director Estudiante Curso Profesor nombre: Nombre matrícula: Numero asiste * * nombre: Nombre código: Numero imparte * 1..* nombre: Nombre regper: NRP 2005 Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 51