análisis, diseño y desarrollo orientado a objetos de un sistema de comunicación interna

UNIVERSIDAD MAYOR DE SAN ANDRÉS Facultad de Ciencias Puras y Naturales Postgrado en Informática Análisis y Diseño Orientado a Objetos

Análisis, Diseño y Desarrollo Orientado a Objetos de un Sistema de Comunicación Interna (Proyecto Final)

Presentado a:

Dr. Esteban Saavedra L.

Presentado por: Ing. Roger Saravia A.

La Paz, Bolivia – Marzo 2 de 2009

Resumen En éste trabajo se desarrolla el análisis, diseño y desarrollo orientado a objetos (OO) de un sistema de comunicación interna para oficina; es decir, de un pequeño sistema de mensajería. Primero, se hace el planteamiento del problema. Seguidamente, se tiene la revisión bibliográfica que se enfoca directamente en los conceptos que gobiernan el paradigma OO. Posteriormente, en el desarrollo práctico, se tiene el análisis y diseño del sistema presentado mediante diagramas estáticos y dinámicos del lenguaje unificado de desarrollo o UML por sus siglas en inglés. El desarrollo de la aplicación se lleva acabo en el lenguaje OO Java para páginas Web dinámicas generadas en el lado del servidor (Java Server Pages o JSP). Finalmente, se hacen algunas conclusiones importantes.

Palabras Clave ABSTRACCIÓN, CASOS DE USO, CLASE, CLASES ABSTRACTAS, CLIENTE/SERVIDOR, COMPORTAMIENTO, COMPOSICIÓN, DIAGRAMA DE ACTIVIDADES, DIAGRAMA DE CLASES, DIAGRAMA DE COLABORACIÓN, DIAGRAMA DE COMPONENTES, DIAGRAMA DE DESPLIEGUE, DIAGRAMA DE ESTADO, DIAGRAMA DE SECUENCIA, ENCAPSULACIÓN, ESTADO, HERENCIA, IMPLEMENTACIÓN, INSTANCIACIÓN, INTERFAZ, JAVA, JSP, MAPA MENTAL, MODELO DEL NEGOCIO, OBJETO, ORIENTACIÓN A OBJETOS, PERSISTENCIA, POLIMORFISMO, RE-UTILIZACIÓN, SUBCLASE, SUPERCLASE, UML

Tabla de Contenido

1

INTRODUCCIÓN ......................................................................................................................................................... 2 1.1

OBJETIVOS ESPECÍFICOS ......................................................................................................................................... 2

2

MARCO TEÓRICO (REVISIÓN BIBLIOGRÁFICA) ............................................................................................. 2

3

DESARROLLO PRÁCTICO ....................................................................................................................................... 5 3.1 3.2 3.2.1 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10

MAPA MENTAL DE CONCEPTUALIZACIÓN .............................................................................................................. 5 CASOS DE USO ........................................................................................................................................................ 6 Especificación de Caso de Caso de Uso ........................................................................................................... 8 DIAGRAMA DE CLASES ........................................................................................................................................... 9 DIAGRAMAS DE SECUENCIA ................................................................................................................................. 10 DIAGRAMAS DE COLABORACIÓN .......................................................................................................................... 11 DIAGRAMAS DE ESTADO ....................................................................................................................................... 11 DIAGRAMA DE ACTIVIDADES................................................................................................................................ 12 DIAGRAMA DE COMPONENTES ............................................................................................................................. 13 DIAGRAMA DE DESPLIEGUE .................................................................................................................................. 15 SOBRE LA IMPLEMENTACIÓN ................................................................................................................................ 16

4

CONCLUSIONES ....................................................................................................................................................... 16

5

REFERENCIAS .......................................................................................................................................................... 16

6

APÉNDICES ................................................................................................................................................................ 17 6.1

CAPTURAS DE PANTALLA DE LA APLICACIÓN....................................................................................................... 17

1

Introducción Éste trabajo se extiende en el paradigma orientado a objetos (OO) del área de modelos conceptuales de las ciencias de la computación.

La concepción de un sistema de comunicación interna de manera tradicional o estructurada sin un modelo que permita el reconocimiento de las entidades y relaciones involucradas, es desventajosa porque podría involucrar un diseño sin el mejor de los rendimientos, sin la más alta confiabilidad y sin capacidad de ser extensible fácilmente (i. e. la dificultad del mantenimiento del código estructurado).

Una aplicación tan importante para el trabajo en oficina como es un sistema de comunicación interna, mejor debe ser diseñado y desarrollado a partir de un modelo OO que permita la abstracción de sus entidades y relaciones con el fin de que su implementación termine siendo eficiente, confiable, extensible, fácil de mantener y hasta elegante.

1.1

2

Objetivos Específicos



Conceptuar el sistema.



