Diagramas de clases en UML

(1)

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

Contenido

Introducción

– Evolución de las aplicaciones Web

– Arquitecturas cliente-servidor y multi-tier

– Integración de aplicaciones corporativas: la

plataforma Java 2, Enterprise Edition

(J2EE)

(2)

Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata

2005 3

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

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)

(3)

2005 5

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

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

(4)

2005 7

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

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

(5)

2005 9

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

Evolución de las aplicaciones Web - EJBs

EJBs:

(6)

2005 11

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

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

(7)

2005 13

MVC – Aplicación J2EE

(8)

2005 15

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

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

(9)

2005 17

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

Arquitecturas cliente/servidor

Nivel Cliente Nivel Servidor

“Fat client” Cliente Servidor Datos Lógica de negocio

(10)

2005 19

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

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

(11)

2005 21

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

Arquitecturas multi-nivel (multi-tier)

Nivel Cliente Nivel EIS

“Thin client” Cliente Servidor Datos Nivel Medio Lógica de negocio Servicios

(12)

2005 23

Arquitectura tradicional en tres niveles

Nivel Cliente Nivel EIS

Lógica de presentación Servidor Datos Nivel Medio Lógica de negocio

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)

(13)

2005 25

Ejemplo: arquitectura multi-nivel

Thin client _{Lógica de negocio} Windows Componente cuenta cliente Nivel Cliente Nivel Medio Macintosh Unix Java Browser Presentación

Servidor Web Servidor Aplicación

Back End Nivel Datos DBMS server SAP/R3 server Componente movimiento Componente banco

Driver base de datos Conector Sevicio transacciones

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:

(14)

2005 27

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)

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

(15)

2005 29

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

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

(16)

2005 31

Arquitectura J2EE

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

(17)

2005 33

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

(18)

2005 35

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)

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

(19)

2005 37

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.

(20)

Software de Comunicaciones (c) UC3M Natividad Martínez, Ignacio Ramos Zapata 2005 39

Clases en UML

Ventana origen dimensión abre() cierra() mueve() nom bre atributos operaciones

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 Contrato Libro Display Fichero Java::awt:applet

(21)

2005 41

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

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

(22)

2005 43

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

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

(23)

2005 45

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) Graphics Dependencia (uso)

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

(24)

2005 47

Asociación

Relación estructural entre abstracciones que implica

interconexión o enlace entre los objetos representados por las abstracciones:

• Una biblioteca almacenalibros

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 Libro alm acena > Nombre Dirección de nombre

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), ... Empresa Persona Trabaja para > _* 1..* empleado empleador Multiplicidad Roles

(25)

2005 49

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

Cadena Eslabón Proceso Hilo 1 2..* _* 1 Clase componente Clase agregada Clase componente Clase compuesta agregación composición

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

(26)

2005 51

Ejemplo de diagramas de clases

Escuela nuevoEstudiante() buscaEstudiante() listaDepartamentos() nombre: Nombre Departamento nuevoProfesor() elimProfesor() listaProfesores() nombre: Nombre Estudiante nombre: Nombre matrícula: Numero Curso nombre: Nombre código: Numero Profesor nombre: Nombre regPer: NRP 1..* 1 tiene 1..* * matriculado en asiste * * imparte * 1..* 1..* 1..* organiza 0..1 0..1 director 1..* 0..1 asignado a {subset}