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.