Modelar el sistema haciendo uso del lenguaje unificado de modelado o UML.



Desarrollar el modelo en Java para la Web (JSP).

Marco Teórico (Revisión Bibliográfica) Análisis Orientado a Objetos AOO La primera vez que se propuso un enfoque orientado a objetos para el desarrollo de software fue a finales de los años 60. Las tecnologías de objetos llevan a reutilizar y la reutilización (de componente de software) lleva a un desarrollo de software más rápido y a programas de mejor calidad.

El propósito del AOO es definir todas las clases que son relevantes al problema que se va a resolver, las operaciones y atributos asociados, las relaciones y comportamientos asociados con ellos.

Diseño Orientado a Objetos El diseño orientado a objetos transforma el modelo de análisis creado usando análisis orientado a objetos en un modelo de diseño que sirve como anteproyecto para la construcción de software.

¿Qué es un Objeto?

Un objeto es la representación de una entidad. Un objeto puede representar algo concreto como una computadora o un concepto como un proceso químico, etcétera. Un objeto es una abstracción. Un objeto tiene ESTADO y COMPORTAMIENTO.

2

ESTADO: El estado cambia con el tiempo y está definido por un conjunto de propiedades (atributos).

COMPORTAMIENTO: El comportamiento tipifica todo lo que un objeto puede realizar.

¿Qué es una Clase?

Una clase es la plantilla de un grupo de objetos con propiedades comunes (atributos) y comportamientos comunes (operaciones). Cada objeto es la instancia de una clase.

Los mensajes son los mecanismos de comunicación entre objetos.

Encapsulación Encapsular datos y comportamiento en un simple objeto es de vital importancia en el desarrollo OO. La encapsulación garantiza que los usuarios de un objeto no puedan modificar su estado sin usar su interfaz (métodos accesibles por otros objetos). La ventaja de la encapsulación radica en que si se modifica algo de un módulo interno sin alterar su interfaz, dicho cambio no implicaría ninguna modificación en el sistema.

Interfaz La interfaz es el medio fundamental de comunicación entre objetos. Cada clase deberá especificar sus interfaces para una adecuada instanciación y operación de los objetos.

Implementación Solo los atributos y métodos públicos son considerados interfaces. El usuario de un objeto debería interactuar con el mismo únicamente por medio de las interfaces; y no debería poder ver nada de la implementación (el cuerpo de los métodos)

Herencia Compartir atributos y operaciones entre clases con base en una relación jerárquica. Una clase padre (superclase) puede ser refinada en sucesivas subclases más definidas. La herencia es uno de los mecanismos más poderosos de la orientación a objetos puesto que permite la re-utilización de código.

Herencia Múltiple Recurso que permite la definición de una subclase con más de una superclase. Esto permite la combinación de dos o más orígenes.

Superclases y Subclases La superclase (o la clase padre) contiene todos los atributos y comportamientos que son comunes a las clases que heredan de ella. Estas clases que heredan de ella se denominan subclases.

3

Abstracción En la tecnología OO las clases son la abstracción fundamental. Mediante la abstracción, se parte de algunos casos concretos (objetos) de entidades y se generan clases. La abstracción consiste en estudiar los conceptos fundamentales del dominio de estudio obviando temporalmente las decisiones de diseño e implementación.

Relación “es un tipo de” Supóngase por ejemplo que, el círculo, el cuadrado y la estrella son clases que heredan directamente de una superclase llamada “figura”. Esta relación es muchas veces referida como una relación “es un tipo de” puesto que un círculo es una figura o un cuadrado es una figura. Entonces, el círculo, el cuadrado y la estrella, todas son extensiones de una figura.

Polimorfismo Mecanismo que permite a la subclase implementar la misma operación con un método diferente. La misma operación puede actuar de modos diversos en clases diferentes.

Al definir clases para figuras geométricas (rectas, circunferencias, elipses y polígonos), la operación fundamental de mover una figura se brinda al polimorfismo.

Composición Cuando los objetos están compuestos a partir de otros objetos, esto se denomina composición. Es natural pensar que los objetos siempre contienen otros objetos. Por ejemplo, una televisión contiene un sintonizador de canales y una pantalla de video.

Relación “tiene un” Aunque la relación de herencia es considerada una relación “es un tipo de” por razones discutidas anteriormente, una composición es referida como una relación “tiene un”.

Persistencia La persistencia de un objeto se refiere al concepto de guardar el estado del mismo para que pueda ser restaurado y usado posteriormente. Por ejemplo, el estado de un objeto podría ser guardado en una base de datos.

Clases Abstractas Una clase abstracta es una clase que contiene uno o más métodos sin ninguna implementación. Por ejemplo, la superclase “figura” es una clase abstracta porque no se la puede instanciar. El concepto de “figura” es abstracto.

4

