análisis y diseño orientado a objetos de un sistema de comunicación interna (2)

Análisis y Diseño Orientado a Objetos de un Sistema de Comunicación Interna Ing. Roger Saravia Aramayo LP – Marzo 2, 2009

Problema 

La concepción de un sistema de comunicación interna sin un modelo que permita el reconocimiento de las entidades y relaciones involucradas, es desventajosa porque podría implicar 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).

Abordaje del Problema 

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.

Objetivos Específicos Conceptuar el sistema.  Modelar el sistema haciendo uso del lenguaje unificado de modelado o UML.  Desarrollar el modelo en tecnología cliente-servidor usando Java Server Pages (JSP). 

Marco Teórico 

Objetos, Clases, Estado, Comportamiento, Encapsulación, Interfaz, Implementación, Herencia, Superclases y Subclases, Abstracción, Polimorfismo, Composición, Persistencia, Clases Abstractas, Interface Java, UML, JSP

Desarrollo Mapa mental  Modelado mediante diagramas UML  Implementación  Demostración del sistema 

Mapa Mental

D e s e c u e n c ia p a r a la a u te n tic a c ió n .

U s u a r io

S e r v ic io s

F u e n te

c re a r g e tid u s u a r io g e tid u s u a r io [id ] F u n c io n a r io

[id ]

a g ru b u z o [m e 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]

De actividades para el proceso: autenticaciĂłn.

Bean01

Servicios

Fuente

Funcionario

Adm inistrador

Usuario

O btener info Login

Iniciar y consultar

Consultar BD

[Perm itido] [Adm inistrador] [Negado] [Funcionario] Iniciar instancia M ostrar m ensaje Iniciar instancia Iniciar

Agrupar buzones

M ostrar m enĂş

Conclusiones Las clases no permanecen aisladas. Las clases deben ser diseñadas para interactuar con otras clases.  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. 

Conclusiones La composición debe ser usada cuando sea posible y la herencia debe ser usada solo cuando sea necesario.  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. 