INSTITUTO POLITÉCNICO NACIONAL
UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERÍA Y CIENCIAS SOCIALES Y
ADMINISTRATIVAS
“
SERVICIO WEB ADMINISTRADOR DE USUARIOS MULTIPLATAFORMA”T E S I N A
Q U E P A R A O B T E N E R E L T Í T U L O D E : L I C E N C I A D O E N C I E N C I A S D E L A I N F O R M Á T I C A
P R E S E N T A N :
D A V I D G I L H I D A L G O
J O B S A M U E L R O B L E S S A L I N A S V I L L A R R E A L G A L V Á N V E R Ó N I C A
M É X I C O , D . F . 2 0 0 9
Índice
Resumen ... i
Introducción ... ii
Capítulo I. Marco metodológico ... 1
1.1. Planteamiento del problema ... 1
1.2. Objetivos ... 1
1.2.1. Objetivo General ... 1
1.2.2. Objetivos Específicos ... 2
1.3. Justificación del estudio ... 2
1.4. Hipótesis ... 3
1.5. Técnicas de investigación empleadas ... 3
Capítulo II. Conceptos fundamentales de la programación orientada a objetos ... 4
2.1. El concepto de objeto ... 4
2.2. Objetos en POO ... 5
2.3. Estados en objetos ... 5
2.4. Cómo se piensa en objetos ... 6
2.5. Mensajes en objetos ... 7
2.6. Clases en POO ... 7
2.7. Propiedades en clases ... 8
2.8. Métodos en las clases ... 8
2.9. Método constructor de una clase ... 8
2.10. Declaración de una clase y creación de un objeto ... 9
2.11. Herencia ...10
2.12. Modificadores de acceso a atributos y métodos (protected) ...10
2.13. Sobreescritura de métodos ...11
2.14. Sobreescritura del constructor ...11
2.15. Clases abstractas y concretas ...11
2.16. Métodos abstractos ...11
2.17. Métodos y clases final ...11
2.18. Resumen ...12
2.18.1. Conceptos fundamentales ...12
2.18.2. Características de la POO ...14
Capítulo III. Lenguaje unificado de modelado UML (Unified Modeling Language ) ... 16
3.1 Introducción ...16
3.2. Notación básica UML ...16
3.2.1 Modelos ...16
3.2.2 Elementos Comunes a Todos los Diagramas ...17
3.2.2.1 Notas ...17
3.2.2.2 Dependencias ...17
3.2.3 Diagramas de Estructura Estática ...17
3.2.3.1 Clases ...17
3.2.3.2 Objetos ...18
3.2.3.3 Asociaciones ...18
3.2.3.3.1 Nombre de la Asociación y Dirección ...18
3.2.3.3.2 Multiplicidad ...18
3.2.3.3.3 Roles ...19
3.2.3.3.4 Agregación ...19
3.2.3.3.5 Clases Asociación ...19
3.2.3.3.6 Asociaciones N-Arias ...19
3.2.3.3.7 Navegabilidad ...19
3.2.3.4 Herencia ...19
3.2.3.5 Elementos Derivados ...20
3.2.4 Diagrama de Casos de Uso ...20
3.2.4.1 Elementos ...20
3.2.4.1.1 Actores ...20
3.2.4.1.2 Casos de Uso ...20
3.2.4.1.3 Relaciones entre Casos de Uso ...20
3.2.5 Diagramas de Interacción ...21
3.2.5.1 Diagrama de Secuencia ...21
3.2.5.2 Diagrama de Colaboración ...21
3.2.6 Diagrama de Estados...22
3.3 Notación avanzada UML ...23
3.3.1 Modelado Dinámico ...23
3.3.1.1 Diagramas De Actividades ...23
3.3.1.2 Contenido del diagrama de actividades...23
3.3.1.2.1 Estados de actividad y estados de acción ...23
3.3.1.2.2 Transiciones...24
3.3.1.2.3 Bifurcaciones ...24
3.3.1.2.4 División y unión ...24
3.3.2 Modelado Físico De Un Sistema OO ...24
3.3.2.1 Componentes ...24
3.3.2.1.1 Interfaces ...25
3.3.2.1.2 Tipos de componentes ...25
3.3.2.1.3 Organización de componentes ...25
3.3.2.1.4 Estereotipos de componentes ...25
3.3.2.2 Despliegue ...26
3.3.2.2.1 Nodos ...26
3.3.2.2.2 Nodos y componentes ...26
3.3.2.3 Diagramas de Componentes ...26
3.3.2.3.1 Conceptos ...27
3.3.2.3.2 Usos más comunes ...27
3.3.2.4 Diagramas de Despliegue ...28
3.3.2.4.1 Técnicas más comunes de modelado ...28
3.3.2.5 Arquitectura del Sistema ...29
3.3.2.5.1 Arquitectura de tres niveles ...29
3.3.2.5.2 Arquitectura de tres niveles orientadas a objetos ...29
3.3.2.5.3 Arquitectura MULTI-nivel ...29
3.3.2.5.4 Paquetes ...30
3.3.2.5.5 Identificación de Paquetes ...30
Capítulo IV. Arquitectura de software orientada a servicios (SOA) y servicios web (web services) ... 31
4.1. La arquitectura de software ...31
4.1.1. Introducción ...31
4.1.2. Definiciones ...32
4.1.3. Historia ...32
4.1.4. Principales conceptos manejados en la arquitectura de software ...33
4.1.4.1. Lenguajes de descripción arquitectónica (ADLs) ...33
4.1.4.2. Vistas ...33
4.1.4.3. Frameworks de arquitectura ...34
4.1.4.3.1. Four plus one (4+1) ...34
4.1.4.3.2. Reference Model of Open Distributed Processing (RM-ODP) ...35
4.1.4.3.1. Service-Oriented Modeling Framework (SOMF) ...37
4.1.5. Principales estilos de arquitectura de software ...38
4.1.5.1. Monolítica ...38
4.1.5.2. Cliente-Servidor ...39
4.1.5.3. Tres Capas ...39
4.1.6. Diferencias de la arquitectura de software con el diseño detallado ...40
4.1.7. El rol del arquitecto de software ...40
4.2. Arquitectura orientada a servicios (SOA) ...42
4.2.1. Definición ...42
4.2.2. Conceptos ...42
4.2.3. Principios ...43
4.2.4. Limitaciones Adicionales ...44
4.2.4.1. Servicio sin estado (Stateless Service) ...44
4.2.4.2. Servicio con estado (Stateful Service) ...44
4.2.4.3. Petición idempotente (Idempotent Request) ...45
4.2.5. Gobierno de SOA ...45
4.2.6. Ciclo de vida de SOA ...46
4.3. Servicios web ...46
4.3.1. Definición ...46
4.3.2. Lenguajes y protocolos usados comúnmente ...47
4.3.2.1. HTTP (HyperText Transfer Protocol) ...47
4.3.2.2. XML (eXtensible Markup Language) ...47
4.3.2.3. WSDL (Web Service Description Language) ...48
4.3.2.4. UDDI (Universal Description, Discovery and Integration) ...48
4.3.3. Servicios web SOAP ...49
4.3.4. Servicios web SOAP RPC ...49
4.3.5. Servicios web REST ...49
Capítulo V. El servicio web administrador de usuarios multiplataforma ... 51
5.1. Visión ...51
5.2. Arquitectura ...51
5.3. Diagramas UML ...52
5.4. Desarrollo ...78
5.4.1. Base de datos ...78
5.4.1.1. Diagrama entidad-relación ...79
5.4.1.2. Descripción de las tablas ...80
5.4.1.3. Descripción de los procedimientos almacenados ...82
5.4.2. Descripción de clases ...85
5.4.2.1. Métodos de clase empresa ...85
5.4.2.2. Métodos de clase usuario ...86
5.4.2.3. Métodos de clase tarea ...90
5.4.3. Web service ...92
5.4.3.1. Métodos del web service ...92
5.4.3.2. Ejemplo de consumo del servicio ...93
Conclusiones ... 95
Bibliografía ... 96
Resumen
Conforme las organizaciones avanzan en tecnología y comienzan a utilizar uno o más sistemas de información dentro de la organización, administrar los usuarios se convierte en un problema no sólo más grave, sino también más olvidado. Especialmente en organizaciones donde se utilizan múltiples sistemas de información de diversas fuentes (a veces aún siendo de la misma), es común que cada una tenga su propio diseño y modelado de la base de usuarios, flujo de información, algoritmos de seguridad, etc., lo que dificulta (y muchas veces impide) una administración unificada de los usuarios. Hay una serie de problemas adicionales que acompañan al diseño de una solución que administre los usuarios. Siendo un problema poco estudiado, muchas veces se dejan de lado cuestiones como seguridad, independencia de plataforma (usualmente se desarrolla desde inicio todo el módulo en cada plataforma) e independencia de sistema operativo, así como lo costoso que resulta el estar repitiendo el módulo a través de sistemas y la redundancia de datos – un usuario puede aparecer en varias bases de datos de la misma organización.
El objetivo del proyecto es desarrollar un servicio web que permita la administración de usuarios de uno o más sistemas de la organización de manera unificada, segura e independiente del lenguaje de programación y del sistema operativo en el que se implemente esta solución. Se plantea entonces atacar todos estos problemas desarrollando un sistema de administración de usuarios disponible para todos los desarrollos, evitando así los registros repartidos en varias bases y el desarrollo repetido del módulo. La propuesta es que esté disponible como un Web Service, es decir, una aplicación web estandarizada (generalmente usando XML para describir los datos) que permite realizar operaciones sobre los datos.
El sistema Servicio Web Administrador de Usuarios Multiplataforma podrá ser consumido por cualquier aplicación que lo requiera y cuyas tareas, usuarios y permisos estén registrados en el mismo. Contará con una base de datos que llevará el control de las empresas, dominios, usuarios, tareas, permisos y perfiles. Así como una bitácora del uso. Los diferentes beneficios que se obtendrán son: independencia de aplicación, plataforma y sistema operativo; consolidación de datos; seguridad y privacidad de datos; actualizaciones y mejoras que automáticamente se reflejan en los sistemas conectados.
Introducción
En el trabajo presentado a continuación, “Servicio web de administración de usuarios multiplataforma”, se utilizan tecnologías novedosas para abordar un problema viejo y común de los sistemas de información: la administración de usuarios. Por lo general, los sistemas de información requieren administrar varios aspectos de los usuarios que utilizan el sistema, como son sus datos, sus permisos y un rastreo de su actividad.
El problema no surge solamente de administrar estos usuarios para un solo sistema, sino de las complicaciones que surgen cuando se administran dichos usuarios en varios sistemas dentro de una misma empresa, ya que surgen problemas como redundancia de información, creación de múltiples interfaces de ingreso de credenciales, diferencias entre manejo de usuarios, incompatibilidad de la información de los usuarios, etc.
Al tratar de dar solución al problema planteado, se revela como clara situación que la administración de usuarios puede funcionar como un servicio para el resto de las aplicaciones y sistemas de la organización, y se postula a la arquitectura orientada a servicios (conocida como SOA, por sus siglas en inglés) como la indicada para solucionar el problema.
Así, el equipo autor del presente proyecto se da a la tarea de crear todos los servicios web necesarios para solventar la administración de usuarios en la mayoría de las posibles plataformas y sin restringir al consumidor del servicio al uso de una u otra metodología, permitiéndole sortear este obstáculo sin imponerle otros en su lugar.
Para el diseño y desarrollo del servicio web, se utiliza una metodología orientada a objetos. Ésta completa metodología, gracias a su constante evolución, permite la abstracción de un proceso a un grupo de objetos interrelacionados entre sí y con características y actividades definidas. Dicha abstracción permite generar código de manera simple, lo que permite pasar del diseño al desarrollo fácilmente.
Para el manejo de bases de datos, se utiliza la aplicación de manejo de bases de datos MySQL, una herramienta poderosa y gratuita que cuenta con todas las características requeridas para un desarrollo de este tipo, como son los procedimientos almacenados.
Al final del presente proyecto, se describe a detalle el modelado de los procesos de acuerdo a la metodología orientada a objetos y diagramas UML, su implementación en bases de datos y el modelo relacional y, finalmente, como un grupo de servicios web.
Capítulo I. Marco metodológico
1.1. Planteamiento del problema
De la experiencia profesional de los miembros del equipo en lo que a desarrollo de sistemas se refiere, es claro que existe una larga lista de problemas a los que el desarrollador y sus clientes o sus empleadores se enfrentan frecuentemente. Uno de estos problemas suele ser desatendido (o al menos rara vez es lo más importante) durante el desarrollo de la solución: la administración de los usuarios.
Más aún. Conforme las organizaciones avanzan en tecnología y comienzan a utilizar uno o más sistemas de información dentro de la organización, administrar los usuarios se convierte en un problema no sólo más grave, sino también más olvidado. Especialmente en organizaciones donde se utilizan múltiples sistemas de información de diversas fuentes (a veces aún siendo de la misma), es común que cada una tenga su propio diseño y modelado de la base de usuarios, flujo de información, algoritmos de seguridad, etc., lo que dificulta (y muchas veces impide) una administración unificada de los usuarios.
Hay una serie de problemas adicionales que acompañan al diseño de una solución que administre los usuarios. Siendo un problema poco estudiado, muchas veces se dejan de lado cuestiones como seguridad, independencia de plataforma (usualmente se desarrolla desde inicio todo el módulo en cada plataforma) e independencia de sistema operativo, así como lo costoso que resulta el estar repitiendo el módulo a través de sistemas y la redundancia de datos – un usuario puede aparecer en varias bases de datos de la misma organización.
Es así que vemos la necesidad de un servicio independiente de aplicación, plataforma y sistema operativo que permita la administración y unificación de las bases de datos de usuarios, lo que da origen al presente proyecto de titulación. Más aún, reconocemos un potencial nicho de mercado para un servicio de este tipo.
1.2. Objetivos
1.2.1. Objetivo General
Desarrollar un servicio web que permita la administración de usuarios de uno o más sistemas de la organización de manera unificada, segura e independiente del lenguaje de programación y del sistema operativo en el que se implemente esta solución.
1.2.2. Objetivos Específicos
1. Investigar, analizar las tecnologías actuales para el desarrollo de la aplicación.
2. Levantar y analizar los requerimientos establecidos para el desarrollo del Servicio Web de Administración de Usuarios
3. Instalar, configurar y operar las diversas herramientas a utilizar para el desarrollo del web service en forma distribuida.
4. Analizar, diseñar y desarrollar los componentes y procesos del Servicio Web de Administración de Usuarios.
5. Implementar el proyecto, de manera que permita el acceso de datos en tiempo real, mostrar la funcionalidad multiplataforma.
6. Generar la documentación necesaria para el mantenimiento correcto del Servicio Web de Administración de Usuarios.
1.3. Justificación del estudio
Anteriormente en este documento, se trató detalladamente el problema que posa la administración de usuarios de uno o varios sistemas para las organizaciones. Básicamente se habla de problemas de seguridad, datos repartidos y repetidos en diversas bases de datos, así como un incompleto estudio del problema y sus mejores soluciones debido a que usualmente no es el principal de los problemas que se tienen al decidir iniciar un desarrollo a la medida, una implementación de una solución o hasta la paquetería más simple. También queda claro que es costoso para las organizaciones repetir constantemente este desarrollo, necesario en la mayoría de los sistemas.
Se plantea entonces atacar todos estos problemas desarrollando un sistema de administración de usuarios disponible para todos los desarrollos, evitando así los registros repartidos en varias bases y el desarrollo repetido del módulo. La propuesta es que esté disponible como un Web Service, es decir, una aplicación web estandarizada (generalmente usando XML para describir los datos) que permite realizar operaciones sobre los datos.
Los diferentes beneficios que se obtendrán son: independencia de aplicación, plataforma y sistema operativo; consolidación de datos; seguridad y privacidad de datos; actualizaciones y mejoras que automáticamente se reflejan en los sistemas conectados.
El web service de usuarios otorgará un alto grado de disponibilidad de la información sin comprometer en ningún momento la seguridad de la misma. Todas las aplicaciones podrán utilizar una conexión a este servicio para manejar los usuarios y los usuarios estarán consolidados en una base de datos única para toda la organización.
La independencia de plataforma y sistema operativo dará libertad al equipo de desarrollo de la organización o consultorías externas para desarrollar en cualquier lenguaje y sistema operativo y poder seguir utilizando el servicio.
Cualquier actualización o mejora al sistema tendrá una repercusión inmediata en todos los sistemas. Por ejemplo, si en la organización se tienen cinco sistemas que utilicen usuarios, y se necesita hacer un cambio en el modo en que se trabajan o almacenan los usuarios (quizá agregar un campo, por ejemplo), no es necesario hacer el cambio en cinco sistemas diferentes, sino basta con hacerlo en el web service y el cambio se reflejará automáticamente en todos los sistemas de la organización.
1.4. Hipótesis
De acuerdo al análisis realizado, encontramos que para resolver el problema de la administración y unificación de usuarios se resolvió mediante la implementación del servicio Web de administración de usuarios.
Con el fin de comprobar que la aplicación cubre los requerimientos para resolver el problema, se llevaron a cabo varias implementaciones las cuales tendrán plataformas de lenguaje de programación diferente y serán accedidas desde dos diferentes medios de comunicación, estas pruebas se tomaran como indicadores del nivel de eficacia de la resolución del problema. Se documentó la implementación en plataforma .NET.
1.5. Técnicas de investigación empleadas
Se hizo uso de las técnicas documentales, recurriendo a información en libros, buscadores en Internet, los cuales nos permitieron conocer, evaluar, analizar conceptos, métodos de la programación orientada a objetos, la metodología UML, la arquitectura de software, la arquitectura de software orientada a objetos y las características de las herramientas para el desarrollo.
Capítulo II. Conceptos fundamentales de la programación orientada a objetos
La programación Orientada a objetos (POO) es una forma especial de programar, más cercana a como expresaríamos las cosas en la vida real que otros tipos de programación.
Con la POO tenemos que aprender a pensar las cosas de una manera distinta, para escribir nuestros programas en términos de objetos, propiedades, métodos y otras cosas que veremos rápidamente para aclarar conceptos y dar una pequeña base que permita soltarnos un poco con este tipo de programación.
Durante años, los programadores se han dedicado a construir aplicaciones muy parecidas que resolvían una y otra vez los mismos problemas. Para conseguir que los esfuerzos de los programadores puedan ser utilizados por otras personas se creó la POO. Que es una serie de normas de realizar las cosas de manera que otras personas puedan utilizarlas y adelantar su trabajo, de manera que consigamos que el código se pueda reutilizar.
La POO no es difícil, pero es una manera especial de pensar, a veces subjetiva de quien la programa, de manera que la forma de hacer las cosas puede ser diferente según el programador.
Aunque podamos hacer los programas de formas distintas, no todas ellas son correctas, lo difícil no es programar orientado a objetos sino programar bien. Programar bien es importante porque así nos podemos aprovechar de todas las ventajas de la POO.
2.1. El concepto de objeto
La programación orientada a objetos consiste en ordenar datos en conjuntos modulares de elementos de información del mundo real (denominado un dominio). Estos elementos de datos se llaman objetos. Estos datos se agrupan de acuerdo a las características principales del mundo real de estos elementos (tamaño, color, etc.).
El enfoque de objetos es una idea que se ha probado con creces. Simula fue el primer lenguaje de programación en implementar el concepto de clases en 1967. En 1976, Smalltalk implementó los conceptos de encapsulación, agrupación y herencia (los conceptos principales de la programación orientada a objetos). Por otra parte, se han implementado varios lenguajes de programación orientada a objetos a escala global (Eiffel, Objective C, Loops, etc.).
La dificultad que presenta este enfoque es la creación de una representación abstracta, en forma de objetos, de entidades que realmente existen (perro, auto, lámpara eléctrica...) o que existen virtualmente (seguridad social, clima...).
2.2. Objetos en POO
Los objetos son ejemplares de una clase cualquiera. Cuando creamos un ejemplar tenemos que especificar la clase a partir de la cual se creará. Esta acción de crear un objeto a partir de una clase se llama instanciar (que viene de una mala traducción de la palabra instace que en inglés significa ejemplar). Por ejemplo, un objeto de la clase fracción es por ejemplo 3/5. El concepto o definición de fracción sería la clase, pero cuando ya estamos hablando de una fracción en concreto 4/7, 8/1000 o cualquier otra, la llamamos objeto.
Para crear un objeto se tiene que escribir una instrucción especial que puede ser distinta dependiendo el lenguaje de programación que se emplee, pero será algo parecido a esto.
miCoche = new Coche()
Con la palabra new especificamos que se tiene que crear una instancia de la clase que sigue a continuación. Dentro de los paréntesis podríamos colocar parámetros con los que inicializar el objeto de la clase coche.
2.3. Estados en objetos
Cuando tenemos un objeto sus propiedades toman valores. Por ejemplo, cuando tenemos un coche la propiedad color tomará un valor en concreto, como por ejemplo rojo o gris metalizado. El valor concreto de una propiedad de un objeto se llama estado.
Para acceder a un estado de un objeto para ver su valor o cambiarlo se utiliza el operador punto.
miCoche.color = rojo
El objeto es miCoche, luego colocamos el operador punto y por último el nombre de la propiedad a la que deseamos acceder. En este ejemplo estamos cambiando el valor del estado de la propiedad del objeto a rojo con una simple asignación.
Un objeto se caracteriza por varios conceptos:
Atributos: estos son los datos que caracterizan al objeto. Son variables que almacenan datos relacionados al estado de un objeto.
Métodos (usualmente llamados funciones de miembro): Los métodos de un objeto caracterizan su comportamiento, es decir, son todas las acciones (denominadas operaciones) que el objeto puede realizar por sí mismo. Estas operaciones hacen posible que el objeto responda a las solicitudes externas (o que actúe sobre otros objetos).
Además, las operaciones están estrechamente ligadas a los atributos, ya que sus acciones pueden depender de, o modificar, los valores de un atributo.
Identidad: El objeto tiene una identidad, que lo distingue de otros objetos, sin considerar su estado. Por lo general, esta identidad se crea mediante un identificador que deriva naturalmente de un problema (por ejemplo: un producto puede estar representado por un código, un automóvil, por un número de modelo, etc.).
2.4. Cómo se piensa en objetos
Pensar en términos de objetos es muy parecido a cómo lo haríamos en la vida real. Por ejemplo vamos a pensar en un coche para tratar de modelarlo en un esquema de POO. Diríamos que el coche es el elemento principal que tiene una serie de características, como podrían ser el color, el modelo o la marca. Además tiene una serie de funcionalidades asociadas, como pueden ser ponerse en marcha, parar o estacionarse.
Pues en un esquema POO el coche sería el objeto, las propiedades serían las características como el color o el modelo y los métodos serían las funcionalidades asociadas como ponerse en marcha o parar.
Por poner otro ejemplo vamos a ver cómo modelaríamos en un esquema POO una fracción, es decir, esa estructura matemática que tiene un numerador y un denominador que divide al numerador, por ejemplo 3/2.
La fracción será el objeto y tendrá dos propiedades, el numerador y el denominador. Luego podría tener varios métodos como simplificarse, sumarse con otra fracción o número, restarse con otra fracción, etc.
Estos objetos se podrán utilizar en los programas, por ejemplo en un programa de matemáticas harás uso de objetos fracción y en un programa que gestione un taller de coches utilizarás objetos coche. Los programas Orientados a objetos utilizan muchos objetos para realizar las acciones que se desean realizar y ellos mismos también son objetos. Es decir, el taller de coches será un objeto que utilizará objetos coche, herramienta, mecánico, recambios, etc.
Un objeto es una entidad independiente con sus propios datos y programación. Las ventanas, menús, carpetas de archivos pueden ser identificados como objetos; el motor de un auto también es considerado un objeto, en este caso, sus datos (atributos) describen sus características físicas y su programación (métodos) describen el funcionamiento interno y su interrelación con otras partes del automóvil (también objetos).
El concepto renovador de la tecnología Orientación a Objetos es la suma de funciones a elementos de datos, a esta unión se le llama encapsulamiento. Por ejemplo, un objeto página contiene las dimensiones físicas de la página (ancho, alto), el color, el estilo del borde, etc, llamados atributos.
Encapsulados con estos datos se encuentran los métodos para modificar el tamaño de la página, cambiar el color, mostrar texto, etc. La responsabilidad de un objeto pagina consiste en realizar las acciones apropiadas y mantener actualizados sus datos internos. Cuando otra parte del programa (otros objetos) necesitan que la pagina realice alguna de estas tareas (por ejemplo, cambiar de color) le envía un mensaje. A estos objetos que envían mensajes no les interesa la manera en que el objeto página lleva a cabo sus tareas ni las estructuras de datos que maneja, por ello, están ocultos. Entonces, un objeto contiene información pública, lo que necesitan los otros objetos para interactuar con él e información privada, interna, lo que necesita el objeto para operar y que es irrelevante para los otros objetos de la aplicación.
2.5. Mensajes en objetos
Un mensaje en un objeto es la acción de efectuar una llamada a un método. Por ejemplo, cuando le decimos a un objeto coche que se ponga en marcha estamos pasándole el mensaje “ponte en marcha”.
Para mandar mensajes a los objetos utilizamos el operador punto, seguido del método que deseamos invocar.
miCoche.ponerseEnMarcha()
En este ejemplo pasamos el mensaje ponerseEnMarcha(). Hay que colocar paréntesis igual que cualquier llamada a una función, dentro irían los parámetros.
2.6. Clases en POO
Las clases son declaraciones de objetos, también se podrían definir como abstracciones de objetos. Esto quiere decir que la definición de un objeto es la clase. Cuando programamos un
objeto y definimos sus características y funcionalidades en realidad lo que estamos haciendo es programar una clase. En los ejemplos anteriores en realidad hablábamos de las clases coche o fracción porque sólo estuvimos definiendo, aunque por encima, sus formas.
2.7. Propiedades en clases
Las propiedades o atributos son las características de los objetos. Cuando definimos una propiedad normalmente especificamos su nombre y su tipo. Nos podemos hacer a la idea de que las propiedades son algo así como variables donde almacenamos datos relacionados con los objetos.
2.8. Métodos en las clases
Son las funcionalidades asociadas a los objetos. Cuando estamos programando las clases las llamamos métodos. Los métodos son como funciones que están asociadas a un objeto.
Métodos de una clase
Los métodos son como las funciones en los lenguajes estructurados, pero están definidos dentro de una clase y operan sobre los atributos de dicha clase.
Los métodos también son llamados las responsabilidades de la clase. Para encontrar las responsabilidades de una clase hay que preguntarse qué puede hacer la clase.
El objetivo de un método es ejecutar las actividades que tiene encomendada la clase a la cual pertenece.
Los atributos de un objeto se modifican mediante llamadas a sus métodos.
2.9. Método constructor de una clase
El constructor es un método especial de una clase. El objetivo fundamental del constructor es inicializar los atributos del objeto que creamos.
Básicamente el constructor remplaza al método inicializar que habíamos hecho en el concepto anterior.
Las ventajas de implementar un constructor en lugar del método inicializar son:
1. El constructor es el primer método que se ejecuta cuando se crea un objeto.
2. El constructor se llama automáticamente. Es decir es imposible de olvidarse llamarlo ya que se llamará automáticamente.
3. Quien utiliza POO (Programación Orientada a Objetos) conoce el objetivo de este método.
Otras características de los constructores son:
El constructor se ejecuta inmediatamente luego de crear un objeto y no puede ser llamado nuevamente.
Un constructor no puede retornar dato.
Un constructor puede recibir parámetros que se utilizan normalmente para inicializar atributos.
El constructor es un método opcional, de todos modos es muy común definirlo.
2.10. Declaración de una clase y creación de un objeto
La programación orientada a objetos se basa en la programación de clases; a diferencia de la programación estructurada, que está centrada en las funciones.
Una clase es un molde del que luego se pueden crear múltiples objetos, con similares características.
Una clase es una plantilla (molde), que define atributos (lo que conocemos como variables) y métodos (lo que conocemos como funciones).
La clase define los atributos y métodos comunes a los objetos de ese tipo, pero luego, cada objeto tendrá sus propios valores y compartirán las mismas funciones.
Debemos crear una clase antes de poder crear objetos (instancias) de esa clase. Al crear un objeto de una clase, se dice que se crea una instancia de la clase o un objeto propiamente dicho.
Confeccionaremos nuestra primera clase para conocer la sintaxis en el lenguaje PHP, luego definiremos dos objetos de dicha clase.
Implementaremos una clase llamada Persona que tendrá como atributo (variable) su nombre y dos métodos (funciones), uno de dichos métodos inicializará el atributo nombre y el siguiente método mostrará en la página el contenido del mismo.
Los atributos son las características, cualidades, propiedades distintivas de cada clase. Contienen información sobre el objeto. Determinan la apariencia, estado y demás particularidades de la clase.
Varios objetos de una misma clase tendrán los mismos atributos pero con valores diferentes.
Cuando creamos un objeto de una clase determinada, los atributos declarados por la clase son localizadas en memoria y pueden ser modificados mediante los métodos.
Lo más conveniente es que los atributos sean privados para que solo los métodos de la clase puedan modificarlos.
Parámetros opcionales
Esta característica está presente tanto para programación estructurada como para programación orientada a objetos. Un parámetro es opcional si en la declaración del método le asignamos un valor por defecto. Si luego llamamos al método sin enviarle dicho valor tomará el que tiene por defecto.
2.11. Herencia
Otra requisito que tiene que tener un lenguaje para considerarse orientado a objetos es la HERENCIA.
La herencia significa que se pueden crear nuevas clases partiendo de clases existentes, que tendrá todos los atributos y los métodos de su 'superclase' o 'clase padre' y además se le podrán añadir otros atributos y métodos propios.
2.12. Modificadores de acceso a atributos y métodos (protected)
En el concepto anterior presentamos la herencia que es una de las características fundamentales de la programación orientada a objetos.
Habíamos dicho que otro objetivo de la POO es el encapsulamiento (es decir ocultar todo aquello que no le interese a otros objetos), para lograr esto debemos definir los atributos y métodos como privados. El inconveniente es cuando debemos utilizar herencia.
Una subclase no puede acceder a los atributos y métodos privados de la clase padre. Para poder accederlos deberíamos definirlos como públicos (pero esto trae como contrapartida que perdemos el encapsulamiento de la clase). Aquí es donde entra en juego el modificador protected. Un atributo
o método protected puede ser accedido por la clase, por todas sus subclases pero no por los objetos que definimos de dichas clases.
2.13. Sobreescritura de métodos
Una subclase puede redefinir un método, es decir que podemos crear un método con el mismo nombre que el método de la clase padre. Ahora cuando creamos un objeto de la subclase, el método que se llamará es el de dicha subclase.
Lo más conveniente es sobreescribir métodos para completar el algoritmo del método de la clase padre. No es bueno sobreescribir un método y cambiar completamente su comportamiento.
2.14. Sobreescritura del constructor
Cuando creamos un objeto de una clase el primer método que se ejecuta es el constructor. Si la clase no tiene constructor pero la subclase si lo tiene, el que se ejecuta es el constructor de la clase padre.
2.15. Clases abstractas y concretas
Una clase abstracta tiene por objetivo agrupar atributos y métodos que luego serán heredados por otras subclases.
No es obligatorio que toda clase padre sea abstracta. Podemos tener por ejemplo un problema donde tengamos una clase padre (superclase) llamada Persona y una subclase llamada Empleado y luego necesitemos definir objetos tanto de la clase Persona como de la clase Empleado.
2.16. Métodos abstractos
Vimos en conceptos anteriores que podemos definir clases abstractas que tienen por objetivo agrupar atributos y métodos comunes a un conjunto de subclases.
Si queremos que las subclases implementen comportamientos obligatoriamente podemos definir métodos abstractos.
2.17. Métodos y clases final
Si a un método le agregamos el modificador final significa que ninguna subclase puede sobreescribirlo. Este mismo modificador se lo puede aplicar a una clase, con esto estaríamos indicando que dicha clase no se puede heredar.
2.18. Resumen
Los objetos son entidades que combinan estado, comportamiento e identidad:
El estado está compuesto de datos, será uno o varios atributos a los que se habrán asignado unos valores concretos (datos).
El comportamiento está definido por los procedimientos o métodos con que puede operar dicho objeto, es decir, qué operaciones se pueden realizar con él.
La identidad es una propiedad de un objeto que lo diferencia del resto, dicho con otras palabras, es su identificador (concepto análogo al de identificador de una variable o una constante).
La programación orientada a objetos expresa un programa como un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. Esto permite hacer los programas y módulos más fáciles de escribir, mantener y reutilizar.
De esta forma, un objeto contiene toda la información que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. A su vez, los objetos disponen de mecanismos de interacción llamados métodos que favorecen la comunicación entre ellos. Esta comunicación favorece a su vez el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separan ni deben separarse el estado y el comportamiento.
Los métodos (comportamiento) y atributos (estado) están estrechamente relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de métodos para poder tratar los atributos con los que cuenta.
2.18.1. Conceptos fundamentales
La programación orientada a objetos es una nueva forma de programar que trata de encontrar una solución a estos problemas. Introduce nuevos conceptos, que superan y amplían conceptos antiguos ya conocidos. Entre ellos destacan los siguientes:
Clase: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ellas.
Herencia: (por ejemplo, herencia de la clase D a la clase C) Es la facilidad mediante la cual la clase D hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y operaciones hubiesen sido definidos por la misma D. Por lo tanto, puede usar los mismos métodos y variables públicas declaradas en C. Los componentes registrados como "privados" (private) también se heredan, pero como no pertenecen a la clase, se mantienen escondidos al programador y sólo pueden ser accedidos a través de otros métodos públicos. Esto es así para mantener hegemónico el ideal de OOP.
Objeto: entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos). Se corresponde con los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Es una instancia a una clase.
Método: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo mensaje para otro objeto del sistema.
Evento: un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. También se puede definir como evento, a la reacción que puede desencadenar un objeto, es decir la acción que genera.
Mensaje: una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó.
Propiedad o atributo: contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método.
Estado interno: es una variable que se declara privada, que puede ser únicamente accedida y alterada por un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos). No es visible al programador que maneja una instancia de la clase.
Componentes de un objeto:atributos, identidad, relaciones y métodos.
Representación de un objeto: un objeto se representa por medio de una tabla o entidad que esté compuesta por sus atributos y funciones correspondientes.
En comparación con un lenguaje imperativo, una "variable", no es más que un contenedor interno del atributo del objeto o de un estado interno, así como la "función" es un procedimiento interno del método del objeto.
2.18.2. Características de la POO
Hay un cierto desacuerdo sobre exactamente qué características de un método de programación o lenguaje le definen como "orientado a objetos", pero hay un consenso general en que las características siguientes son las más:
Abstracción: Denota las características esenciales de un objeto, donde se capturan sus comportamientos.Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos y cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción.
Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite aumentar la cohesión de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultación, principalmente porque se suelen emplear conjuntamente.
Principio de ocultación: Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especifica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas, solamente los propios métodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstracción. La aplicación entera se reduce a un agregado o rompecabezas de objetos.
Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecución", esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en "tiempo de compilación") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++.
Herencia: las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de
todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que volver a implementarlo. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en árboles o enrejados que reflejan un comportamiento común. Cuando un objeto hereda de más de una clase se dice que hay herencia múltiple.
Recolección de basura: la Recolección de basura o Garbage Collection es la técnica por la cual el ambiente de Objetos se encarga de destruir automáticamente, y por tanto desasignar de la memoria, los Objetos que hayan quedado sin ninguna referencia a ellos.
Esto significa que el programador no debe preocuparse por la asignación o liberación de memoria, ya que el entorno la asignará al crear un nuevo Objeto y la liberará cuando nadie lo esté usando. En la mayoría de los lenguajes híbridos que se extendieron para soportar el Paradigma de Programación Orientada a Objetos como C++ u Object Pascal, esta característica no existe y la memoria debe desasignarse manualmente.
Capítulo III. Lenguaje unificado de modelado UML (Unified Modeling Language )
3.1 Introducción
UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. Se ha convertido en el estándar de facto de la industria, debido a que ha sido impulsado por los autores de los tres métodos más usados de orientación a objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh. Estos autores fueron contratados por la empresa Rational Software Co. para crear una notación unificada en la que basar la construcción de sus herramientas CASE. En el proceso de creación de UML han participado, no obstante, otras empresas de gran peso en la industria como Microsoft, Hewlett- Packard, Oracle o IBM, así como grupos de analistas y desarrolladores.
Uno de los objetivos principales de la creación de UML era posibilitar el intercambio de modelos entre las distintas herramientas CASE orientadas a objetos del mercado. Para ello era necesario definir una notación y semántica común.
Esta notación ha sido ampliamente aceptada debido al prestigio de sus creadores y debido a que incorpora las principales ventajas de cada uno de los métodos particulares en los que se basa (principalmente Booch, OMT y OOSE). UML ha puesto fin a las llamadas “guerras de métodos” que se han mantenido a lo largo de los 90, en las que los principales métodos sacaban nuevas versiones que incorporaban las técnicas de los demás. Con UML se fusiona la notación de estas técnicas para formar una herramienta compartida entre todos los ingenieros software que trabajan en el desarrollo orientado a objetos.
3.2. Notación básica UML
3.2.1 Modelos
Un modelo representa a un sistema software desde una perspectiva específica. Al igual que la planta y el alzado de una figura en dibujo técnico nos muestran la misma figura vista desde distintos ángulos, cada modelo nos permite fijarnos en un aspecto distinto del sistema.
Los modelos de UML que se tratan en esta parte son los siguientes:
• Diagrama de Estructura Estática.
• Diagrama de Casos de Uso.
• Diagrama de Secuencia.
• Diagrama de Colaboración.
• Diagrama de Estados.
3.2.2 Elementos Comunes a Todos los Diagramas
3.2.2.1 Notas
Una nota sirve para añadir cualquier tipo de comentario a un diagrama o a un elemento de un diagrama. Es un modo de indicar información en un formato libre, cuando la notación del diagrama en cuestión no nos permite expresar dicha información de manera adecuada. Una nota se representa como un rectángulo con una esquina doblada con texto en su interior. Puede aparecer en un diagrama tanto sola como unida a un elemento por medio de una línea discontinua. Puede contener restricciones, comentarios, el cuerpo de un procedimiento, etc.
3.2.2.2 Dependencias
La relación de dependencia entre dos elementos de un diagrama significa que un cambio en el elemento destino puede implicar un cambio en el elemento origen (por tanto, si cambia el elemento destino habría que revisar el elemento origen). Una dependencia se representa por medio de una línea de trazo discontinuo entre los dos elementos con una flecha en su extremo. El elemento dependiente es el origen de la flecha y el elemento del que depende es el destino (junto a él está la flecha).
3.2.3 Diagramas de Estructura Estática
Los Diagramas de Estructura Estática de UML se van a utilizar para representar tanto Modelos Conceptuales (ver sección IV.3.2) como Diagramas de Clases de Diseño (ver sección IV.4.4).
Ambos usos son distintos conceptualmente, mientras los primeros modelan elementos del dominio los segundos presentan los elementos de la solución software. Ambos tipos de diagramas comparten una parte de la notación para los elementos que los forman (clases y objetos) y las relaciones que existen entre los mismos (asociaciones). Sin embargo, hay otros elementos de notación que serán exclusivos de uno u otro tipo de diagrama.
3.2.3.1 Clases
Una clase se representa mediante una caja subdividida en tres partes: En la superior se muestra el nombre de la clase, en la media los atributos y en la inferior las operaciones. Una clase puede representarse de forma esquemática, con los atributos y operaciones suprimidos, siendo entonces tan solo un rectángulo con el nombre de la clase.
3.2.3.2 Objetos
Un objeto se representa de la misma forma que una clase. En el compartimento superior aparecen el nombre del objeto junto con el nombre de la clase subrayados, según la siguiente sintaxis:
nombre_del_objeto: nombre_de_la_clase Puede representarse un objeto sin un nombre específico, entonces sólo aparece el nombre de la clase.
3.2.3.3 Asociaciones
Las asociaciones entre dos clases se representan mediante una línea que las une. La línea puede tener una serie de elementos gráficos que expresan características particulares de la asociación. A continuación se verán los más importantes de entre dichos elementos gráficos.
3.2.3.3.1 Nombre de la Asociación y Dirección
El nombre de la asociación es opcional y se muestra como un texto que está próximo a la línea. Se puede añadir un pequeño triángulo negro sólido que indique la dirección en la cual leer el nombre de la asociación.
Los nombres de las asociaciones normalmente se incluyen en los modelos para aumentar la legibilidad. Sin embargo, en ocasiones pueden hacer demasiado abundante la información que se presenta, con el consiguiente riesgo de saturación. En ese caso se puede suprimir el nombre de las asociaciones consideradas como suficientemente conocidas. En las asociaciones de tipo agregación y de herencia no se suele poner el nombre.
3.2.3.3.2 Multiplicidad
La multiplicidad es una restricción que se pone a una asociación, que limita el número de instancias de una clase que pueden tener esa asociación con una instancia de la otra clase. Puede expresarse de las siguientes formas:
Con un número fijo: 1.
Con un intervalo de valores: 2..5.
Con un rango en el cual uno de los extremos es un asterisco. Significa que es un intervalo abierto. Por ejemplo, 2..* significa 2 o más.
Con una combinación de elementos como los anteriores separados por comas: 1, 3..5, 7, 15..*.
Con un asterisco: * . En este caso indica que puede tomar cualquier valor (cero o más).
3.2.3.3.3 Roles
Para indicar el papel que juega una clase en una asociación se puede especificar un nombre de rol. Se representa en el extremo de la asociación junto a la clase que desempeña dicho rol.
3.2.3.3.4 Agregación
El símbolo de agregación es un diamante colocado en el extremo en el que está la clase que representa el “todo”.
3.2.3.3.5 Clases Asociación
Cuando una asociación tiene propiedades propias se representa como una clase unida a la línea de la asociación por medio de una línea a trazos. Tanto la línea como el rectángulo de clase representan el mismo elemento conceptual: la asociación. Por tanto ambos tienen el mismo nombre, el de la asociación. Cuando la clase asociación sólo tiene atributos el nombre suele ponerse sobre la línea. Por el contrario, cuando la clase asociación tiene alguna operación o asociación propia, entonces se pone el nombre en la clase asociación y se puede quitar de la línea.
3.2.3.3.6 Asociaciones N-Arias
En el caso de una asociación en la que participan más de dos clases, las clases se unen con una línea a un diamante central. Si se muestra multiplicidad en un rol, representa el número potencial de tuplas de instancias en la asociación cuando el resto de los N-1 valores están fijos.
3.2.3.3.7 Navegabilidad
En el caso de una asociación en la que participan más de dos clases, las clases se unen con una línea a un diamante central. Si se muestra multiplicidad en un rol, representa el número potencial de tuplas de instancias en la asociación cuando el resto de los N-1 valores están fijos.
3.2.3.4 Herencia
La relación de herencia se representa mediante un triángulo en el extremo de la relación que corresponde a la clase más general o clase “padre”. Si se tiene una relación de herencia con varias clases subordinadas, pero en un diagrama concreto no se quieren poner todas, esto se representa mediante puntos suspensivos.
3.2.3.5 Elementos Derivados
Un elemento derivado es aquel cuyo valor se puede calcular a partir de otros elementos presentes en el modelo, pero que se incluye en el modelo por motivos de claridad o como decisión de diseño.
Se representa con una barra “/” precediendo al nombre del elemento derivado.
3.2.4 Diagrama de Casos de Uso
Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. En el diagrama de casos de uso se representa también el sistema como una caja rectangular con el nombre en su interior. Los casos de uso están en el interior de la caja del sistema, y los actores fuera, y cada actor está unido a los casos de uso en los que participa mediante una línea.
3.2.4.1 Elementos
Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y relaciones entre casos de uso
3.2.4.1.1 Actores
Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organización, y que realiza algún tipo de interacción con el sistema.. Se representa mediante una figura humana dibujada con palotes. Esta representación sirve tanto para actores que son personas como para otro tipo de actores.
3.2.4.1.2 Casos de Uso
Un caso de uso es una descripción de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea específica. Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea específica que el actor desea llevar a cabo usando el sistema.
3.2.4.1.3 Relaciones entre Casos de Uso
Un caso de uso, en principio, debería describir una tarea que tiene un sentido completo para el usuario. Sin embargo, hay ocasiones en las que es útil describir una interacción con un alcance menor como caso de uso. La razón para utilizar estos casos de uso no completos en algunos
casos, es mejorar la comunicación en el equipo de desarrollo, el manejo de la documentación de casos de uso. Para el caso de que queramos utilizar estos casos de uso más pequeños, las relaciones entre estos y los casos de uso ordinarios pueden ser de los siguientes tres tipos: • Incluye (<>): Un caso de uso base incorpora explícitamente a otro caso de uso en un lugar especificado en dicho caso base. Se suele utilizar para encapsular un comportamiento parcial común a varios casos de uso.
3.2.5 Diagramas de Interacción
En los diagramas de interacción se muestra un patrón de interacción entre objetos. Hay dos tipos de diagrama de interacción, ambos basados en la misma información, pero cada uno enfatizando un aspecto particular: Diagramas de Secuencia y Diagramas de Colaboración.
3.2.5.1 Diagrama de Secuencia
Un diagrama de Secuencia muestra una interacción ordenada según la secuencia temporal de eventos. En particular, muestra los objetos participantes en la interacción y los mensajes que intercambian ordenados según su secuencia en el tiempo. El eje vertical representa el tiempo, y en el eje horizontal se colocan los objetos y actores participantes en la interacción, sin un orden prefijado. Cada objeto o actor tiene una línea vertical, y los mensajes se representan mediante flechas entre los distintos objetos. El tiempo fluye de arriba abajo. Se pueden colocar etiquetas (como restricciones de tiempo, descripciones de acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones o activaciones a las que se refieren.
3.2.5.2 Diagrama de Colaboración
Un Diagrama de Colaboración muestra una interacción organizada basándose en los objetos que toman parte en la interacción y los enlaces entre los mismos (en cuanto a la interacción se refiere).
A diferencia de los Diagramas de Secuencia, los Diagramas de Colaboración muestran las relaciones entre los roles de los objetos. La secuencia de los mensajes y los flujos de ejecución concurrentes deben determinarse explícitamente mediante números de secuencia.
En cuanto a la representación, un Diagrama de Colaboración muestra a una serie de objetos con los enlaces entre los mismos, y con los mensajes que se intercambian dichos objetos. Los mensajes son flechas que van junto al enlace por el que “circulan”, y con el nombre del mensaje y los parámetros (si los tiene) entre paréntesis. Cada mensaje lleva un número de secuencia que denota cuál es el mensaje que le precede, excepto el mensaje que inicia el diagrama, que no lleva número de secuencia. Se pueden indicar alternativas con condiciones entre corchetes (por ejemplo 3 [condición_de_test] : nombre_de_método() ). También se puede mostrar el anidamiento de
mensajes con números de secuencia como 2.1, que significa que el mensaje con número de secuencia 2 no acaba de ejecutarse hasta que no se han ejecutado todos los 2. x .
3.2.6 Diagrama de Estados
Un Diagrama de Estados muestra la secuencia de estados por los que pasa bien un caso de uso, bien un objeto a lo largo de su vida, o bien todo el sistema. En él se indican qué eventos hacen que se pase de un estado a otro y cuáles son las respuestas y acciones que genera.
En cuanto a la representación, un diagrama de estados es un grafo cuyos nodos son estados y cuyos arcos dirigidos son transiciones etiquetadas con los nombres de los eventos.
Un estado se representa como una caja redondeada con el nombre del estado en su interior.
Una transición se representa como una flecha desde el estado origen al estado destino.
La caja de un estado puede tener 1 o 2 compartimentos. En el primer compartimento aparece el nombre del estado. El segundo compartimento es opcional, y en él pueden aparecer acciones de entrada, de salida y acciones internas.
Una acción de entrada aparece en la forma entrada/acción_asociada donde acción_asociada es el nombre de la acción que se realiza al entrar en ese estado. Cada vez que se entra al estado por medio de una transición la acción de entrada se ejecuta.
Una acción de salida aparece en la forma salida/acción_asociada. Cada vez que se sale del estado por una transición de salida la acción de salida se ejecuta.
Una acción interna es una acción que se ejecuta cuando se recibe un determinado evento en ese estado, pero que no causa una transición a otro estado. Se indica en la forma nombre_de_evento/acción_asociada.
Un diagrama de estados puede representar ciclos continuos o bien una vida finita, en la que hay un estado inicial de creación y un estado final de destrucción (finalización del caso de uso o destrucción del objeto). El estado inicial se muestra como un círculo sólido y el estado final como un círculo sólido rodeado de otro círculo. En realidad, los estados inicial y final son pseudoestados, pues un objeto no puede “estar” en esos estados, pero nos sirven para saber cuáles son las transiciones inicial y final(es).
3.3 Notación avanzada UML
3.3.1 Modelado Dinámico
3.3.1.1 Diagramas De Actividades
Vamos a recordar los diferentes modelos que sirven para representar el aspecto dinámico de un sistema:
Diagramas de secuencia Diagramas de colaboración Diagramas de estados Diagramas de casos de uso Diagramas de actividades
La idea es generar una especie de diagrama Pert, en el que se puede ver el flujo de actividades que tienen lugar a lo largo del tiempo, así como las tareas concurrentes que pueden realizarse a la vez. El diagrama de actividades sirve para representar el sistema desde otra perspectiva, y de este modo complementa a los anteriores diagramas vistos. Gráficamente un diagrama de actividades será un conjunto de arcos y nodos. Desde un punto de vista conceptual, el diagrama de actividades muestra cómo fluye el control de unas clases a otras con la finalidad de culminar con un flujo de control total que se corresponde con la consecución de un proceso más complejo. Por este motivo, en un diagrama de actividades aparecerán acciones y actividades correspondientes a distintas clases. Colaborando todas ellas para conseguir un mismo fin.
3.3.1.2 Contenido del diagrama de actividades
Básicamente un diagrama de actividades contiene:
Estados de actividad Estados de acción Transiciones Objetos
3.3.1.2.1 Estados de actividad y estados de acción
La representación de ambos es un rectángulo con las puntas redondeadas, en cuyo interior se representa bien una actividad o bien una acción. La forma de expresar tanto una actividad como una acción, no queda impuesta por UML, se podría utilizar lenguaje natural, una especificación formal de expresiones, un metalenguaje, etc. La idea central es la siguiente: “Un estado que
represente una acción es atómico, lo que significa que su ejecución se puede considerar instantánea y no puede ser interrumpida”.
3.3.1.2.2 Transiciones
Las transiciones reflejan el paso de un estado a otro, bien sea de actividad o de acción. Esta transición se produce como resultado de la finalización del estado del que parte el arco dirigido que marca la transición. Como todo flujo de control debe empezar y terminar en algún momento, podemos indicar esto utilizando dos disparadores de inicio y fin tal
3.3.1.2.3 Bifurcaciones
Un flujo de control no tiene porqué ser siempre secuencial, puede presentar caminos alternativos.
Para poder representar dichos caminos alternativos o bifurcación se utilizará como símbolo el rombo. Dicha bifurcación tendrá una transición de entrada y dos o más de salida. En cada transición de salida se colocará una expresión booleana que será evaluada una vez al llegar a la bifurcación, las guardas de la bifurcación han de ser excluyentes y contemplar todos los casos ya que de otro modo la ejecución del flujo de control quedaría interrumpida. Para poder cubrir todas las posibilidades se puede utilizar la palabra ELSE, para indicar una transición obligada a un determinado estado cuando el resto de guardas han fallado.
3.3.1.2.4 División y unión
No sólo existe el flujo secuencial y la bifurcación, también hay algunos casos en los que se requieren tareas concurrentes. UML representa gráficamente el proceso de división, que representa la concurrencia, y el momento de la unión de nuevo al flujo de control secuencial, por una línea horizontal ancha.
3.3.2 Modelado Físico De Un Sistema OO
3.3.2.1 Componentes
Los componentes pertenecen al mundo físico, es decir, representan un bloque de construcción al modelar aspectos físicos de un sistema.
Una característica básica de un componente es que debe definir una abstracción precisa con una interfaz bien definida, y permitiendo reemplazar fácilmente los componentes más viejos con otros más nuevos y compatibles. En UML todos los elementos físicos se modelan como componentes.
UML proporciona una representación gráfica para estos, en la que XXXX.dll, es el nombre del componente.
3.3.2.1.1 Interfaces
Tanto los servicios propio de una clase como los de un componente, se especifican a través de una Interfaz. Por ejemplo, todas las facilidades más conocidas de los sistemas operativos, basados en componentes (COM+, CORBA, etc.), utilizan las interfaces como lazo de unión entre unos componentes y otros. La relación entre un componente y sus interfaces se puede representar de dos maneras diferentes
3.3.2.1.2 Tipos de componentes
Existen básicamente tres tipos de componentes:
1. Componentes de despliegue: componentes necesarios y suficientes para formar un sistema ejecutable, como pueden ser las bibliotecas dinámicas (DLLs) y ejecutables (EXEs).
2. Componentes producto del trabajo: estos componentes son básicamente productos que quedan al final del proceso de desarrollo. Consisten en cosas como archivos de código fuente y de datos a partir de los cuales se crean los componentes de
despliegue.
3. Componentes de ejecución: son componentes que se crean como consecuencia de un sistema en ejecución. Es el caso de un objeto COM+ que se instancia a partir de una DLL.
3.3.2.1.3 Organización de componentes
Los componentes se pueden agrupar en paquetes de la misma forma que se organizan las clases.
Además se pueden especificar entre ellos relaciones de dependencia, generalización, asociación (incluyendo agregación), y realización.
3.3.2.1.4 Estereotipos de componentes
UML define cinco estereotipos estándar que se aplican a los componentes:
executable Componente que se puede ejecutar en un nodo.
library Biblioteca de objetos estática o dinámica.
table Componentes que representa una tabla de una base de datos.
file Componente que representa un documento que contiene código fuente o datos.
document Componente que representa un documento.
UML no especifica iconos predefinidos para estos estereotipos
3.3.2.2 Despliegue
3.3.2.2.1 Nodos
Al igual que los componentes los nodos pertenecen al mundo material. Vamos a definir un nodo como un elemento físico, que existe en tiempo de ejecución y representa un recurso computacional que generalmente tiene alguna memoria y, a menudo, capacidad de procesamiento. Los nodos sirven para modelar la topología del hardware sobre el que se ejecuta el sistema. Un nodo representa normalmente un procesador o un dispositivo sobre el que se pueden desplegar los componentes. Un nodo debe tener un nombre asignado que lo distinga del resto de nodos.
3.3.2.2.2 Nodos y componentes
En muchos aspectos los nodos y los componentes tienen características parecidas. Vamos a ver con más detalle cuales son los parecidos y las diferencias entre los componentes y los nodos. Los Nodos Los Componentes son los elementos donde se ejecutan los componentes.
Son los elementos que participan en la ejecución de un sistema.
Representan el despliegue físico de los componentes. Representan el empaquetamiento físico de los elementos lógicos.
La relación entre un nodo y los componentes que despliega se pueden representar mediante una relación de dependencia.
Los nodos se pueden agrupar en paquetes igual que los las clases y los componentes.
Los tipos de relación más común entre nodos es la asociación. Una asociación entre nodos viene a representar una conexión física entre nodos.
3.3.2.3 Diagramas de Componentes
Un diagrama de componentes muestra la organización y las dependencias entre un conjunto de componentes. Para todo sistema OO se han de construir una serie de diagramas que modelan tanto la parte estática (diagrama de clases), como dinámica (diagramas de secuencia, colaboración, estados y de actividades), pero llegado el momento todo esto se debe materializar en un sistema implementado que utilizará partes ya implementadas de otros sistemas, todo esto es lo que pretendemos modelar con los diagramas de componentes.