Interface Java Una interface Java, a diferencia de una clase abstracta, no contiene absolutamente ninguna implementación. Entonces, cualquier clase que implemente una interface Java, deberá proveer la implementación para todos sus métodos.

Otras Consideraciones Cuando se diseñan modelos de clases y objetos, es de vital importancia entender como los objetos están relacionados entre sí.

Los conceptos primarios para la construcción de objetos son: la herencia, las interfaces y la composición.

Usando estos conceptos junto a un proceso de desarrollo de software, se está en condiciones de diseñar sólidos modelos de clases y objetos.

Unified Modeling Language (UML) UML nace como un lenguaje que permite el modelado OO. La idea inicial es que pudiera ser utilizado en cualquier método OO. Se ofrecen herramientas diversas para modelar las diferentes vistas de un problema OO.

Diagramas de UML 

Casos de Uso



Clases



Diagramas de Colaboración



Diagramas de Secuencia



Diagramas de Estado



Diagramas de Actividad



Diagramas de Componentes



Diagramas de Implantación

Ejemplo de un diagrama de casos de uso.

3

Desarrollo Práctico

3.1

Mapa Mental de Conceptualización La figura 1 muestra el mapa mental usado inicialmente para conceptuar la aplicación de comunicación interna.

5

Figura 1. Mapa mental para conceptuar la aplicación ha desarrollar.

3.2

Casos de Uso Las figuras 2, 3 y 4 muestran los diagramas de casos de uso que delatan las diversas funcionalidades de un pequeño sistema de comunicación interna.

En la figura 2 se distinguen los actores relacionados jerárquicamente. En la figura 3 se presentan los casos de uso para el actor funcionario. En la misma figura pero más abajo, se expone una herencia de casos de uso para la funcionalidad de visitar buzón. En la figura 4 se tienen los casos de uso para los actores: administrador y sistema.

Figura 2. Actores.

6

Figura 3.

Casos de Uso.

7

Figura 4. Casos de uso para los actores administrador y sistema.

3.2.1 Especificación de Caso de Caso de Uso Solo para ejemplificar, se ha redactado el texto correspondiente a la especificación del caso de uso de acceso al sistema de comunicación interna.

CU: Acceso al Sistema de Mensajería Interno (Actor: Funcionario) Descripción Consiste en el ingreso al sistema mediante la introducción de información de identidad de usuario.

Escenario principal 1. El usuario accede al servicio de mensajería interna ejecutando una aplicación cliente en su máquina.

2. El sistema presenta un formulario con 2 campos de entrada: nombre de usuario y contraseña.

3. El usuario completa el formulario con la información pertinente a su cuenta y solicita acceder presionando un botón.

4. El sistema verifica la información de la cuenta en su base de datos y acepta el ingreso del usuario al sistema mostrando inmediatamente un menú básico de funciones del mismo.

8

Escenario alternativo 4. El sistema determina que la información de entrada no coincide con ningún registro de la base de datos y muestra en mensaje pertinente rechazando su ingreso.

5. El sistema vuelve a la pantalla del formulario de acceso al sistema.

3.3

Diagrama de Clases Sobre la base de los casos de uso es posible distinguir las clases que se presentan en el sistema. La figura 5 muestra el diagrama de clases según el UML. Nótese la presencia de clases abstractas y de las relaciones de herencia, composición y dependencia.

Figura 5. Diagrama de clases del sistema.

9

3.4

Diagramas de Secuencia La figura 6 y 7 muestran los diagramas de secuencia para los casos de uso de autenticación y ver buzón, respectivamente. Nótese la presencia de las clases de frontera, de control y de entidad “personificadas” en las clases Usuario, Servicios y Fuente, respectivamente.

De secuencia para la autenticación.

Usuario

Servicios

Fuente

crear getidusuario getidusuario [id] Funcionario

[id]

agrubuzo [menú]

Figura 6. Diagrama de secuencia para la autenticación.

De secuencia para el CU: ver buzón.

:Usuario

:Buzon

:Mensaje

Servicios

Fuente

verbuzon recubuzon recumen getmensajes Funcionario

getmensajes [String] [Objeto] getbuzon getmen(i) [Mensaje] [mensajes]

Figura 7. Diagrama de secuencia para el caso de uso ver buzón.

10

3.5

Diagramas de Colaboración La figura 8 muestra el diagrama de colaboración para el caso de uso representativo ver buzón. Nótese que un diagrama de colaboración es semánticamente igual a un diagrama de secuencia.

Figura 8. Diagrama de colaboración – caso de uso ver buzón.

3.6

Diagramas de Estado La figura 9 muestra dos diagramas de estado para dos de los objetos más representativos del sistema: el objeto del tipo usuario y el objeto del tipo buzón.

11

Figura 9. Diagramas de estados para los objetos del tipo Usuario y del tipo Buzon.

3.7

Diagrama de Actividades La figura 10 muestra el diagrama de actividades para el proceso de la autenticaciรณn. Nรณtese en dicho diagrama la responsabilidad compartida entre 6 objetos.

12

De actividades para el proceso: autenticación.

Bean01

Servicios

Fuente

Funcionario

Administrador

Usuario

Obtener info Login

Iniciar y consultar

Consultar BD

[Permitido] [Administrador] [Negado] [Funcionario]

Iniciar instancia

Mostrar mensaje Iniciar instancia Iniciar

Agrupar buzones

Mostrar menú

Figura 10. Diagrama de actividades para el proceso de autenticación.

3.8

Diagrama de Componentes La figura 11 expone el diagrama de componentes organizado mediante paquetes. En dicho diagrama, nótese que además de los componentes propios del modelo, también se incluyen a los “beans” que son los componentes usados para intercambio de variables entre las páginas Web del tipo JSP (Java Server Pages).

13

Figura 11. Diagrama de componentes.

Figura 12. Diagrama de despliegue.

14

3.9

Diagrama de Despliegue La figura 12 muestra el diagrama de despliegue en el cuál se puede apreciar que en el nodo procesador servidor se hace uso de una base de datos que hace como repositorio central de la aplicación pero que en realidad contiene las tablas de la clase entidad denominada “Fuente”. Nótese también que es una aplicación del tipo cliente-servidor y basada en el protocolo TCP/IP. Tal como insinúa el nodo procesador cliente, ésta aplicación se ejecuta mediante un explorador estándar de Internet.

Figura 13. Captura de pantalla mostrando la implementación del modelo en Java (JSP).

15

3.10 Sobre la Implementación El modelo fue desarrollado en Java; específicamente para páginas Web dinámicas lado del servidor basadas en Java, las cuáles se denominan Java Server Pages (JSP). La figura 13 muestra la estructura de la aplicación (lado izquierdo de la figura) así como el código correspondiente -en éste caso- a la clase abstracta Buzon (lado derecho de la figura). Se trata entonces de una aplicación de mensajería interna de tecnología cliente-servidor cuyas capturas de pantallas representativas se tienen en los apéndices al final de éste trabajo.

4

Conclusiones Las clases no permanecen aisladas. Las clases deben ser diseñadas para interactuar con otras clases. Un grupo de clases que interactúa con otras, es parte de un sistema. Y un sistema provee valor a los usuarios finales.

Un sistema puede ser representado por diagramas de clases UML. Y varias iteraciones pueden ser requeridas hasta lograr el modelo del sistema al punto que uno está conforme con el mismo.

La composición debe ser usada cuando sea posible y la herencia debe ser usada solo cuando sea necesario.

Cuando se diseñan clases y modelos de objetos, es de vital importancia entender cómo los objetos están relacionados entre sí.

La composición puede ser de dos tipos: agregación y asociación. Mientras la herencia representa un objeto ya existente, la composición representa las interacciones entre varios objetos.

El diagrama de secuencias UML juega un papel preponderante puesto que representa la parte dinámica (en función del tiempo) del funcionamiento del modelo.

El diagrama de componentes es como un “plano” de la implementación física del modelo.

JSP es una tecnología que permite separar la presentación de una página Web de la lógica del negocio subyacente. JSP trabaja en un servidor Web y es independiente de la plataforma.

5

Referencias 

MATT WEISFELD (2004). “The Object-Oriented Thought Process”. Segunda edición.

Publishing. USA.



JOSEPH SCHMULLER (2002). “Aprendiendo UML en 24 Horas”. Prentice Hall. USA.



UNIVERSITY OF PADERBORN SOFTWARE ENGINEERING GROUP (2007). “FUJABA 2007”. [En red]. Disponible en: http://wwwcs.uni-paderborn.de/cs/fujaba/index.html



MINDJET (2008). “Technology for the way your mind works”. [En red]. Disponible en: http://www.mindjet.com/

Sams

16



JGURU (2007).

“Java Server Pages Fundamentals”.

[En red]. http://developer.java.sun.com/developer/onlineTraining/JSPIntro/index.html



ESTEBAN SAAVEDRA (2008).

Informática. UMSA. LP-BOL.



NELSON TERRAZAS (2007). “Introducción Práctica a UML”. IDELOGIX. LP-BOL.



YAILE CABALLERO (2007). "Análisis y Diseño Orientado a Objetos". Postgrado en Informática.

Universidad de Camaguey. Cuba.

Disponible en:

"Análisis y Diseño Orientado a Objetos". Postgrado en

6

Apéndices

6.1

Capturas de Pantalla de la Aplicación

Figura A.1. Pantalla caso de uso autenticación.

17

Figura A.2. Pantalla del caso de uso ver buzรณn.

Figura A.3. Pantalla del caso de uso ver mensaje.

18