Tesis - Dirección General de Servicios Telemáticos

Transcription

UNIVERSIDAD DE COLIMA
FACULTAD DE TELEMATICA
TESIS QUE PARA OBTENER EL GRADO DE MAESTRO EN
CIENCIAS, ÁREA DE TELEMÁTICA.
DISEÑO Y ANÁLISIS DE UN CASO DE ESTUDIO APLICADO AL
LENGUAJE DE MODELADO UNIFICADO.
PRESENTA:
ING. CARLOS ULIBARRI IRETA
ASESOR
M.C. ARMANDO ROMAN GALLARDO
COLIMA, COL. JUNIO 2002
AGRADECIMIENTOS
Al M.C. Armando Román Gallardo
Por su apoyo y orientación para la realización de este trabajo.
Al Lic. Carlos Maldonado Villaverde
Por su disposición y tiempo dedicados a ayudarme.
Al personal administrativo de la Facultad de Telmática
Por las atenciones brindadas.
DEDICATORIA
A Dios.
Por permitirme completar una meta más en mi vida.
A mis padres.
Mi respeto y amor siempre.
Por su apoyo y tenacidad para forjar mi futuro.
A mis hermanos.
Fuente infinita de la amistad más pura y el cariño más sincero.
A Hedya Nirbana
Mi gran amor.
Por su inmensa paciencia y cariño.
Siempre te admiraré.
INDICE
Página
Resumen
i
Abstract
ii
Agradecimientos
iii
Dedicatoria
iv
I.-Introducción
v
1.1 Objetivo
vii
1.2 Justificación
viii
II.- Marco Teórico y Conceptual
2.1 Plataforma Cliente- Servidor
2.1.1 Arquitectura cliente – servidor.
2
2.1.2 El cliente.
3
2.1.3 El servidor.
3
2.1.4 La red.
4
2.1.5 Ventajas de la plataforma cliente – servidor.
4
2.1.6 Desventajas de la plataforma cliente – servidor.
5
2.1.7 Retransmisión de charlas a través de Internet.
5
2.2 Lenguaje de Modelado Unificado
2.2.1 Una breve historia de UML.
8
2.2.2 Principios de Modelado.
9
2.2.3 Modelo Orientado a Objetos.
12
2.2.4 Visión general de UML.
13
2.2.5 UML es un lenguaje.
13
2.2.6 Tarjetas CRC (clase – responsabilidad – colaboración).
15
2.2.7 Casos de Uso.
16
2.2.8 Diagrama de casos de uso.
17
2.2.9 Diagramas de secuencia del sistema.
18
2.2.10 Glosario de términos.
19
2.2.11 Modelo conceptual.
19
2.2.12 Diagramas de clases.
20
2.2.13 Contratos.
21
2.2.14 Usos de UML.
22
III.- Metodología
3.1 Elaboración del marco teórico
3.2 Desarrollo del caso de estudio
25
29
IV.- Desarrollo del caso de estudio
4.1 Planeación
4.1.1 Especificación de requerimientos.
31
4.1.2 Análisis y Elaboración de las tarjetas CRC.
32
4.1.3 Definición del glosario de términos.
35
4.1.4 Definición de funciones.
35
4.1.4.1 Funciones básicas.
36
4.1.4.2 Funciones de comunicación.
37
4.1.5 Atributos de la aplicación.
37
4.1.5.1 Detalles y restricciones de frontera de los atributos. 37
4.1.5.2 Atributos del sistema.
39
4.2 Construcción del sistema
4.2.1 Casos de uso: Descripción de procesos.
40
4.2.1.1 Identificación de actores
40
4.2.1.2 Identificación de los casos de uso.
41
4.2.1.3 Caso de uso: Iniciar sesión de usuario.
41
4.2.1.4 Caso de uso: Terminar sesión de usuario.
44
4.2.1.5 Caso de uso: Enviar mensaje.
47
4.2.1.6 Caso de uso: Seleccionar zona.
49
4.2.1.7 Caso de uso: Usuario ausente.
52
4.2.1.8 Diagrama de casos de uso.
54
4.2.2 Definición de un modelo conceptual.
55
4.2.3 Ampliación del glosario de términos.
60
4.2.4 Diagrama de clases.
61
4.2.5 Definición de los diagramas de secuencia del sistema.
64
4.2.6 Definición de contratos.
70
V.- Conclusiones
Bibliografía
Anexos
74
INDICE DE TABLAS Y FIGURAS
Tabla o Figura
Página
Tabla 1. Funciones cliente – servidor
4
Figura 1. Esquema de un sistema I.R.C.
6
Figura 2. Formato de tarjeta C.R.C.
15
Figura 3. Símbolo de caso de uso.
16
Figura 4. Ejemplo de un diagrama de caso de uso.
18
Figura 5. Diagrama de secuencia de sistema.
19
Figura 6. Etapas principales del ciclo de vida.
28
Figura 7. Etapa de construcción.
29
Figura 8. Esquema de un sistema de charla.
32
Figura 9. Tarjetas C.R.C.
33
Tabla 2. Glosario de términos
35
Tabla 3. Tabla de funciones básicas.
36
Tabla 4. Tabla de funciones de comunicación.
37
Tabla 5. Tabla de atributos y restricciones.
37
Tabla 6. Atributos del sistema en la especificación de funciones.
39
Tabla 7. Identificación de actores.
40
Tabla 8. Caso de uso expandido: iniciar sesión.
42
Tabla 9. Caso de uso esencial: iniciar sesión.
42
Tabla 10. Caso de uso real: iniciar sesión.
43
Figura 10. Ventana 2 Inicio de sesión.
43
Tabla 11. Caso de uso expandido: terminar sesión.
44
Tabla 12. Caso de uso esencial: terminar sesión.
45
Tabla 13. Caso de uso real: terminar sesión.
45
Figura 11. Ventana 4 Pantalla de charla.
46
Tabla 14. Caso de uso expandido: enviar mensaje.
47
Tabla 15. Caso de uso esencial: enviar mensaje.
48
Tabla 16. Caso de uso real: enviar mensaje.
48
Figura 12. Ventana 4 Pantalla de charla.
48
Tabla 17. Caso de uso expandido: seleccionar zona.
49
Tabla 18. Caso de uso esencial: seleccionar zona.
50
Tabla 19. Caso de uso real: seleccionar zona.
50
Figura 13. Ventana 3 Zonas de charla.
51
Tabla 20. Caso de uso expandido: usuario ausente.
52
Tabla 21. Caso de uso esencial: usuario ausente.
53
Tabla 22. Caso de uso real: usuario ausente.
53
Figura 14. Ventana 4 Timer.
53
Figura 15. Diagrama de casos de uso.
54
Figura 16. Definición de conceptos.
55
Figura 17. Definición de asociaciones.
56
Figura 18. Definición de atributos.
57
Tabla 23. Significado de los atributos.
58
Figura 19. Definición de un modelo conceptual.
59
Tabla 24. Ampliación del glosario de términos.
60
Figura 20. Atributos de las clases.
61
Figura 21. Métodos de las clases.
62
Figura 22. Diagrama de clases.
62
Figura 23. Métodos de las clases con tipos de datos.
63
Figura 24. Diagrama de secuencia: iniciar sesión.
64
Figura 25. Diagrama de secuencia - entidades: iniciar sesión.
65
Figura 26. Diagrama de secuencia: terminar sesión.
66
Figura 27. Diagrama de secuencia - entidades: terminar sesión.
66
Figura 28. Diagrama de secuencia: enviar mensaje.
67
Figura 29. Diagrama de secuencia - entidades: enviar mensaje.
67
Figura 30. Diagrama de secuencia: seleccionar zona.
68
Figura 31. Diagrama de secuencia - entidades: seleccionar zona.
68
Figura 32. Diagrama de secuencia: usuario ausente.
69
Figura 33. Diagrama de secuencia - entidades: usuario ausente.
69
RESUMEN
Con esta tesis se presenta un caso de estudio analizado y diseñado con el
lenguaje unificado de modelado. Este lenguaje de diseño tiene la peculiaridad de
ser completamente orientado a objetos, característica que lo hace sobresalir entre
los lenguajes de diseño estructurado. Otro punto a su favor, es que es un lenguaje
reciente ya que los esfuerzos por crearlo comenzaron en 1994, logrando en 1997
la primera versión de este lenguaje de diseño.
Con este caso de estudio, se pretende ejemplificar en forma clara y sencilla
la metodología del diseño orientado a objetos y la forma en que se deben elaborar
los artefactos involucrados en cada etapa del mismo, especificándolos de acuerdo
a la notación del lenguaje de modelado unificado. Entre los diferentes artefactos
de diseño que se obtienen como resultado de este caso de estudio están
comprendidos:
•
Casos de uso
•
Diagramas de casos de uso
•
Diagramas de secuencia de sistema
•
Diagramas de clases
Los cuales hacen posible en el momento de especificar un diseño, que
tanto el analista, como el usuario, y los programadores visualicen el caso de
estudio de una manera uniforme.
La conclusión de este caso de estudio presenta además de los artefactos
mencionados, un análisis del panorama del lenguaje de modelado unificado y el
diseño orientado a objetos, los cuales permiten al analista adoptar posturas muy
distintas a la hora de enfocar sus esfuerzos de diseño sobre un caso particular.
RESUMEN
This thesis is a case study that is analyzed and designed, using the unified
language of modeling. This design language has the peculiarity of being totally
object oriented, a characteristic that makes it stand out among structured design
languages. Another point in its favor is that it is a relatively new language, as
efforts to create it they began in 1994, with the first version of this design language
introduced in 1997.
y la forma en que se deben elaborar los artefactos involucrados en cada
etapa del mismo, especificándolos de acuerdo a la notación del lenguaje de
modelado unificado. Entre los diferentes artefactos de diseño que se obtienen
como resultado de este caso de estudio están
This case study seeks exemplify the methodology of object oriented design
in a clear and simple way and the manner in which the artifacts involved in each
stage should be elaborated, according to the concept of unified modeling
language. Among the different design devices that are obtained as a result of this
case study are:
•
Cases of use
•
Diagrams of cases of use
•
Diagrams of system sequence
•
Diagrams of classes
These four devices make the visualization of the case study between the
analyst, the user, and the programmer more uniform at the moment of specifying a
specific design.
In conclusion, this case study presents, besides the aforementioned
devices, an analysis of the panorama of unified modeling language and object
oriented design, which allow the analyst to adopt very different postures when
focusing on design efforts in a specific case.
I.- INTRODUCCIÓN
El presente trabajo muestra un ejemplo práctico del lenguaje de modelado
unificado. En sus páginas, se escenifica un caso de estudio, el cual se somete a
un proceso de desarrollo orientado a objetos y a la especificación de artefactos de
diseño orientados al lenguaje de modelado unificado.
cuestión hace referencia a
El caso de estudio en
un sistema de comunicación orientado a la
retransmisión de charlas a través de internet, y pretende ilustrar de manera clara y
sencilla, la forma en que se elaboran los diferentes artefactos de diseño del
lenguaje de modelado unificado.
El lector encontrará también, las bases teóricas que fundamentan este caso de
estudio y las conclusiones a las que se llegaron después de haber completado
todas las fases de diseño que este caso de estudio comprende. En él se abordan
los conocimientos y habilidades necesarias para proporcionar los artefactos de
diseño básicos del lenguaje de modelado unificado, utilizados para analizar y
diseñar software .
En el primer capítulo de este trabajo, se incluye una descripción de las
metodologías aplicadas tanto a la elaboración del marco teórico, como al
desarrollo del caso de estudio; siendo de vital importancia para la comprensión e
interpretación de las conclusiones presentadas. El segundo capítulo, conformado
por el marco teórico, incluye tres temas principales que presentan un panorama
amplio, mas no exhaustivo, sobre la plataforma cliente servidor, el lenguaje de
modelado unificado y el diseño orientado a objetos. Respecto al primer tema, se
ilustran conceptos básicos así como sus ventajas y desventajas, cuya
comprensión permitirán al lector conformar un panorama general del ambiente en
el que se desarrolla el caso de estudio.
El segundo tema introduce los
componentes del lenguaje de modelado unificado (un lenguaje que permite dar un
enfoque orientado a objetos al diseño de software), los cuales fueron utilizados
para realizar este trabajo. El tercer y ultimo tema del marco teórico, hace
referencia a las nociones mínimas que son necesarias para comprender la utilidad
de los artefactos de diseño, resultado de este trabajo. El tercer capítulo, que
representa la parte medular de éste trabajo, se encuentra guiado por un caso de
estudio, que invita al lector, a comprender y aplicar el lenguaje de modelado
unificado de una manera clara y sencilla, explicando a detalle cada una de las
etapas involucradas en el proceso de desarrollo del caso de estudio y
proporcionando ilustraciones y diagramas que en su conjunto hacen
posible
especificar el diseño del caso de estudio. El capítulo 4, que conforma la parte final
de este trabajo, presenta las conclusiones, las cuales mencionan los logros
alcanzados en este trabajo, y un análisis particular sobre el lenguaje de modelado
unificado.
OBJETIVO
Analizar y diseñar un caso de estudio, aplicando los principios del Lenguaje
de Modelado Unificado.
OBJETIVO PARTICULAR
Elaborar los siguientes artefactos de diseño, de acuerdo con la notación del
lenguaje de modelado unificado: casos de uso, diagramas de casos de uso, de
colaboración, de secuencia, de clases y de paquetes de la arquitectura,
necesarios para el diseño de un sistema de comunicación enfocado a la
retransmisión de charlas a través de internet.
JUSTIFICACIÓN
Cuando se tiene la experiencia de estar en contacto con el sector laboral y el
académico referente a una profesión, resulta evidente que la caducidad del
conocimiento puede llegar en el breve momento en el que una persona se aleje de
las fuentes de nuevas ideas, esto debido al rápido desarrollo y difusión que tienen
las nuevas tecnologías. Refiriéndonos al área de la informática y los sistemas
computacionales, estas tecnologías van enfocadas tanto al hardware (que
corresponde a la parte física de una computadora) como al software (que se
refiere a las aplicaciones que una computadora puede ejecutar), y es en éste
último, en el que se enfocará la presente investigación.
El software, es sin duda, la forma más palpable para medir el desempeño de una
computadora, debido a que entre mejor diseñado esté el software aplicado a una
computadora, mayor será el aprovechamiento que se tenga del hardware, y es
aquí donde radica la importancia de un diseño eficiente del software. Es necesario
recordar que el software nace con la invención de la primera computadora, y el por
qué de su nacimiento se refiere a la necesidad de especificar una forma de
"decirle" a la computadora las tareas que debe ejecutar. Desde entonces,
numerosos y variados paradigmas han surgido en torno al diseño y elaboración de
aplicaciones de software, que con el paso del tiempo aumentan su grado de
complejidad. En este terreno de los paradigmas es que surge el lenguaje de
modelado unificado, como una alternativa para el diseño de sistemas con gran
cantidad de software. Este lenguaje de modelado unificado surge en Enero de
1997, como una respuesta a las necesidades del mercado para contar con un
lenguaje estándar de modelado; y es debido a su relativamente "corta" edad que
no se encuentra muy difundido en las escuelas, ya que este proceso requiere de
tiempo para que el lenguaje sea conocido, utilizado y comprobado por usuarios y
después llevado al ámbito académico. Refiriéndonos a éste dentro de la Facultad
de Telemática de la Universidad de Colima, el lenguaje de modelado unificado no
ha llegado a este nivel de difusión, esto con base en que los planes de estudio de
dicha Facultad, correspondientes al año de 1999, no contemplan el lenguaje de
modelado unificado en su estructura. Es por esta razón, que se presenta un caso
de estudio, en el cual se plantean de una forma clara y explícita, las etapas y
artefactos involucrados en el desarrollo de sistemas de información, utilizando el
lenguaje de modelado unificado para su especificación. La mayor importancia
radica no en el caso de estudio en particular, sino en la forma en se aplica el
lenguaje de modelado unificado para identificar y alcanzar los objetivos del diseño,
ya que éste obliga al analista, a adoptar un punto de vista orientado a objetos, el
cual es muy diferente al diseño estructurado.
II.- MARCO TEÓRICO Y
CONCEPTUAL
2.1
Plataforma Cliente – Servidor
El presente capítulo tiene como principal objetivo, ilustrar un tema
característico de la tecnología computacional denominada Arquitectura Cliente Servidor. De igual forma se pretende cumplir los siguientes objetivos:
•
Definir ¿qué es un ambiente Cliente - Servidor?
•
Citar las principales ventajas de esta plataforma.
2.1.1 Arquitectura Cliente – Servidor.
El término Cliente - Servidor se utiliza frecuentemente como sinónimo de
Proceso Cooperativo o Proceso Distribuido, es decir, distribución de aplicaciones y
/ o datos en una red de ordenadores.
Una definición de la arquitectura Cliente - Servidor desde el punto de vista
empresarial puede ser la siguiente: Distribución de los recursos computacionales a
lo largo y ancho de la organización, pero con una administración central, como un
todo único (Elizalde, 2000).
La tecnología Cliente - Servidor puede definirse como un conjunto de
elementos tanto de software como de hardware, entre los cuales se destacan tres
tecnologías: el cliente, el servidor y la red. El Servidor central quien acepta y
procesa los requerimientos de otro elemento llamado cliente, quien es el
encargado de recibir el resultado del proceso; estos dos elementos son unidos por
medio de una red de comunicaciones. Esta definición no se aleja de lo que
entendemos por una red, sin embargo lo primordial se encuentra en las
características que debe cumplir cada uno de estos elementos, pero sobre todo lo
fundamental se encuentra en la calidad del diseño que se haga para la
arquitectura, y así poder explotar todas las ventajas ofrecidas por las tres
tecnologías mencionadas.
2.1.2 El Cliente.
Es el elemento encargado de interactuar directamente con el usuario final.
Mediante éste el usuario realiza el acceso a la información sin importar el lugar en
donde se encuentre. El cliente maneja la presentación de los datos, realiza la
captura y la validación de los mismos, genera consultas ejecuta operaciones y
recibe información procedente del servidor o de otro cliente. Por lo tanto el cliente
debe contar con una gran capacidad de procesamiento, y debe poseer una
interfaz amigable para el usuario final. Una interfaz gráfica de usuario (GUI) es la
ideal para un cliente, ya que le permite realizar operaciones complejas mediante
labores sencillas como oprimir botones, los cuales están ubicados en la pantalla
gráfica; teniendo esto como consecuencia, que los usuarios finales no necesiten
conocimientos profundos sobre computación.
2.1.3 El servidor.
El servidor es el encargado de satisfacer los requerimientos del cliente.
Procesa las consultas del cliente, envía, recibe y almacena información, provee
seguridad y control de acceso. Existen varias clases de servidores: de datos, de
correo electrónico, de imágenes, de impresión, entre otros. Los servidores deben
contar con elementos que gestionen los datos, esto se lleva a cabo mediante un
Sistema Manejador de Bases de Datos (DBMS), que permita una transparencia de
acceso, de distribución y de integridad a todas las transacciones de la base de
datos. Dependiendo del diseño de la aplicación, los servidores tendrán la tarea de
acceder a la información solicitada por el cliente y procesarla, o únicamente
distribuir los datos para que sean procesados por los clientes.
Las funciones básicas de el cliente y del servidor, se resumen en forma
breve en la Tabla 1, y se muestran en forma comparativa, para permitir una mejor
comprensión de los conceptos anteriormente citados.
Funciones del Cliente
Administrar la interfaz de usuario.
Funciones del Servidor
Aceptar las solicitudes de la base de
datos de los clientes.
Aceptar datos usuario.
Procesar las solicitudes de la base de
datos.
Dar formato a los resultados y
Trasmitirlos al cliente.
Procesar la lógica de la aplicación.
Generar las solicitudes para la Base de Llevar a cabo
Datos.
integridad.
la
verificación
de
Transmitir las solicitudes de la base de Mantener los datos generales de la base
datos al servidor.
de datos.
Recibir los resultados del servidor.
Proporcionar
control
de
acceso
concurrente .
Dar formato a los resultados.
Llevar a cabo recuperación.
Optimizar
el
procesamiento
consultas/ actualización.
de
Tabla 1. Funciones Cliente y Servidor
2.1.4 La red.
La Red es elemento encargado de realizar la transmisión de los
requerimientos del cliente al servidor y del servidor al cliente. También controla la
transmisión de datos entre los diferentes servidores que conformen el ambiente.
2.1.5 Ventajas de la plataforma Cliente - Servidor.
•
Control Centralizado: el usuario final tiene el control sobre todos los clientes
de la red, de otra parte el administrador del sistema ejerce el control sobre
el servidor y sobre la red, permitiendo mantener la seguridad en la base de
datos. Un cliente podrá hacer las veces de servidor en el momento que se
requiera.
•
Sistemas Abiertos: soporta múltiples ambientes, múltiples plataformas,
múltiples manejadores de bases de datos.
•
Flexibilidad y Escalabilidad: permite reemplazar, ampliar o agregar
componentes sin necesidad de realizar grandes cambios a la aplicación.
•
Incremento de la Productividad: con las plataformas amigables, los usuarios
podrán emplear menos tiempo en la realización de las tareas que antes
eran tediosas.
•
Reducción de Tráfico: la red se descongestiona por que la manipulación de
los datos ocurre en el cliente y en el servidor, dependiendo de cuál sea la
forma más efectiva para cada tarea. La red dedica mayor tiempo a
transportar los resultados y no las consultas.
2.1.6 Desventajas de la plataforma Cliente – Servidor.
Una desventaja de los sistemas cliente servidor se refiere al control. Las
computadoras cliente operan en forma simultánea y procesan las aplicaciones en
paralelo. Surge así la posibilidad de problemas por actualización perdida y otros
problemas de control de multiusuario.
2.1.7 Retransmisión de charlas a través de Internet.
El Internet Relay Chat (IRC) es un sistema de chat que involucra un
conjunto de reglas y convenciones, así como software cliente-servidor (Lee, 1999)
. Este tipo de sistemas permite que múltiples usuarios se reúnan simultáneamente
en tertulias o debates, en los cuales cada uno va expresando sus opiniones de
forma escrita y en tiempo real (Irc, 2002). Básicamente, este tipo de sistemas esta
conformado por un sistema cliente, que se conecta a través de internet a un
sistema servidor, que es el encargado de coordinar a los usuarios y enviar los
mensajes. Esto puede interpretarse en la Figura 1:
Sistema Cliente
Sistema Cliente
Sistema Cliente
Internet
Sistema Servidor
Figura 1. Esquema un sistema I.R.C.
La plataforma cliente servidor y los sistemas de retransmisión de charlas a
través de internet, son partes fundamentales para la realización de este caso de
estudio, debido a que proporcionan el ambiente sobre el cual trabajará el sistema.
Es importante que se logre la integración de estos conceptos dentro del caso de
estudio, ya que se busca dar mayor comprensión al diseño. Los detalles de la
implementación de esta arquitectura al diseño generado en este caso de estudio
queda fuera de los objetivos del mismo.
2.2
U.M.L.: Lenguaje Unificado de Modelado
2.2.1 Una breve historia de UML.
Los lenguajes de modelado orientados a objetos aparecieron, en algún
momento, entre la mitad de los setenta y finales de los ochenta cuando los
metodologistas, enfrentados a los nuevos lenguajes de programación orientados a
objetos y a unas aplicaciones cada vez más complejas, empezaron a experimentar
con enfoques alternativos al análisis y al diseño. El número de métodos orientados
a objetos se incrementó de menos de l0 a más de 50 durante el período entre
1989 y 1994 (Booch et-al, 1999). Muchos usuarios de estos métodos tenían
problemas al intentar encontrar un lenguaje de modelado que cubriera sus
necesidades completamente por lo que basadas de estas experiencias,
comenzaron a aparecer nuevas generaciones de métodos, entre los que
destacaron de manera muy clara unos pocos métodos, en especial el método de
Booch, el método OOSE (Object-Oriented Software Engineering, Ingeniería del
Software Orientada a Objetos) de Jacobson y el método OMT (Object Modeling
Technique, Técnica de Modelado de Objetos) de Rumbaugh. En pocas palabras,
el método de Booch era particularmente expresivo durante las fases de diseño y
construcción de los proyectos, OOSE proporcionaba un soporte para los casos de
uso como forma de dirigir la captura de requisitos, el análisis y el diseño de alto
nivel, y OMT-2 era principalmente útil para el análisis y para los sistemas de
información con gran cantidad de datos.
Una masa crítica de ideas comenzó a formarse en la primera mitad de los
noventa, cuando Grady Booch (Rational Software Corporation), Ivar Jacobson
(Objectory) y James Rumbaugh (General Electric) (Booch et-al íbidem)
comenzaron a adoptar ideas de cada uno de los otros dos métodos, los cuales
habían sido reconocidos en conjunto como los tres principales métodos orientados
a objetos a nivel mundial. Como creadores principales de los métodos de Booch,
OOSE y OMT, se sintieron motivados para crear un lenguaje unificado de
modelado por tres razones:
En primer lugar, cada uno de los métodos ya estaba evolucionando
independientemente hacia los otros dos. Tenía sentido hacer continuar esa
evolución de forma conjunta en vez de hacerlo por separado, eliminando la
posibilidad de cualquier diferencia gratuita e innecesaria que confundiría aún más
a los usuarios.
Segundo, al unificar los métodos, se podría proporcionar cierta estabilidad
al mercado orientado a objetos, permitiendo que los proyectos se pusieran de
acuerdo en un lenguaje de modelado maduro y permitiendo a los constructores de
herramientas que se centraran en proporcionar más características útiles.
Tercero, se esperaba que la colaboración introduciría mejoras en los tres
métodos anteriores, ayudando a capturar lecciones aprendidas y a cubrir
problemas que ninguno de los métodos había manejado bien anteriormente.
2.2.2 Principios del modelado.
El uso del modelado tiene una historia interesante en todas las disciplinas
de ingeniería. Esa experiencia sugiere cuatro principios básicos de modelado.
Primero:
En el software, los modelos elegidos pueden afectar mucho a nuestra visión
del mundo. Si se construye un sistema con la mirada de un desarrollador de bases
de datos, probablemente el diseño este centrado en los modelos entidad-relación
que trasladan el comportamiento a disparadores (triggers) y procedimientos
almacenados. Si se construye un sistema con la mirada de un analista
estructurado, probablemente se obtendrán modelos centrados en los algoritmos,
con los datos fluyendo de proceso en proceso. Si se construye un sistema con la
mirada de un desarrollador orientado a objetos, se obtendrá un sistema cuya
arquitectura se centra en un mar de clases y los patrones de interacción que
gobiernan cómo trabajan juntas esas clases. No obstante, la cuestión es que cada
visión del mundo conduce a un tipo de sistema diferente, con diferentes costos y
beneficios.
Segundo:
Todo modelo puede ser expresado a diferentes niveles de precisión. Si se
está construyendo un rascacielos, a veces es necesaria una vista de pájaro, por
ejemplo, para ayudar a que los inversores se imaginen su aspecto externo. Otras
veces, hay que descender al nivel de los remaches, por ejemplo, cuando hay un
recorrido de tuberías enmarañado o un elemento estructural poco usual.
Eso mismo es cierto con los modelos software. A veces, un pequeño y
sencillo modelo ejecutable de la interfaz del usuario es exactamente lo que se
necesita, otras veces, hay que bajar y enredarse con los bits (Booch et-al, 1999)
como cuando se están especificando interfaces entre sistemas o luchando con
cuellos de botella en redes. En cualquier caso, los mejores tipos de modelos son
aquellos que permiten elegir el grado de detalle, dependiendo de quién está
viendo el sistema y por qué necesita verlo. Un analista o un usuario final se
centrarán en el qué, mientras que un desarrollador se centrará en el cómo. Tanto
unos , como otros querrán visualizar un sistema a diferentes niveles de detalle en
momentos diferentes.
Tercero:
Los mejores modelos están ligados a la realidad. Todos los modelos
simplifican la realidad, el truco está en asegurarse de que las simplificaciones no
enmascaran ningún detalle importante. En el software, el talón de Aquiles de las
técnicas de análisis estructurado es el hecho de que hay una desconexión básica
entre el modelo de análisis y el modelo de diseño del sistema. No poder salvar
este abismo hace que el sistema concebido y el sistema construido diverjan con el
paso del tiempo (Booch et-al íbidem).
Cuarto:
Un único modelo no es suficiente. Cualquier sistema no trivial se aborda
mejor a través de un pequeño conjunto de modelos casi independientes (Booch etal). Para comprender la arquitectura de los sistemas orientados a objetos, se
necesitan varias vistas complementarias y relacionadas entre si: una vista de
casos de uso (que muestre los requisitos del sistema), una vista de diseño (que
capture el vocabulario del espacio del problema y del espacio de la solución), una
vista de procesos (que modele la distribución de los procesos e hilos (threads del
sistema), una vista de implementación (que se ocupe de la realización física del
sistema) y una vista de despliegue (que se centre en cuestiones de ingeniería del
sistema). Cada una de estas vistas puede tener aspectos tanto estructurales como
de comportamiento. En conjunto, estas vistas representan los planos del software.
Según la naturaleza del sistema, algunos modelos pueden ser más
importantes que otros. Por ejemplo, en sistemas con grandes cantidades de datos,
dominarán los modelos centrados en las vistas de diseño estáticas. En sistemas
con uso intensivo de interfaces gráficas de usuario (GUI), las vistas de casos de
uso estáticas y dinámicas son bastante importantes. En los sistemas de tiempo
real muy exigentes, las vistas de procesos dinámicas tienden a ser más
importantes. Finalmente, en los sistemas distribuidos, como los encontrados en
aplicaciones de uso intensivo de la Web, los modelos de implementación y
despliegue son los más importantes.
2.2.3
Modelado Orientado a Objetos.
En el software hay varias formas de enfocar un modelo. Las dos formas
más comunes son la perspectiva orientada a objetos y la perspectiva algorítmica.
La visión tradicional del desarrollo de software toma una perspectiva algorítmica.
En este enfoque, el bloque principal de construcción de todo el software es el
procedimiento o función. Esta visión conduce a los desarrolladores a centrarse en
cuestiones de control y de descomposición de algoritmos grandes en otros más
pequeños. No hay nada inherentemente malo en este punto de vista, salvo que
tiende a producir sistemas frágiles.
Cuando los requisitos cambian y el sistema crece, los sistemas construidos
con un enfoque algorítmico se vuelven muy difíciles de mantener. La visión actual
del desarrollo de software toma una perspectiva orientada a objetos. En este
enfoque, el principal bloque de construcción de todos los sistemas software es el
objeto o clase. Para explicarlo sencillamente, un objeto es una cosa, generalmente
extraída del vocabulario del espacio del problema o del espacio de la solución
(Paige, 1999); una clase es una descripción de un conjunto de objetos similares
(Paige, íbidem).
Actualmente, el enfoque orientado a objetos forma parte de la tendencia
principal para el desarrollo de software, simplemente porque ha demostrado ser
válido en la construcción de sistemas en toda clase de dominios de problemas,
abarcando todo el abanico de tamaños y complejidades. Más aún, la mayoría de
los lenguajes actuales, sistemas operativos y herramientas son orientados a
objetos de alguna manera, lo que ofrece más motivos para ver el mundo en
términos de objetos.
Varias cuestiones se derivan de la elección de ver el mundo de una forma
orientada a objetos: ¿Cuál es la estructura de una buena arquitectura orientada a
objetos? ¿Qué artefactos debería crear el proyecto? ¿Quién debería crearlos?
¿Cómo deberían medirse? Visualizar, especificar, construir y documentar sistemas
orientados a objetos es exactamente el propósito, del UML.
2.2.4 Visión general de UML.
El UML es un lenguaje estándar para escribir planos de software. UML
puede utilizarse para visualizar, especificar, construir y documentar los artefactos
de un sistema que involucra una gran cantidad de software.
UML es apropiado para modelar desde sistemas de información en
empresas hasta aplicaciones distribuidas basadas en la Web, e incluso para
sistemas empotrados de tiempo real muy exigentes (Flower, 1999). Es un lenguaje
muy expresivo, que cubre todas las vistas necesarias para desarrollar y luego
desplegar tales sistemas, ya que no se debe de perder de vista que UML es el
resultado de años de experiencia y estudio en el desarrollo de software.
UML es sólo un lenguaje y por tanto es tan sólo una parte de un método de
desarrollo de software (Larman, 1999). UML es independiente del proceso de
desarrollo, aunque para utilizarlo óptimamente se debería usar en un proceso que
fuese dirigido por los casos de uso, centrado en la arquitectura, iterativo e
incremental.
2.2.5 UML es un lenguaje.
Un lenguaje proporciona un vocabulario y las reglas para combinar palabras
de ese vocabulario con el objetivo de posibilitar la comunicación (Booch et-al,
1999). Un lenguaje de modelado es aquel cuyo vocabulario y reglas se centran en
la representación conceptual y física de un sistema. Un lenguaje de modelado
como UML es por tanto un lenguaje estándar para los planos del software. El
modelado proporciona una comprensión de un sistema. Para sistemas con gran
cantidad de software, se requiere un lenguaje que cubra las diferentes vistas de la
arquitectura de un sistema mientras evoluciona a través del ciclo de vida del
desarrollo de software. El vocabulario y las reglas de un lenguaje como UML
indican cómo crear y leer modelos bien formados, pero no dicen qué modelos se
deben crear ni cuándo se deberían crear. Esta es la tarea del proceso de
desarrollo de software. Un proceso bien definido guiará a sus usuarios al decidir
qué artefactos producir, qué actividades y qué personal emplear para crearlos y
gestionarlos, y cómo usar esos artefactos para medir y controlar el proyecto de
forma global.
UML como lenguaje de modelado en la actualidad llama cada vez mas a
los programadores de sistemas a utilizarlo, debido a la rapidez y efectividad de sus
especificaciones y a que es de gran aceptación por su diseño orientado a objetos.
Este lenguaje para la especificación de software representa la herramienta básica
para cumplir con el objetivo de diseño del sistema de comunicación planteado
como objeto de estudio de este trabajo, y usado de forma conjunta con las
tecnologías y
plataformas descritas en los capítulos anteriores, permitirá una
especificación precisa y confiable del sistema que comprende el caso de estudio
de este trabajo.
Entre los diferentes artefactos que proporciona UML para el análisis y
diseño y que serán utilizados en este caso de estudio están:
•
Tarjetas CRC
•
Casos de uso
•
Diagramas de casos de uso
•
Diagramas de secuencia del sistema
•
Glosario de términos
•
Modelo conceptual
•
Diagramas de clases
•
Contratos
Cada uno de los cuales se describe a continuación.
2.2.6 Tarjetas CRC (clase-responsabilidad-colaboración)
Las tarjetas CRC son una técnica utilizadas para determinar las clases de
un sistema propuesto (Arlow, 2002), asignando responsabilidades a las clases y
encontrando todas las clases necesarias para lograr que se cumplan todas las
responsabilidades asignadas. La información se coloca en tarjetas de 4 x 6
pulgadas y en lugar de escribir en ellas atributos y métodos, se escriben
responsabilidades, colaboraciones y conocimientos. La tarjeta CRC tiene el
formato presentado en la Figura 2:
Nombre
Conocimiento
Responsabilidades
Colaboraciones
Figura 2. Formato de tarjeta C.R.C.
La tarjeta CRC se aplica en sesiones en las que normalmente participan
expertos en todo el campo del problema, como por ejemplo: analistas,
diseñadores, programadores, administradores, usuarios finales; todos aquellos
que de una u otra forma estén involucrados con el sistema y que puedan aportar
algo a su planteamiento. Durante las sesiones, se determinan cuales pueden ser
las clases candidatas con la finalidad de que formen parte del diseño del sistema.
2.2.7 Casos de Uso
Un caso de uso es, en esencia una interacción típica entre un usuario y un
sistema de cómputo (Flower, 1999). El caso de uso capta alguna función visible
para el usuario, puede ser grande o pequeño y logra un objetivo discreto para el
usuario. El caso de uso se obtiene hablando con los usuarios habituales y
analizando con ellos las distintas tareas que planear realizar con el sistema. Los
casos de uso pueden considerarse como un documento narrativo que describe la
secuencia de eventos de un actor (externo) que utiliza un sistema para completar
un proceso (Jacobson, 1992)]. Su notación en UML esta dada por un óvalo, que
en su interior contiene el nombre del caso de uso que representa como lo ilustra la
Figura 3:
Caso de
Uso
Figura 3. Símbolo de caso de uso
Los casos de uso, de acuerdo a su contenido y a su grado de abstracción
se clasifican en diferentes categorías:
•
Alto Nivel: este tipo de casos de uso, son los más básicos y sencillos
de plantear, este tipo de caos de uso describe un proceso muy
brevemente, casi siempre en dos o tres enunciados(Larman, 1999)].
Estos casos son muy sucintos y vagos en las decisiones de diseño,
pero son útiles para comenzar a analizar el problema y a partir de
ellos plantear los demás tipos de casos de uso.
•
Expandido: muestra más detalles del problema a analizar que los
casos de alto nivel, este tipo de casos suelen ser útiles para alcanzar
un conocimiento más profundo de los procesos y requerimientos
(Larman, íbidem). Por lo regular suelen plantearse con un estilo
“coloquial” y comienzan con la frase: “este caso de uso comienza”,
que es la forma que se adoptó en este caso de estudio, aunque no
es una regla a seguir.
•
Primario: esta categoría permite al diseñador, identificar o asignar
cierta prioridad a los casos de uso, siendo los primarios, aquellos que
representan los procesos comunes más importantes (Larman,
íbidem) que acontecen dentro del sistema.
•
Secundario: a esta clasificación pertenecen aquellos casos de uso
que representan procesos poco comunes o raros que se suceden
dentro del sistema.
•
Opcional: es el caso de uso que se utiliza para representar procesos
que no pueden abordarse o cuya integración al diseño no representa
ningún beneficio sustancioso.
•
Esencial: son casos expandidos que se representan en forma teórica
que tienen poca tecnología y pocos detalles de implementación
(Booch et-al 1999), mantiene un carácter abstracto, es especial a lo
que se refiere a la interfaz con el usuario.
•
Real: representan concretamente el proceso a partir de su diseño
concreto actual, sujeto a las tecnologías de entrada y de salida
(Maldonado, 1999). Este tipo de casos se apega más a la realidad
que cualquiera de los antes mencionados, y conserva una estricta
relación con la realidad de donde se abstrae el caso.
En su conjunto, todos estos tipos de casos de uso, son una poderosa
herramienta de análisis, ya que proporcionan al diseñador un enfoque desde
diferentes puntos de vista, lo cual le permite apreciar en una forma más palpable
el problema que se analiza a la vez que permite analizarlo en forma abstracta o
en forma real.
2.2.8 Diagramas de Casos de Uso.
Los diagramas de casos de uso son un artefacto importante dentro del
UML, ya que permiten modelar el comportamiento de un sistema, un subsistema
o una clase (Booch et-al 1999), según sea el caso. Estos diagramas explican
gráficamente un conjunto de casos de uso de un sistema, los actores y las
relaciones que existen entre éstos y los casos de uso. Tienen por objeto ofrecer un
diagrama contextual que permita reconocer rápidamente los actores externos de
un sistema y las formas básicas en que lo utilizan. Normalmente, un diagrama de
casos de uso contiene: Casos de uso, actores y relaciones. Los diagramas de
casos de uso tienen la siguiente forma, ilustrada en la Figura 4:
TPDV
Compra Productos
Usuario
Cajero
Registra los
Productos
Entrega el cambio de los
roductoscomprados
Fig. 4 Ejemplo de un diagrama de casos de uso
Estos diagramas muestran gráficamente los eventos que fluyen de los
actores al sistema, forman parte del análisis y su creación depende de la
formulación previa de los casos de uso. El diagrama de secuencia
es una
representación que muestra, en un determinado caso de uso, los eventos
generados por actores externos, su orden y los eventos del sistema (Larman,
1999). A todos los sistemas se les trata como una caja negra, ya que los
diagramas se centran en los eventos y operaciones involucradas en él, sin
importar la forma en que son resueltos dichos eventos y operaciones.
Un
diagrama de secuencia de sistema tiene la siguiente forma:
Comprar productos
Caso de Uso: Iniciar Sesión
Curso normal de los eventos
1.- Este caso comienza
cuando un cliente llega a una
caja de TDPV con los
productos que desea comprar.
2.- El cajero registra el
código del producto de cada
p r o d u c t o .
3.- El sistema determina el
precio del producto y agrega
la información sobre el
producto y lo agrega a la
transacción actual de ventas.
Se muestran la descripción
y el precio actual.
Cajero
: Sistema
IntroducirProducto(CUP,cantidad)
terminarVenta()
EfectuarPago(monto)
Figura.5 Diagrama de secuencia de sistema.
Estos diagramas contienen una prosa, que describe el caso de uso que se
esta representando así como las operaciones que cada uno de los actores genera.
2.2.10
Glosario de términos.
El glosario es un documento simple en el cual se definen términos. También
conocido como diccionario modelo, semejante a un diccionario de datos, incluye y
define todos los términos que requieren explicación para mejorar la comunicación
y aminorar el riesgo de malos entendidos (Booch et-al 1999). Este glosario se crea
originalmente durante la fase de planeación y elaboración conforma vayan
generándose los términos, después va perfeccionándose de continuamente en
cada ciclo de desarrollo, al aparecer nuevos vocablos. Por lo regular se realiza
junto con la especificación de requerimientos, los casos de uso y el modelo
conceptual.
2.2.11 Modelo conceptual.
Un modelo conceptual, explica a sus creadores y a los demás miembros del
equipo de desarrollo los conceptos significativos en un dominio del problema, es el
artefacto más importante a crear durante el análisis orientado a objetos, ya que de
él dependen otros artefactos de diseño. Para poder elaborar un modelo conceptual
del sistema, se debe de contar con artefactos previamente elaborados como los
casos de uso y las tarjetas CRC, aunque esto no implique que la creación sea
lineal, ya que se pueden crear los casos de uso y el modelo conceptual en forma
paralela.
Un modelo conceptual es una representación de conceptos en un dominio
del problema (Flower, 1999), el cual puede mostrar: conceptos, asociaciones entre
conceptos y atributos de conceptos. Su elaboración consta de tres etapas, la
primera, identificar los conceptos u objetos relacionados con el problema. El
segundo se refiere a la agregación e identificación de asociaciones existentes
entre los conceptos identificados. Por último se identifican y agregan los atributos,
que son características propias de cada objeto. Una vez ejecutados los pasos
anteriores, surge como resultado el modelo conceptual del sistema
2.2.12 Diagramas de clases.
Los diagramas de clases son los más utilizados en el diseño de sistemas
orientados a objetos. Un diagrama de clases muestra un conjunto de clases,
interfases y colaboraciones, así como sus relaciones (Booch et-al 1999). Estos
diagramas se utilizan para modelar la vista de diseño estática de un sistema,
además de que son importantes no sólo para visualizar, especificar y documentar
modelos, sino también para construir sistemas ejecutables, aplicando ingeniería
directa e inversa.
Los diagramas de clases describen gráficamente las especificaciones de las
clases de software y de las interfases en una aplicación. Por lo regular pueden
contener la siguiente información: clases, asociaciones, atributos, métodos,
interfases e información sobre los tipos de los atributos.
Para elaborar un diagrama de clases primero es necesario identificar cuáles
de los conceptos del modelo conceptual formarán parte de las clases del software.
Una vez identificados se deben examinar sus atributos o propiedades para
después añadirles las operaciones o métodos que cada clase puede ejecutar.
Para finalizar se definen y agregan las asociaciones que existen entra cada clase,
que por lo regular se toman del modelo conceptual.
2.2.13 Contratos.
Los contratos son otro de los artefactos que se crean en la etapa de diseño,
y están directamente relacionados con el comportamiento del sistema. Su
elaboración depende del desarrollo previo del modelo conceptual, los diagramas
de secuencia y la identificación de las operaciones. En términos generales, un
contrato se puede definir como un documento que describe lo que una operación
se propone lograr (Larman, 1999). Por lo regular se redacta en un estilo
declarativo centrándose más en lo que sucederá y no en cómo se conseguirá. En
una manera informal se puede definir al contrato como una fotografía tomada
antes y después de que se ha ejecutado alguna operación que produce cambios
en el sistema. Debe elaborarse un contrato por cada operación que exista en cada
caso de uso que se halla detectado. Un contrato cuenta con secciones que
permiten especificar información particular de cada caso de uso, y tiene el
siguiente esquema:
Nombre: Nombre de la operación y parámetros
Responsabilidades: Descripción informal de las actividades que debe cumplir la
operación.
Tipo: Especifica si es clase de software, concepto, interfaz, etc.
Referencias cruzadas: Números de referencia de las funciones del sistema.
Notas: Información adicional.
Excepciones: Casos excepcionales.
Salida: Mensajes o registros que se envían fuera del sistema.
Precondiciones: Suposiciones acerca del estado del sistema, antes de que se
ejecute la operación.
Poscondiciones: Definición del estado del sistema después de que se ha
ejecutado una operación.
Obviamente, este esquema no es obligatorio y no todas sus partes se
aplican en cada contrato. Lo que sí es obvio es que los contratos son de gran
ayuda para los diseñadores y programadores del sistema, ya que se elaboran a un
nivel más apegado a las fases de diseño y permite visualizar los posibles estados
de la información, aún cuado no se ha llegado a la etapa de implementación.
2.2.14 Usos del UML.
UML es un lenguaje para visualizar:
Para
muchos
programadores,
la
distancia
entre
pensar
en
una
implementación y transformarla en código es casi cero. Lo piensan, lo codifican.
De hecho, algunas cosas se modelan mejor directamente en código. En tales
casos, el programador todavía está haciendo algo de modelado, si bien lo hace de
forma completamente mental. Incluso puede bosquejar algunas ideas sobre una
pizarra blanca o sobre una servilleta, aunque esto genera un gran problema: cómo
comunicarlo a los demás miembros del equipo de trabajo o a los encargados de
mantenimiento del sistema. Al escribir modelos en UML se afronta este gran
problema, ya que se proporciona un modelo explícito del sistema, el cual facilita la
comunicación.
UML es un lenguaje para especificar:
En este contexto, especificar significa construir modelos precisos, no
ambiguos y completos. En particular, UML cubre la especificación de todas las
decisiones de análisis, diseño e implementación que deben realizarse al
desarrollar y desplegar un sistema con gran cantidad de software.
UML es un lenguaje para construir:
UML no es un lenguaje de programación visual, pero sus modelos pueden
conectarse de forma directa a una gran variedad de lenguajes de programación, lo
que le da cierto carácter de universalidad, a nivel de diseño. Las cosas que se
expresan mejor gráficamente también se representan gráficamente en UML,
mientras que las cosas que se expresan mejor textualmente se plasman con el
lenguaje de programación.
III.- METODOLOGÍA
3.1 Elaboración del marco teórico
Esta investigación se realizó, bajo al perspectiva de la investigación aplicada,
en la
cual
se
manejan
tres
niveles de
investigaciones concernientes al
información, ya que en las
ámbito académico es
necesario hacer
referencia, directa o indirectamente, a los todos los niveles que tienen que ver
con la información relacionada con el caso de estudio; lo que no podría ser
de otra forma, pues quedarse solamente en el plano teórico sin establecer
conexiones con la realidad empírica para poder trabajar con ésta, nos llevaría
a una formalización
de la teoría poco creativa para el desarrollo del trabajo
científico.
El primer nivel implica el manejo
de las teorías generales del diseño de
software, el cual tiene dos corrientes principales: el diseño estructurado y el diseño
orientado a objetos. Del diseño orientado a objetos, que es el que forma parte del
caso de estudio que se presenta en este trabajo, se analizaron conceptos
particulares como los lenguajes de diseño orientados a objetos, en particular, el
lenguaje de modelado unificado. El
información
proveniente de
segundo nivel
distintas
consiste
en
analizar
fuentes, como: investigaciones
documentadas en bibliotecas e informes publicados en Internet relacionados con
el lenguaje de modelado unificado, elaborando las fichas bibliográficas
correspondientes . Entre éstas diversas fuentes se contó además, con la
entrevista cualitativa, que es la recopilación de información en forma directa, cara
a cara, es decir, el entrevistador obtiene datos del entrevistado siguiendo una serie
de preguntas preconcebidas (Muñoz, 1998). En el proceso de análisis de la
información, debió distinguirse entre la aquella que resulta significativa para
estudiar el problema y la que por estar dirigida a otras situaciones, no tiene
puntos en común con la problemática a tratar, o simplemente resulta inoperante.
El propósito fue, básicamente, contar con información confiable y congruente con
la realidad. El tercer nivel implica el manejo de información obtenida mediante
un acercamiento con la realidad, esto a través de la entrevista realizada a Carlos
Maldonado Villaverde, y las pláticas sostenidas con el asesor de este trabajo, y de
mi experiencia sobre el tema. En éste nivel, se recopila información sobre los
aspectos más sobresalientes de este caso de estudio, como son conceptos
generales del diseño orientado a objetos, la plataforma de aplicación, y el lenguaje
de diseño. Los tres niveles del marco teórico se integran en una visión de la
totalidad que
permite
contextualizar concretamente el
caso de estudio en
cuestión. Evidentemente, la integración de todos estos elementos se hizo de
una manera que se observe coherencia en la presentación de materiales
teóricos, así como de todas las ideas que se manejan. Esto permite tener una
idea más clara y exacta de los principios y reglas que intervienen en el
de estudio de este trabajo.
caso
3.2 Desarrollo del caso de estudio
La parte fundamental de este caso de estudio se presenta en el capítulo 4, el cual
se refiere al análisis y el diseño de un sistema de comunicación. Para llevar a cabo
dicho análisis y diseño se utilizó la metodología que dicta el ciclo de vida iterativo.
Este ciclo para desarrollar sistemas se basa en el agrandamiento y
perfeccionamiento secuencial de un sistema a través de múltiples ciclos de
desarrollo de análisis, diseño, implementación y pruebas, (Larman, 1999) y tiene
como principal característica, un incremento gradual de la complejidad, de tal
forma que el problema se aborda desde un enfoque general al principio, y
conforme se va avanzando en el proceso, la complejidad aumenta poco a poco.
Este ciclo de vida consta de tres etapas principales, las cuales se muestran a
continuación en la Figura 6:
Planeación y
elaboración
Construcción
Aplicación
Figura 6. Etapas principales del ciclo de vida
Para pasar de una etapa a otra, deben cumplirse ciertas tareas, las
correspondientes a la primera etapa, la de “planeación”, son aquellas involucradas
en la planeación del tiempo y definición de requerimientos del sistema. Esta etapa
de “planeación” también incluye tareas de análisis y definición de requerimientos.
Como parte inicial del proceso de análisis, se deben identificar palabras “clave”
que permitan entender en un lenguaje natural, los actores; que son los que llevan
a cabo los casos de uso (Flower, 1999), y los demás objetos que intervienen
dentro del ámbito del sistema. Como resultado de este proceso de identificación
surge el glosario de términos, que es de gran utilidad, ya que en él estarán
contenidos los nombres de los objetos y procesos clave que formaran parte del
diseño. En cada etapa del proceso de desarrollo, el glosario se va enriqueciendo y
perfeccionando, con la finalidad de incluir en él, todos los conceptos que estén
relacionados con el sistema. Una vez concluida la 1ra. etapa, comienza la etapa
de “construcción”, cuyos componentes se definen a continuación el la Figura 7:
Planeación y
elaboración
Aplicación
Construcción
Ciclo de
Ciclo de
desarrollo 1
desarrollo 2
...
Figura 7. Etapa de construcción.
La etapa de “construcción” es la más importante de este ciclo de vida, ya que es
en ella donde se da el proceso iterativo. Teniendo como inicio del planteamiento
del problema el resultado de la etapa de “planeación”, la etapa de “construcción”
consta de varios ciclos (los que sean necesarios), de los cuales, el primero de
ellos se alimenta de la información recabada en la etapa de “planeación”. Después
de haber comenzado el primer ciclo, se continuó con cada una de las tareas
señaladas con la finalidad de llegar a aquellas relacionadas con el análisis y el
diseño. Es importante puntualizar, que no se hizo un uso extensivo de el ciclo de
vida iterativo ya que este comprende tareas de construcción y pruebas, las cuales
no son el objetivo de este caso de estudio, razón por la cual, en este caso
particular se aplicó un solo ciclo, haciendo exhaustiva cada tarea comprendida
dentro del mismo para lograr un buen resultado. Otra de las razones por las que
no fue posible presentar todas las etapas del ciclo de vida es que las tareas de
“construcción” y “pruebas” de cada ciclo, aportan información vital que debe ser
tomada en cuenta para el ciclo siguiente, de tal forma que esa conexión se
perdería debido a que la finalidad de este caso de estudio es el análisis y diseño
de un sistema de comunicación, dejando a un lado las acciones correspondientes
a la implementación.
IV.- DESARROLLO DEL CASO DE
ESTUDIO.
4.1 Planeación
4.1.1 Especificación de requerimientos.
La aplicación que se utilizará como caso de estudio debe cumplir con las
siguientes características:
•
Entorno de trabajo basado en Internet (plataforma cliente / servidor).
•
Diseño orientado a objetos.
•
Enfocada a la retransmisión de charlas a través de Internet.
Las cuales son discutidas en el marco teórico. En el caso de estudio que se
aplica a este trabajo, se plantea un sistema de charla (cliente) en el que cada
usuario tiene la posibilidad de conectarse a Internet e intercambiar mensajes con
los demás usuarios independientemente de su localidad geográfica. Internamente,
por motivos de organización, un sistema de charla, esta dividido en zonas y éstas
a su vez en canales, aunque la configuración de cada sistema en particular puede
variar, para el caso de estudio de este trabajo, se considerará un sistema de
charla compuesto por 4 zonas principales, denominadas: alfa, beta, gamma y
delta, dentro de las cuales se pueden encontrar n usuarios entablando
conversaciones individuales. Esta organización se ilustra en la Figura 8:
Sistema de charla
Zona Alfa
Zona Beta
Usuario
Usuario
Usuario
Usuario
Usuario
Usuario
Usuario
Usuario
Usuario
Usuario
Zona Delta
Zona Gamma
Usuario
Usuario
Usuario
Usuario
Usuario
Usuario
Figura 8. Esquema de un sistema de charla.
4.1.2
Análisis
y
elaboración
de
las
tarjetas
CRC
(clase-
responsabilidad-colaboración).
Una vez elaboradas las tarjetas CRC, se aplicaron obteniendo como
resultado 4 tarjetas CRC que se ilustran a continuación en la Figura 9:
Mensaje
Conocimiento:
Destino
Responsabilidades
Llegar al destino
Remitente
Contenido
Colaboraciones
Usuario destino
Usuario remitente
Zona
Registro_Usuario
Conocimiento:
Zona
Responsabilidades
Registrar ingreso de usuario
Alias
Dirección IP
Colaboraciones
Mensaje
Zona
Zona
Conocimiento:
Cantidad de usuarios
Responsabilidades
Admitir usuarios
Nombre de la zona
Expulsar usuarios
Colaboraciones
Usuario
Usuario
Conocimiento:
Alias
Responsabilidades
Charlar
Colaboraciones
Usuario destino
Usuario remitente
Zona
Figura 9. Tarjetas C.R.C.
Las tarjetas CRC son de vital importancia, ya que de ellas se desprende el
análisis orientado a objetos. La tarjeta con el nombre “mensaje”, define cuáles son
las colaboraciones, responsabilidades y conocimientos de un objeto “mensaje”
dentro del sistema de charla. De forma análoga se obtiene la información respecto
a los objetos: “zona”, “registro usuario” y “usuario”. Cabe aclara que existe una
diferencia entre “usuario” y “registro usuario”, debido a que “usuario” es
considerado como una entidad que genera la mayoría de las operaciones en el
sistema, y el “registro usuario” contiene información correspondiente a la ubicación
del usuario, su alias y la zona en la que se encuentra. Como resultado de la
aplicación de las tarjetas CRC, el diseño conceptual, la identificación de los
diagramas de uso y la elaboración de los demás artefactos se tornará una tarea
más fácil.
4.1.3 Glosario de Términos.
Las tarjetas CRC han aportado información que necesita ser incluida en el
glosario de términos, con la finalidad de comenzar a identificar los componentes
de sistema de charla, razón por la cual son agregados en esta etapa,
asignándoles una categoría y un comentario que los describa, ilustrados en la
Tabla 2:
Término
Categoría
Mensaje
Tipo
Registro_Usuario
Tipo
Usuario
Zona
Tipo
Tipo
Comentarios
Cadena de caracteres enviada y recibida por
los usuarios
Acción de registrar usuarios que ingresan al
sistema
Persona que interviene en una charla
Lugar común donde pueden encontrarse n
usuarios charlando
Tabla 2. Glosario de términos
4.1.4 Definiciones de funciones.
Después de elaborar el glosario, se realiza un análisis que describe las
funciones básicas de la aplicación así como sus funciones de comunicación,
dando por entendido, que las funciones básicas se refieren a las acciones que
permitan a un usuario hacer uso del sistema de charla, y que las funciones de
comunicación hacen referencia a las acciones necesarias para lograr una
conectividad transparente entre los usuarios del sistema de charla. También se
especifica un número de referencia para cada función con la finalidad de
identificarlas más fácilmente; y una categoría, a la cual pertenecen de acuerdo a
sus características. Las categorías de las funciones pueden ser: evidente, oculta y
superflua. Las funciones evidentes corresponden a acciones que son inevitables y
que deben llevarse a cabo. Las funciones ocultas son aquellas de las cuales el
usuario final no debe tener un pleno conocimiento. Por último, las funciones
superfluas son opcionales y su inclusión o exclusión del diseño no representa
ningún inconveniente para el sistema.
Se deben definir los requerimientos de la aplicación y las funciones que
habrán de dar solución a tales requerimientos, para este proceso es recomendable
la lluvia de ideas y el análisis del panorama general de la aplicación. Debe
recordarse que estas actividades se sitúan en la primera fase de la etapa de
desarrollo. Se definen 2 tipos diferentes de funciones, las básicas y las de
comunicación.
4.1.4.1 Funciones Básicas.
Las siguientes funciones definen una lista de tareas que deben estar
contempladas en la aplicación. La forma de interpretar la siguiente tabla es “El
sistema debe tener una función que” y a continuación la definición de cada
función, esto se muestra en la Tabla 3:
R#
R.1.1
R.1.2
R.1.3
R.1.4
R.1.5
R.1.6
R.1.7
R.1.8
R.1.9
Función
Categoría
Permita introducir una identificación y contraseña para
hacer uso de la aplicación.
Permita elegir un canal a explorar.
Ofrezca un mecanismo de almacenamiento para los
datos del usuario.
Ofrezca mecanismos de comunicación entre la
aplicación cliente y servidor.
Permita elegir una zona a explorar.
Muestre la cantidad de usuarios activos en el sistema.
Permita el inicio de sesión en el sistema.
Permita finalizar la sesión en el sistema.
Detecte cuando un usuario este ausente del sistema.
Evidente
Tabla 3. Funciones básicas.
Evidente
Oculta
Oculta
Evidente
Evidente
Evidente
Evidente
Oculta
4.1.4.2 Funciones de Comunicación.
Estas
funciones
ilustran
las
acciones
necesarias
para
lograr
la
comunicación entre los usuarios del sistema, así como tareas de administración
propias del sistema. Tales funciones se muestran en la Tabla 4:
R#
R.2.1
R.2.2
R.2.3
R.2.4
R.2.5
R.2.6
Función
Categoría
Permita seleccionar el usuario al que se quiere enviar
un mensaje.
Permita enviar los menajes a los usuarios
Verifique que el alias del usuario no este repetido
Elimine a los usuarios que cierran su sesión
Notifique a todos los usuarios de un canal cuando
llegue un nuevo usuario
Notifique cuando llegue un mensaje
Evidente
Oculta
Oculta
Oculta
Oculta
Oculta
Tabla 4. Funciones de comunicación.
4.1.5 Atributos de la aplicación.
Los atributos de la aplicación son sus características o dimensiones, no son
funciones (Larman, 1999), por ejemplo:
•
Facilidad de uso.
•
Tiempo de respuesta.
•
Metáfora de interfaz.
•
Plataforma.
Algunos atributos tienen restricciones de frontera, que son generalmente
rangos de valores numéricos para un atributo.
4.1.5.1 Detalles y restricciones de frontera de los atributos.
Para el sistema de comunicación, se han determinado los siguientes
atributos, contenidos en la Tabla 5:
Atributo
Detalles y restricciones de frontera
Plataforma
Metáfora de la interfaz
(Detalle) Sistema operativo Microsoft Windows 95, 98.
(Detalle) Gráfico, orientado a la metáfora de una forma
y cuadros de diálogo. De navegación fácil con el uso
del mouse.
Tabla 5. Atributos y restricciones del sistema.
Es muy útil describir que funciones se relacionan con los atributos
especificados anteriormente, y también clasificar los detalles y las restricciones en
obligatorios u opcionales. La siguiente tabla muestra algunas de las relaciones
entre funciones y atributos, así como sus detalles, restricciones de frontera y
categoría a la que pertenecen.
4.1.5.2 Atributos del sistema en las especificaciones de funciones.
Después de determinar las restricciones de frontera, es conveniente
describir todos los atributos del sistema que se relacionen claramente con las
funciones especificadas en la Tabla 3 y 4, estas relaciones se ilustran en la Tabla
6:
Ref.
#
Función
Categoría
ATRIBUT
Detalles y
restricciones
Categoría
O
R.1.6
Permita elegir una
zona de charla.
Evidente
R.1.7
Muestre
la
cantidad
de
usuarios activos
en el sistema.
Evidente
R.1.8
Muestre
la
cantidad
de
usuarios de una
zona.
Evidente
R.1.9
Detecte
cuando
un usuario este
ausente
del
sistema.
Oculta
Tiempo de (Restricción de
respuesta frontera) Cuando un
usuario entre a una
zona, la información
relativa a este debe
aparecer en 10
segundos máximo.
(Detalle) Rápida
respuesta.
usuario entre al
sistema de charla,
la información
relativa a la
cantidad de
usuarios debe
aparecer en 10
segundos máximo.
(Detalle) Rápida
respuesta.
usuario entre a una
zona, la información
relativa a esa zona
debe aparecer en
10 segundos
máximo.
(Detalle) Rápida
respuesta.
usuario este
ausente del sistema
de charla durante
un máximo de 15
minutos, éste lo
Obligatoria
Obligatoria
Obligatoria
Obligatoria
terminará su sesión
en forma
automática.
Tabla 6. Atributos del sistema en las especificaciones de funciones.
.
4.2 Construcción del sistema
4.2.1 Casos de uso: Descripción de procesos.
Continuando con el diseño según los patrones de UML, se deben construir
los casos de uso, los cuales describen la secuencia de eventos que un actor del
sistema, lleva a cabo para completar un proceso. Los casos de uso son
descripciones narrativas de los procesos del dominio (Larman, 1999). En el marco
teórico se hace referencia a los diferentes tipos de casos de uso que existen, de
los cuales, ejemplificaremos los siguientes:
•
Caso de uso de alto nivel
•
Caso de uso Expandido
•
Caso de uso Esencial
•
Caso de uso Real
4.2.1.1 Identificación de actores.
Antes de presentar los casos de uso, se deben identificar los actores y los
procesos relevantes a los que dan inicio. El actor identificado para este caso de
estudio es el que se muestra en la Tabla 7:
Actor
Usuario
•
•
•
•
Funciones que realiza
Ingresa a Zonas
Envía mensajes
Cambia de zonas
Termina Sesiones
•
Inicia Sesiones
Tabla 7. Identificación de actores.
Una vez identificados los actores, se procede a plantear los casos de uso
en los que se ven involucrados; los cuales se muestran en la siguiente sección.
4.2.1.2 Identificación de Casos de Uso.
Los casos de uso que se presentan a continuación, son los que se han
detectado en la fase del análisis, y tienen el siguiente formato:
•
Caso de alto nivel
•
Caso expandido
•
Caso esencial
•
Caso real
A los formatos de los casos de uso se puede hacer referencia en el marco
teórico, capítulo 2.
4.2.1.3 Caso de Uso: Iniciar sesión de usuario.
El primer caso de uso corresponde al que lleva por nombre “Iniciar sesión
de usuario”. Este caso de uso es de tipo primario y escenifica las acciones
correspondientes al ingreso del usuario al sistema de charla.
Caso de uso Alto Nivel: Iniciar sesión de usuario.
Actores: Usuario.
Tipo : Primario.
Descripción: El usuario entra al sistema y comienza la charla.
Caso de uso Expandido: Iniciar sesión de usuario.
Actores: Usuario.
Tipo : Primario.
Descripción: El usuario entra al sistema y comienza la charla.
Referencias Cruzadas:
R1.7, R1.6, R2.3, R2.5.
Iniciar sesión
de usuario
Curso normal de los eventos.
Acción del Actor
1.- Este caso comienza cuando un
usuario quiere ingresar al sistema de
charla.
2.-.El usuario notifica al sistema que
desea iniciar su sesión por medio de
una acción.
4.- El usuario escoge un nombre y un
dominio para ingresar en él.
Respuesta del sistema
3.- El sistema responde solicitando un
nombre y un dominio a los cuales se
desea ingresar.
5.- El sistema da la bienvenida
T ab la 8 . Ca so d e us o e xpa nd ido : in iciar se s ión.
Cursos alternos:
Línea 3: El nombre no es válido. Indicar error.
Caso de uso Esencial: Iniciar sesión de usuario.
Acción del Actor
1.- El usuario decide ingresar al sistema
de charla.
3.-.El usuario especifica la información
requerida.
2.- Le requiere al usuario un nombre y
un dominio en el que desea ingresar.
4.-Verifica el nombre, da acceso al
dominio y notifica la llegada de un nuevo
usuario.
T ab la 9 . Ca so d e us o e sen c ia l: in ic ia r s es ión .
Caso de uso Real: Iniciar sesión de usuario.
Acción del Actor
1.- Por medio de un icono en su
computadora el usuario, ejecuta el
programa que carga el sistema de
charla.
3.-.El usuario escribe su “alias” en la
caja de texto correspondiente y hace
presiona el botón “aceptar” o la tecla
<Enter>
2.- Presenta la ventana2 que contiene la
caja de texto3, para que el usuario
ingrese un “alias” que le permita
identificarse.
4.-Verifica que el “alias” del usuario no
este repetido y muestra la ventana3 con
cuatro botones que contienen los
nombres de los dominios a los que el
usuario puede ingresar.
El sistema ingresa el alias en una tabla
que le permite almacenar todos los
“alias” disponibles.
5.-El usuario presiona el botón 6.- Lo ingresa al dominio, mostrándole la
correspondiente al dominio al que desea ventana4, que contiene la caja de texto4
ingresar
para enviar mensajes, la lista1 de los
usuarios disponibles, la caja de texto5
que muestra el historial de las
conversaciones y tres botones, uno para
mandar mensajes, otro para cambiar de
dominio y uno más para terminar la
sesión con el sistema. Además notifica a
los demás usuarios mediante un sonido
y un mensaje que un nuevo usuario a
ingresado al dominio.
T ab la 1 0 . Ca so de u so r ea l: in ic iar se s ión.
Figura 10. Ventana 2 Inicio de sesión.
4.2.1.4 Caso de Uso : Terminar sesión de usuario.
El segundo caso de uso identificado, tiene el nombre “Terminar sesión de
usuario”, y corresponde a las acciones relacionadas con la salida del usuario del
sistema de charla; este caso también esta clasificado como primario.
Caso de uso Alto Nivel: Terminar sesión de usuario.
Actores: Usuario, sistema.
Tipo : Primario.
Descripción: El usuario notifica al sistema que desea terminar su sesión y
sale del sistema.
Caso de uso Expandido: Terminar sesión de usuario.
Actores: Usuario.
Tipo : Primario.
Descripción: El usuario notifica al sistema que desea terminar su sesión y
sale del sistema.
Referencias Cruzadas:
R1.8, 2.4.
Terminar sesión
de usuario
CURSO NORMAL DE LOS EVENTOS
Acción del Actor
1.- Este caso de uso comienza cuando 2.- El sistema notifica a los demás
el usuario notifica al sistema por medio usuarios que un usuario saldrá y lo
de una acción, que desea terminar su elimina del sistema de charla.
sesión.
T ab la 1 1 . Ca so de u so e xp an d ido : ter mina r s es ión .
Caso de uso Esencial: Terminar sesión de usuario.
Acción del Actor
1.- El usuario notifica al sistema 2.- El sistema termina la sesión del
mediante una acción, que desea usuario, eliminándolo del sistema ,
terminar su sesión.
cerrando su ventana de charla y
notificándolo a los demás usuarios.
T ab la 1 2 . Ca so de u so e se n cia l: te r min ar se s ión .
Caso de uso Real: Terminar sesión de usuario.
Acción del Actor
1.- Desde su ventana de charla, el
usuario presiona el botón “Cerrar
Sesión”.
3.-.El usuario presiona el botón
“aceptar” o la tecla <Enter>
2.- El sistema mediante una caja de
mensaje solicita una confirmación al
usuario.
4.-El sistema elimina al usuario
borrándolo de la lista1 incluida en la
ventana4 de todos los usuarios del
dominio correspondiente. Cierra la
ventana4 del usuario que solicita
terminar su sesión y notifica a los demás
usuarios por medio de un sonido y un
mensaje con el formato “El usuario
<Alias> ha salido del sistema” en la caja
de texto5, que un usuario sale del
sistema. El sistema elimina el “alias” del
usuario de la tabla que contiene los
“alias” disponibles.
T ab la 1 3 . Ca so de u so r ea l: ter mina r se s ión.
Figura 11. Ventana 4 Ventana de charla.
4.2.1.5 Caso de Uso: Enviar Mensaje.
El tercer caso de uso se denomina “Enviar mensaje”, esta clasificado como
primario y corresponde a las acciones implicadas en el envío de mensajes entre
dos usuarios.
Caso de uso Alto Nivel: Enviar mensaje.
Tipo : Primario.
Descripción: El usuario selecciona un usuario destino y le envía un
mensaje.
Caso de uso Expandido: Enviar mensaje.
Tipo : Primario.
Descripción: El cliente elabora un mensaje, elige al usuario destino y le
envía el mensaje.
Referencias Cruzadas: R2.2, R2.6
Enviar mensaje
Acción del Actor
1.- Este caso de uso comienza cuando 2.- El sistema analiza el “alias” del
un usuario desea enviar un mensaje. El usuario destino y le hace llegar el
usuario elabora el mensaje y elige al mensaje
usuario al que va dirigido y mediante
una acción envía el mensaje.
T ab la 1 4 . Ca so de u so e xp an d ido : En v ia r Men sa je
.
Caso de uso Esencial: Enviar Mensaje.
Acción del Actor
1.- El usuario redacta un mensaje y 2.- El sistema analiza el “alias” para
selecciona el usuario destino, y determinar su localización y le hace
mediante una acción envía el mensaje. llegar el mensaje, mostrándoselo en la
ventana de charla
T ab la 1 5 . Ca so de u so e se n cia l: Env iar Me ns a je
Caso de uso Real: Enviar mensaje.
Acción del Actor
1.- Desde la ventana4, el usuario
redacta un mensaje en la caja de texto4,
selecciona a un usuario destino de la
lista1 y presiona el botón “enviar
mensaje”.
2.- El sistema extrae el “alias” del
usuario destino
desde la lista1 de
usuarios y le envía el mensaje. En la
ventana4 del usuario destino, muestra el
mensaje en la caja de texto5
T ab la 1 6 . Ca so de u so r ea l: En v iar Men sa je
Figura 12. Ventana 4 Ventana de charla.
4.2.1.6 Caso de Uso: Seleccionar Zona.
El cuarto caso de uso denominado “Seleccionar Zona” y clasificado también
como primario, hace referencia a las acciones necesarias para cambiar de zona
de charla.
Caso de uso Alto nivel: Seleccionar Zona.
Actores: Usuario.
Tipo : Primario.
Descripción: El usuario cambia la zona de charla.
Caso de uso Expandido:
Seleccionar zona.
Actores: Usuario.
Tipo : Primario.
Descripción: El usuario cambia la zona de charla.
Referencias cruzadas: R1.5
Casos de uso: El usuario debe haber terminado el caso de uso “Iniciar
sesion”
Seleccionar
Zona
Acción del Actor
1.- Este caso de uso comienza cuando
el usuario desea cambiarse a otra zona
de charla mediante una acción se lo
notifica al sistema.
3.-.El usuario selecciona una zona e
ingresa a ella.
2.- El sistema recibe la petición del
usuario de cambio de zona y procede a
mostrar al usuario, las zonas disponibles
a las que puede entrar.
4.- El sistema notifica a los usuarios de
la zona seleccionada, que un nuevo
usuario ha ingresado.
T ab la 1 7 . Ca so de u so e xp an d ido : Se lec c io na r Zon a.
Caso de uso Esencial: Seleccionar Zona.
Acción del Actor
1.- El usuario, mediante una acción
desde la ventana de charla, indica al
sistema que desea cambiar su zona de
charla.
3.- El usuario selecciona una de las
zonas mostradas.
2.- El sistema solicita una confirmación
para el cambio y le muestra al usuario la
ventana de zonas, la cual contiene los
zonas disponibles.
4.-El sistema ingresa al usuario a la
zona seleccionada y le notifica a los
demás usuarios de la zona, que un
nuevo usuario ha ingresado.
T ab la 1 8 . Ca so de u so e se n cia l: Se le cc ion ar Zo na .
Caso de uso Real: Seleccionar Dominio.
Acción del Actor
1.- Desde la ventana4, el usuario 2.- El sistema mediante una caja de
presiona el botón “cambiar de zona”.
mensaje solicita una confirmación al
usuario, con el mensaje “Seguro que
desea cambiar de zona”.
3.-El usuario presiona el botón “Aceptar” 4.- El sistema muestra la ventana3 al
usuario, la cual contiene las zonas
disponibles y espera la selección del
usuario.
5.-El usuario presiona el botón 6.- El sistema cambia al usuario a la
correspondiente a la zona a la que zona seleccionado y le muestra la
desea entrar.
vanetana4, que contiene en la lista1, los
usuarios disponibles en ese zona.
El sistema notifica a los demás usuarios
de la zona mediante un mensaje en la
caja de texto5 con el “El usuario <Alias>
ha ingresado”, que un nuevo usuario ha
ingresado
T ab la 1 9 . Ca so de u so r ea l: Se le c c ion ar Zona .
Figura 13. Ventana 3 Zonas de charla.
4.2.1.7 Caso de Uso: Usuario Ausente.
El quinto caso de uso denominado “Usuario ausente” y clasificado también
como primario, hace referencia a las acciones que lleva a cabo el sistema, cuando
el usuario muestra señales de inactividad durante un tiempo determinado.
Caso de uso Alto nivel: Usuario ausente.
Actores: Sistema.
Tipo : Primario.
Descripción: El sistema detecta que un usuario esta ausente o ha dejado de
mandar mensajes durante un tiempo determinado.
Caso de uso Expandido: Usuario ausente.
Actores: Sistema.
Tipo : Primario.
Descripción: El sistema detecta que un usuario esta ausente o ha dejado de
mandar mensajes durante un tiempo determinado.
Referencias cruzadas: R1.9
Usua rio
ause nte
Acción del Actor
1.- Este caso de uso comienza cuando
el sistema determina que un usuario ha
dejado de mandar mensajes durante un
período determinado y decide expulsarlo
del sistema de charla, terminando su
sesión.
T ab la 2 0 . Ca so de u so e xp an d ido : Us uar io Au sen te.
Caso de uso Esencial: Usuario ausente.
Acción del Actor
1.- El sistema detecta cuales usuarios
no han mandado un mensaje en un
periodo de 10 minutos, en caso de que
alguno esté en ésta situación es
expulsado del sistema de charla.
T ab la 2 1 . Ca so de u so e se n cia l: Us ua r io Au se nte .
Caso de uso Real: Usuario ausente.
Acción del Actor
2.- El sistema monitorea el estado del
botón “enviar mensaje” contenido en la
ventana4. Cada vez que es presionado
se activa el timer1, el cual tiene un
tiempo de expiración de 10 minutos, si
el botón “enviar mensaje” no es
presionado antes de que el timer1
expire entonces el usuario es expulsado
del sistema de charla.
T ab la 2 2 . Ca so de u so r ea l: Usu ar io Aus en te .
Figura 14. Ventana 4- timer
4.2.1.8 Diagramas de casos de uso.
Una vez definidos los casos de uso, se elabora un diagrama que permite
una evaluación gráfica de cada uno de los casos planteados, con la finalidad de
ilustrar en una forma más explícita las relaciones entre los actores y los procesos
que cada uno de ellos genera. En este diagrama, que se ilustra en la Figura 15, se
delimita también la frontera del sistema, la cual en este caso se denomina sistema
de charla.
Sistema de charla
Iniciar Sesión de
usuario
Terminar Sesión de
usuario
Usuario
Enviar mensaje
Seleccionar Zona
Seleccionar
Zona
Usuario ausente
F igur a 15 . D iag ra ma de ca so s de u so .
El
diagrama
representa a cada uno de los casos de uso detectados,
mediante su notación en UML. En 4 de ellos, el usuario es quien comienza las
acciones, pero es importante notar que el caso de uso “usuario ausente”, no es
iniciado por el usuario de manera directa, sino que es una caso interno cuya
ejecución esta controlada por el sistema.
4.2.2 Definición de un modelo conceptual
Una vez determinados los casos de uso y el diagrama de casos, se debe
elaborar un modelo conceptual, el cual “explica a sus creadores los conceptos
significativos en un dominio del problema”[LARMAN]. Este modelo conceptual
permite que el esfuerzo por entender el problema se enfoque en los conceptos
propios del dominio y no en entidades del software (funciones, procedimientos,
etc.), además permite ilustrar:
•
conceptos
•
asociaciones entre los conceptos
•
atributos de las conceptos
Larman (1999) plantea que el paso inicial de un análisis o investigación
orientados a objetos es descomponer el problema en conceptos u objetos
individuales, y el problema de estudio será objeto de este proceso. Como primer
paso, se determinan los conceptos que forman parte del modelo conceptual; un
concepto lo podemos definir como un objeto del dominio que se estudia; los cuales
se incluyen en la Figura 16 :
Registro_Usuario
Usuario
Zona
Sistema de Charla
F igur a 16 . D e fin ic ión d e c on ce ptos .
Mensaje
Es posible que algunos de los conceptos no formen parte del diseño final
pero es mejor tener algunos conceptos de más a tener que reincorporarlos en
fases posteriores del diseño debido a que no se detectaron en la fase de análisis.
El siguiente paso para elaborar un modelo conceptual es el de encontrar las
asociaciones existentes entre los conceptos definidos en la sección anterior.
Podemos definir una asociación como “una relación estructural que
describe un conjunto de enlaces, los cuales son conexiones entre objetos”
[BJR99], que interpretado de una forma diferente, significa que una asociación
indica alguna relación significativa entre los objetos o conceptos definidos
anteriormente.
UML establece una notación para las asociaciones, la cual establece que
estarán denotadas por una “línea continua, posiblemente dirigida, que a veces
incluye una etiqueta y a menudo incluye otros adornos, como la multiplicidad”
[BJR99]; y es esta notación la que se aplicará para este caso.
Partiendo de los conceptos obtenidos en la sección anterior se plantean las
siguientes asociaciones entre ellos, contenidos en la Figura 17:
Registro_Usuario
1..*
Genera
Usuario
Zona
Admite_a
1..*
1
1
4
Redacta
1..*
1
Mensaje
Sistema de Charla
Envia
1..*
1
1
F igur a 17 . D e fin ic ión d e a so c ia c io ne s.
En este diagrama, se determinan las asociaciones existentes, así como la
cardinalidad de éstas. De la figura anterior cabe observar algunos detalles
importantes; la flechas no indica necesariamente el sentido de la asociación, sino
que se utilizan para determinar la forma en que se lee la etiqueta de cada
asociación; además la asociación entre el concepto “sistema de charla” y el
concepto “dominio” es de 1 a 4 exactamente, debido a que solo existen 4 dominios
en el sistema de charla planteado para este caso de estudio.
La última etapa para completar el diseño conceptual del sistema de charla,
es agregar a los conceptos, atributos que los describan. Un atributo representa
una propiedad del elemento que se esta modelando (Booch Et-Al 1999). De esta
forma, el definir los atributos de los conceptos, implica analizar las propiedades de
cada uno de ellos e identificar cuales son útiles al objetivo de este estudio. A
continuación, en la Figura 18, se muestran los posibles atributos de cada uno de
los conceptos (cabe señalar, que no es obligatorio que un concepto tenga
atributos):
Registro_Usuario
Alias: Texto
Direccion: Texto
Usuario
Zona
Mensaje
Nombre_Z: Texto
Origen: Direccion
Usuarios_Z: Numero
Destino: Direccion
Zona:Texto
Contenido: Texto
Sistema de Charla
F igur a 18 . D e fin ic ión d e a tr ibu to s.
Explicación de los atributos
Cada uno de los atributos determinados en esta etapa tienen un significado,
y la Tabla 23 lo demuestra.
Atributo
Alias
Dirección
Zona
Nombre_Z
Usuarios_Z
Origen
Destino
Contenido
Descripción
Identificador único que el usuario necesita para ser
referenciado dentro del sistema de charla
Dirección IP, correspondiente a la computadora donde
se encuentra el usuario
Nombre de la zona ala que el usuario ingresa
Cada zona incluida en el sistema de charla debe
contar con un identificador único
Establece el número de usuarios activos dentro de una
zona del sistema de charla.
Este atributo define quien es el usuario que envía un
mensaje
Indica quien el es destinatario de un mensaje
Tiene el cuerpo del mensaje elaborado por un usuario
T ab la 2 3 . Sign ific ad o de lo s a tr ibu to s.
Una vez determinados los atributos de cada concepto, se procede a
elaborar el modelo conceptual, con toda la información recabada: conceptos,
asociaciones y atributos. Una vez integradas éstas partes, el modelo conceptual
toma la forma de la Figura 19:
Registro_Usuario
1..*
Alias: T
exto
Genera
Dirección: Texto
Zona:T
exto
Usuario
Zona
Alias: T
exto
Nombre_Z: T
exto
Dirección: Texto
Admite_a
1..*
Usuarios_Z: Numero
1
1
4
Redacta
Contiene_a
1..*
1
Mensaje
Sistema de Charla
Envia
1
Origen: Direccion
Destino: Direccion
1..*
1
Contenido: Texto
F igur a 19 . D e fin ic ión d e un mod elo c on ce ptua l.
4.2.3 Ampliación del glosario de términos.
Un momento ideal para ampliar el glosario de términos es después de que
se ha elaborado el modelo conceptual, ya que este nos permite conocer y
entender más a fondo el dominio, sus conceptos, su terminología y sus relaciones.
Por lo tanto, en esta etapa se agregarán al glosario de términos todas aquellas
nuevas definiciones, conceptos y relaciones que hallan surgido del modelo
conceptual, así como los casos de uso, todos estos contenidos en la Tabla 23.
Nótese que ahora se denotan los atributos anteponiéndoles el nombre del objeto
al que pertenecen y un punto “.”.
Término
Mensaje
Usuario
Zona
Sistema de charla
Usuario.Alias: Texto
Zona.Nombre_D: Texto
Zona.Usuarios_D:
Número
Mesaje.Origen: Texto
Mensaje.Destino: Texto
Mensaje:Contenido:
Texto
Enviar Mensaje
Iniciar sesión de usuario
Terminar sesión de
usuario
Seleccionar Zona
Usuario ausente
Categoría Comentarios
Tipo
Cadena de caracteres enviadas y
recibidas por los usuarios.
Tipo
Persona que interviene en una charla.
Tipo
Lugar
común
donde
pueden
encontrarse n usuarios charlando.
Tipo
Espacio conceptual, que contiene
dominios y usuarios.
Atributo Nombre con el que un usuario se
identifica en el sistema.
Atributo El nombre que identifica a cada zona.
Atributo El numero total de usuarios activos en
una zona.
Atributo Nombre del usuario que envía un
mensaje.
Atributo Usuario a quien va dirigido un mensaje.
Atributo Cuerpo del mensaje.
Caso de
uso
Caso de
uso
Caso de
uso
Caso de
uso
Caso de
uso
Descripción del proceso de un usuario
que envía un mensaje.
que ingresa al sistema de charla.
que sale del sistema de charla.
que cambia de dominio de charla.
que abandona su sesión.
T ab la 2 4 . Amp lia c ión de l g los ar io de tér mino s .
4.2.4 Diagramas de Clases del diseño.
Los diagramas de clases de diseño tiene como finalidad bosquejar muchas
clases e ilustrar las relaciones que existen entre ellas (Page, 1999). Las clases
están conformadas de atributos y métodos que definen operaciones que cada
clase puede llevar a cabo.
Para elaborar estos diagramas, es necesaria la información resultante del
mapa conceptual y del las tarjetas CRC. Del primero se obtienen las posibles
asociaciones
entre
clases
y
del
segundo
se
obtienen
los
atributos,
responsabilidades y colaboraciones correspondiente a cada posible clase.
De las tarjetas CRC
aplicadas en la fase de análisis se agregan los
atributos a las siguientes clases, ilustrados en la Figura 21:
Registro_Usuario
Usuario
Zona
Mensaje
Alias: Texto
Alias: Texto
Nombre_Z: Texto
Origen: Direccion
Direccion: Texto
Direccion: Texto
Usuarios_Z: Numero
Destino: Direccion
Contenido: Texto
Zona:Texto
Sistema de Charla
NumUsuarios: numero
F igur a 20 . Atr ib utos de la s c la s es .
Cabe recordar que pueden existir clases que no tengan atributos pero que
contengan métodos y viceversa.
El siguiente paso es identificar los métodos. Para esto se puede analizar la
parte denominada “colaboraciones” de cada tarjeta CRC. Nótese que aunque en la
etapa de la aplicación de las tarjetas CRC solo aparecieron 3 es necesario integrar
las “clases sistema de charla” y “usuario”, con la finalidad de darle sentido al
diagrama conceptual. A partir de los mensajes especificados en el diagrama
conceptual y las “colaboraciones” de las tarjetas CRC, se pueden obtener los
métodos que cada clase debe ejecutar. De lo anterior se obtiene el esquema de la
Figura 21:
Registro_Usuario
Usuario
Zona
Mensaje
Alias: Texto
Alias: Texto
Direccion: Texto
Zona:Texto
Nombre_Z: Texto
Origen: Direccion
Direccion: Texto
Usuarios_Z: Numero
Destino: Direccion
AdmitirUsuario()
ExpulsarUsuario()
IncrementaContador()
EnviarMensaje()
CrearRegistro()
ModificarRegistro()
BorrarRegistro()
Contenido: Texto
Sistema de Charla
F igur a 21 .Métod os d e la s c la se s .
Una vez agregados los atributos y los métodos correspondientes a cada
clase, del modelo conceptual se toman las asociaciones para construir el diagrama
de clases. El resultado se ilustra en la siguiente Figura 22:
Zona
Usuario
Nombre_Z: Texto
Usuarios_Z: Numero
Admite_a
Alias: Texto
Direccion: T
exto
1
1..*
AdmitirUsuario()
ExpulsarUsuario()
1
4
Redacta
Contiene_a
1..*
1
Sistema de Charla
Mensaje
EnviarMensaje()
Alias: Texto
Envia
Origen: Direccion
Destino: Direccion
Contenido: T
exto
Registro_Usuario
1..*
1..*
1
1
Direccion: T
exto
Zona:Texto
Genera
IniciarSesion()
T
erminarSesión()
CrearRegistro()
ModificarRegistro()
BorrarRegistro()
F igur a 22 . D iag ra ma de cla se s.
Por último, al diagrama de clases se le pueden agregar los tipos de datos
correspondientes a cada clase y los parámetros que cada método necesita para
su operación. En el caso de que se vaya a generar código a partir de la
especificación del diseño, es muy conveniente incluirlos en el diagrama de clases,
en cambio si el diagrama de clases es creado con la finalidad de que lo lean los
diseñadores de software, el exceso de detalles puede influir negativamente en la
comprensión del diagrama de clases. Aunque el objetivo de este caso de estudio
no es la implementación del diseño, la Figura 23 muestra los tipos de datos de los
atributos y los parámetros necesarios para cada método.
Zona
Usuario
Nombre_Z: Texto
Usuarios_Z: Numero
Alias: Texto
Direccion: T
exto
AdmitirUsuario(Alias:texto)
ExpulsarUsuario(Alias:texto)
1
4
Redacta
Contiene_a
1..*
1
Mensaje
Origen: Direccion
Destino: Direccion
Contenido: T
exto
EnviarMensaje(origen:texto,
destino:texto,contenido:texto)
Registro_Usuario
Sistema de Charla
Envia
1..*
1..*
Genera
1
1
Alias: Texto
Direccion: T
exto
Zona:Texto
CrearRegistro(Alias:texto, Direccion
:texto, Zona:texto)
ModificarRegistro(alias:texto,
zona:texto)
BorrarRegistro (Alias:texto)
F igur a 23 . D iag ra ma de cla se s co n tipo s de d a to s.
De esta forma, queda especificado el diagrama de clases con tipos de
datos, el cual será una herramienta determinante al momento de implementar el
sistema.
Un diagrama de secuencia, muestra las interacciones que acontecen dentro
del sistema y entre los objetos que lo conforman (Arlow, 2002) y se elabora uno
por cada caso de uso detectado en el sistema. Estos diagramas muestran el curso
particular de los casos de uso, los actores externos que interactúan directamente
con el sistema y con los eventos del sistema generados por los actores. Lo que se
pretende es identificar las operaciones que el actor externo pone en marcha, sin
importar como las resuelve el sistema. A continuación se muestran 2 tipos de
diagramas de secuencia para cada caso de uso, el primero de ellos es más
general y el segundo permite llegar un poco mas dentro del diseño.
Diagramas de secuencia correspondientes al caso de uso iniciar sesión.
Iniciar Sesión
Caso de Uso: Iniciar Sesión
1.- Este caso comienza
cuando un usuario quiere
ingresar al sistema de charla.
2.-.El usuario notifica al
sistema que desea iniciar su
sesión por medio de una acción.
3.- El sistema responde
solicitando un nombre y un
zona a los cuales se
d e s e a i n g r e s a r .
4.- El usuario escoge un nombre
y una zona para ingresar en ella.
Usuario
: Sistema
IntroducirAlias(Alias, Zona)
F igur a 24 . D iag ra ma de se cue n cia : in ic iar se s ión ..
El diagrama de la Figura 24, contiene una prosa que lo describe y que es
tomada directamente de los casos de uso. El diagrama de secuencia de la Figura
25 ilustra cuales son las entidades relacionadas con la acción de iniciar sesión.
Iniciar Sesión
Usuario
Pantalla de inicio
Registro_Ususarios
Sistema de charla
Alias
Validar Usuario
Checar detalles
de usuario
Detalles
de usuario
Resultados
F igur a 25 . D iag ra ma de se cue n cia - e ntida de s: in ic ia r s es ión .
Desde la pantalla de inicio el usuario ingresa su alias y su zona para entrar
al sistema de charla. La pantalla de inicio manda el alias al sistema de charla para
que éste valide que el alias no se encuentra repetido, esto lo logra buscando en el
Regitro_usuario. El sistema de charla comunica el resultado en la pantalla de
inicio, aceptando al usuario o pidiéndole que cambie su alias en caso de que este
se encuentre repetido.
De forma análoga, se procede a elaborar los diagramas de secuencia de los
casos de uso restantes.
Diagramas de secuencia correspondientes al caso de uso terminar sesión.
Terminar Sesión
Caso de Uso: Terminar Sesión
1.- Este caso de uso
c o m i e n z a
c u a n d o
el
usuario notifica al sistema
por medio de una acción,
que desea terminar su sesión.
2.- El sistema notifica a los
demás usuarios que un
usuario saldrá y lo elimina
del sistema de charla.
Usuario
: Sistema
TermminarSesión (Alias )
F igur a 26 . D iag ra ma de se cue n cia : te r min ar se s ión.
Terminar Sesión
Usuario
Pantalla de charla
Sistema de charla
Registro_Ususarios
salir
alias
Eliminar usuario
F igur a 27 . D iag ra ma de se cue n cia- e n tida de s : te r min ar se s ión.
En la Figura 27, es evidente que el usuario manda desde la pantalla de
charla la solicitud de abandonar el sistema de charla. La pantalla de charla envía
al sistema de charla el alias del usuario que desea terminar su sesión y se
encarga de eliminarlo del Registro_usuario.
Diagramas de secuencia correspondientes al caso de uso enviar mensaje.
Caso de Uso: Enviar Mensaje
1.- Este caso de uso comienza
cuando un usuario desea enviar
un mensaje. El usuario elabora el
mensaje y elige al usuario al que
va dirigido y mediante una
acción envía el mensaje.
2.- El sistema analiza el “alias”
del usuario destino y le hace
llegar el mensaje.
Enviar Mensaje
Usuario
: Sistema
EnviaMensaje(mensaje,direcciondestino, direccionorigen )
F igur a 28 . D iag ra ma de se cue n cia : Env iar me ns a je .
Enviar mensaje
Usuario
Pantalla de charla
mensaje,destino
Sistema de charla
Registro_Ususarios
Localizar destino
Detalles Destino
Detalles Destino
Entregar mensaje
F igur a 29 . D iag ra ma de se cue n cia- e n tida de s : Env iar me ns a je .
En el diagrama de la Figura 29, el usuario elabora el mensaje y selecciona
un destino contenido en la pantalla de charla. La pantalla de charla pide al sistema
de charla, localizar la dirección del destino seleccionado. El sistema de charla
obtiene la información del Registro_usuario , el cual se la regresa. El sistema de
charla obtiene la dirección destino y entrega el mensaje.
Diagramas de secuencia correspondientes al caso de uso seleccionar zona.
Seleccionar Zona
Caso de Uso: Seleccionar Dominio
Usuario
: Sistema
CambiarDominio (dominio )
F igur a 30 . D iag ra ma de se cue n cia : Se le cc ion ar Zo na .
Seleccionar Zona
Usuario
Pantalla de charla
Sistema de charla
Registro_Ususarios
Solicita cambio
Detalles zonas
Detalles Zonas
Selecciona zona
Zona, Alias
Cambia registro
F igur a 31 . D iag ra ma de se cue n cia- e n tida de s : Se le cc ion ar Zo na .
Para el diagrama contenido en la figura 31, el usuario, desde la pantalla de
charla solicita cambiar de zona, la pantalla de charla solicita al sistema de charla
las zonas disponibles, el sistema regresa la información a la pantalla de charla y
ésta a su vez al usuario, el cual elige una y se lo comunica a la pantalla de charla.
La pantalla de charla le envía el alias del usuario y la nueva zona al sistema de
charla y éste se encarga de ingresar al usuario en la nueva zona, modificando el
Registro_usuario.
Diagramas de secuencia correspondientes al caso de uso usuario ausente.
Usuario Ausente
Caso de Uso: Usuario ausente
Timer
: Sistema
EliminarUsuario(alias)
F igur a 32 . D iag ra ma de se cue n cia : Us ua r io a u sen te .
Usuario Ausente
Timer
Pantalla de charla
Sistema de charla
Registro_Ususarios
Time Out
Alias
Eliminar Registro
F igur a 33 . D iag ra ma de se cue n cia- en tid ad es : Usu ar io au se nte.
El diagrama de secuencia ilustrado en la Figura 33, muestra que el que
inicia las operaciones no es el usuario, sino un objeto interno, en este caso un
Timer, el cual al llegar a su tiempo de expiración, le indica a la pantalla de charla
que el tiempo a expirado, la pantalla de charla envía al sistema de charla el alias
del usuario que ha expirado y procede a eliminar el usuario, borrándolo del
Registro_usuario.
4.2.6 Contratos.
La elaboración de los contratos depende del desarrollo previo del modelo
conceptual y de los diagramas de secuencia del sistema. Los contratos
contribuyen a definir el comportamiento del sistema y dan un panorama de cual es
su estado después de realizar las operaciones. Por cada caso de uso se elabora
un contrato, el cual tiene un formato específico, al que se puede hacer referencia
en el capítulo 3. A continuación se describen los contratos para cada uno de los
cinco casos de uso detectados en este caso de estudio.
Contrato para el caso de uso: Iniciar Sesión
Nombre: IntroducirAlias (Alias,Zona)
Responsabilidad: Ingresar al usuario al sistema de charla.
Tipo: Sistema
Referencias cruzadas: R1.7, R1.6
Excepciones: Si el alias esta repetido, indicar un error.
Poscondiciones:
•
Si se trata de una nueva sesión, se creo una instancia Registro_usuario
(creación de instancia)
•
Se estableció registro.alias con el valor de Alias (modificación de atributo)
•
Se estableció registro.zona con la fecha de zona (modificación de atributo)
•
Se estableció registro.direccion con el valor de la dirección del usuario
(modificación de atributo).
•
Se estableció Zona.Usuarios_Z con una unidad mas que su valor actual
•
Se asoció sistema de charla a registro_usuario (asociación formada).
Contrato para el caso de uso: Terminar Sesión de usuario
Nombre: TerminarSesion (Alias)
Responsabilidad: Sacar al usuario del sistema de charla.
Tipo: Sistema
Referencias cruzadas: 1.8, 2.5
Excepciones:
Poscondiciones:
•
Se estableció Zona.Usuarios_Z con una unidad menos que su valor actual
•
Se elimina la instancia Ingreso_usuario (alias) correspondiente.
Contrato para el caso de uso: Enviar Mensaje
Nombre: EnviaMensaje (mensaje, direccionorigen, direcciondestino, aliasOrigen,
AliasDestino).
Responsabilidad: Entregar un mensaje a su destinatario.
Tipo: Sistema
Referencias cruzadas: 2.2, 2.6
Excepciones:
Poscondiciones:
•
Se creo la instancia Mensaje (creación de instancia).
•
Se creo la instancia Detalle_mensaje (creación de instancia).
•
Se estableció Mensaje.Origen con el valor de DireccionOrigen (modificación
de atributo).
•
Se estableció Mensaje.Destino con el valor de DireccionODestino
•
Se estableció Mensaje.Contenido con el valor de mensaje (modificación de
atributo).
•
Se asoció Usuario a Mensaje (asociación formada).
Contrato para el caso de uso: Seleccionar Zona
Nombre: Seleccionar Zona (Alias, Zona).
Responsabilidad: Cambiar al usuario de una zona del sistema de charla.
Tipo: Sistema
Referencias cruzadas: 1.5
Excepciones:
Poscondiciones:
•
Se estableció Zona.Usuarios_Z con una unidad menos a su valor actual
•
Se estableció la instancia Ingreso_usuario.zona con el nuevo valor de Zona
•
Se asoció Usuario a Zona (asociación formada).
Contrato para el caso de uso: Usuario ausente
Nombre: Usuario ausente (alias).
Responsabilidad: Detectar si un usuario permanece inactivo durante un tiempo
determinado.
Tipo: Sistema
Referencias cruzadas: 1.9
Excepciones:
Poscondiciones:
•
Se eliminó la instancia de registro_usuario correspondiente al valor de alias.
(eliminación de instancia).
•
Se estableció Zona.Usuarios_Z con una unidad menos a su valor actual
V.- CONCLUSIONES
C
CUUAANNDDO
OC
CO
OM
ME
EN
NC
CÉ
ÉA
AE
EL
LA
AB
BO
OR
RA
AR
RÉ
ÉSST
TE
EC
CA
ASSO
OD
DE
EE
ESST
TU
UD
DIIO
OA
APPL
LIIC
CA
AD
DO
OA
AL
L
L
LE
EN
NG
GU
UA
AJJE
E U
UN
NIIFFIIC
CA
AD
DO
O D
DE
E M
MO
OD
DE
EL
LA
AD
DO
O,, M
ME
E PPR
RO
OPPU
USSE
E Q
QU
UE
E É
ÉSST
TE
E T
TR
RA
AB
BA
AJJO
O
FFU
UE
ER
RA
AU
UN
NM
ME
ED
DIIO
OA
AT
TR
RA
AV
VÉ
ÉSS D
DE
EC
CU
UA
AL
LE
EX
XPPR
RE
ESSA
AR
RE
EL
LA
AN
NÁ
ÁL
LIISSIISS Y
YE
EL
LD
DIISSE
EÑ
ÑO
O
B
BA
ASSA
AD
DO
OE
EN
NE
EL
LL
LE
EN
NG
GU
UA
AJJE
EU
UN
NIIFFIIC
CA
AD
DO
OD
DE
EM
MO
OD
DE
EL
LA
AD
DO
O..
U
UNNAA VVEEZZ CCUUBBIIEERRTTAASS
L
LA
ASS E
EX
XPPE
EC
CT
TA
AT
TIIV
VA
ASS PPR
RO
OPPU
UE
ESST
TA
ASS A
AL
L IIN
NIIC
CIIO
OD
DE
EL
LC
CA
ASSO
OD
DE
EE
ESST
TU
UD
DIIO
O,, SSE
E PPU
UE
ED
DE
E
A
AFFIIR
RM
MA
AR
R Q
QU
UE
E E
EL
L L
LE
EN
NG
GU
UA
AJJE
E D
DE
E M
MO
OD
DE
EL
LA
AD
DO
O U
UN
NIIFFIIC
CA
AD
DO
O PPO
OSSIIB
BIIL
LIIT
TA
A A
AL
L
D
DE
ESSA
AR
RR
RO
OL
LL
LA
AD
DO
OR
R PPA
AR
RA
AQ
QU
UE
EM
MO
OD
DE
EL
LE
EU
UN
N SSIISST
TE
EM
MA
AD
DE
E SSO
OFFT
TW
WA
AR
RE
EA
AN
NT
TE
ESS D
DE
E
E
ESSC
CR
RIIB
BIIR
RU
UN
NA
A SSO
OL
LA
AL
LÍÍN
NE
EA
AD
DE
EC
CÓ
ÓD
DIIG
GO
O,, L
LO
OC
CU
UA
AL
LR
RE
EPPR
RE
ESSE
EN
NT
TA
AU
UN
NA
AG
GR
RA
AN
N
V
VE
EN
NT
TA
AJJA
AA
AL
LM
MO
OM
ME
EN
NT
TO
OD
DE
E IIM
MPPL
LE
EM
ME
EN
NT
TA
AR
RD
DE
E IIM
MPPL
LE
EM
ME
EN
NT
TA
AR
RU
UN
N SSIISST
TE
EM
MA
A,, Y
YA
A
Q
QU
UE
EE
ESS B
BIIE
EN
N SSA
AB
BIID
DO
O Q
QU
UE
E E
EN
NT
TR
RE
EM
ME
EN
NO
OR
R T
TIIE
EM
MPPO
O A
AB
BA
AR
RQ
QU
UE
EL
LA
A FFA
ASSE
E D
DE
E
A
AN
NÁ
ÁL
LIISSIISS Y
Y D
DIISSE
EÑ
ÑO
O,, M
MA
AY
YO
OR
R SSE
ER
RÁ
Á L
LA
A C
CA
AN
NT
TIID
DA
AD
D D
DE
E PPR
RO
OB
BL
LE
EM
MA
ASS Y
Y
SSIIT
TU
UA
AC
CIIO
ON
NE
ESS
R
RIIE
ESSG
GO
OSSA
ASS
Q
QU
UE
E
IIM
MPPL
LE
EM
ME
EN
NT
TA
AC
CIIÓ
ÓN
ND
DE
EU
UN
N SSIISST
TE
EM
MA
A..
SSU
UR
RJJA
AN
N
D
DU
UR
RA
AN
NT
TE
E
L
LA
A
FFA
ASSE
E
D
DE
E
E
ESS IINNDDUUDDAABBLLEE Q
QU
UE
EE
EL
LA
APPL
LIIC
CA
AR
RE
ESST
TE
E
T
TIIPPO
OD
DE
ED
DIISSE
EÑ
ÑO
O,, C
CO
OM
MB
BIIN
NA
AD
DO
OC
CO
ON
NU
UN
NL
LE
EN
NG
GU
UA
AJJE
EE
ESSPPE
EC
CIIA
AL
LIIZ
ZA
AD
DO
O PPE
ER
RM
MIIT
TE
EN
N
A
AL
LA
AN
NA
AL
LIISST
TA
A,, A
AL
LD
DIISSE
EÑ
ÑA
AD
DO
OR
R,, A
AL
L PPR
RO
OG
GR
RA
AM
MA
AD
DO
OR
R,, A
AL
LU
USSU
UA
AR
RIIO
O FFIIN
NA
AL
LY
YA
A
T
TO
OD
DA
ASS L
LA
ASS PPE
ER
RSSO
ON
NA
ASS IIN
NV
VO
OL
LU
UC
CR
RA
AD
DA
ASS E
EN
N U
UN
N PPR
RO
OY
YE
EC
CT
TO
O D
DE
E SSO
OFFT
TW
WA
AR
RE
E;;
T
TE
EN
NE
ER
R U
UN
N N
NIIV
VE
EL
L D
DE
E C
CO
OM
MU
UN
NIIC
CA
AC
CIIÓ
ÓN
N U
UN
NIIFFIIC
CA
AD
DO
O..
E
ESS
PPA
AL
LPPA
AB
BL
LE
E Q
QU
UE
E E
EL
L
L
LE
EN
NG
GU
UA
AJJE
EU
UN
NIIFFIIC
CA
AD
DO
O D
DE
E M
MO
OD
DE
EL
LA
AD
DO
O FFA
AC
CIIL
LIIT
TÓ
Ó M
MU
UC
CH
HO
O L
LA
ASS T
TA
AR
RE
EA
ASS D
DE
E
A
AN
NÁ
ÁL
LIISSIISS Y
YD
DIISSE
EÑ
ÑO
OD
DE
EE
ESST
TE
EC
CA
ASSO
OD
DE
EE
ESST
TU
UD
DIIO
O,, Y
YQ
QU
UE
E SSU
U A
APPL
LIIC
CA
AC
CIIÓ
ÓN
NA
A
SSIISST
TE
EM
MA
ASS C
CO
ON
NG
GR
RA
AN
ND
DE
ESS C
CA
AN
NT
TIID
DA
AD
DE
ESS D
DE
E SSO
OFFT
TW
WA
AR
RE
EY
Y G
GR
RU
UPPO
OSS D
DE
ET
TR
RA
AB
BA
AJJO
O
E
ESS FFA
AC
CT
TIIB
BL
LE
EY
YR
RE
EC
CO
OM
ME
EN
ND
DA
AB
BL
LE
E..
E
ELL LLEENNG
GU
UA
AJJE
EU
UN
NIIFFIIC
CA
AD
DO
O
D
DE
EM
MO
OD
DE
EL
LA
AD
DO
O
PPE
ER
RM
MIIT
TE
EQ
QU
UE
EL
LO
OSS D
DE
ESSA
AR
RR
RO
OL
LL
LA
AD
DO
OR
RE
ESS IIN
NC
CU
UR
RSSIIO
ON
NE
EN
NE
EN
NE
EL
L PPA
AR
RA
AD
DIIG
GM
MA
AD
DE
EL
L
D
DIISSE
EÑ
ÑO
OO
OR
RIIE
EN
NT
TA
AD
DO
OA
AO
OB
BJJE
ET
TO
OSS PPE
ER
RO
OA
AN
NIIV
VE
EL
LD
DE
EA
AN
NÁ
ÁL
LIISSIISS Y
YD
DIISSE
EÑ
ÑO
O,, Y
YN
NO
O
N
NIIV
VE
EL
LD
DE
E IIM
MPPL
LE
EM
ME
EN
NT
TA
AC
CIIÓ
ÓN
N.. E
ESSTTO
OE
ESS M
MU
UY
Y IIM
MPPO
OR
RT
TA
AN
NT
TE
ED
DE
EB
BIID
DO
OA
AQ
QU
UE
E PPO
OR
R
L
LO
OR
RE
EG
GU
UL
LA
AR
R,, PPA
AR
RA
AE
EL
LN
NIIV
VE
EL
LD
DE
EA
AN
NÁ
ÁL
LIISSIISS Y
YD
DIISSE
EÑ
ÑO
O SSE
EA
APPL
LIIC
CA
AE
EL
LE
EN
NFFO
OQ
QU
UE
E
E
ESST
TR
RU
UC
CT
TU
UR
RA
AD
DO
OY
Y PPA
AR
RA
AL
LA
A IIM
MPPL
LE
EM
ME
EN
NT
TA
AC
CIIÓ
ÓN
NE
EL
LE
EN
NFFO
OQ
QU
UE
EO
OR
RIIE
EN
NT
TA
AD
DO
OA
A
O
OB
BJJE
ET
TO
OSS,, L
LO
OC
CU
UA
AL
LR
RE
ESSU
UL
LT
TA
AE
EN
NU
UN
NA
AT
TA
AR
RE
EA
AN
NO
OD
DE
EL
LT
TO
OD
DO
OG
GR
RA
AT
TA
AC
CU
UA
AN
ND
DO
O SSE
E
H
HA
AB
BL
LA
AD
DE
E SSIISST
TE
EM
MA
ASS C
CO
ON
N G
GR
RA
AN
N C
CA
AN
NT
TIID
DA
AD
DD
DE
E SSO
OFFT
TW
WA
AR
RE
E..
E
ESS DDEEFFIINNIITTIIVVO
O
Q
QU
UE
EA
AD
DO
OPPT
TA
AR
RL
LA
A PPO
OSST
TU
UR
RA
AO
OR
RIIE
EN
NT
TA
AD
DA
AA
A O
OB
BJJE
ET
TO
OSS D
DE
ESSD
DE
EL
LO
OSS PPR
RIIM
ME
ER
RO
OSS
N
NIIV
VE
EL
LE
ESS C
CO
ON
NL
LL
LE
EV
VA
AA
AL
LD
DE
ESSA
AR
RR
RO
OL
LL
LO
OD
DE
EU
UN
N SSO
OFFT
TW
WA
AR
RE
EC
CO
ON
NM
ME
EJJO
OR
RC
CA
AL
LIID
DA
AD
D
Y
YQ
QU
UE
E FFA
AC
CIIL
LIIT
TA
AL
LA
AE
EV
VO
OL
LU
UC
CIIÓ
ÓN
ND
DE
EL
L SSIISST
TE
EM
MA
AA
AT
TR
RA
AV
VÉ
ÉSS D
DE
EL
LT
TIIE
EM
MPPO
OL
LO
OC
CU
UA
AL
L
L
LE
E PPE
ER
RM
MIIT
TIIR
RÁ
ÁT
TR
RA
ASSC
CE
EN
ND
DE
ER
R,, C
CO
OSSA
AQ
QU
UE
EN
NO
O SSU
UC
CE
ED
DE
EM
MU
UY
YR
RE
EG
GU
UL
LA
AR
RM
ME
EN
NT
TE
E
C
CO
ON
NE
EL
LE
EN
NFFO
OQ
QU
UE
EE
ESST
TR
RU
UC
CT
TU
UR
RA
AD
DO
O..
E
ELL TTEEM
MA
A PPR
RIIN
NC
CIIPPA
AL
LD
DE
EE
ESST
TA
AD
DE
ET
TE
ESSIISS E
ESS E
EL
LL
LE
EN
NG
GU
UA
AJJE
EU
UN
NIIFFIIC
CA
AD
DO
OD
DE
E
M
MO
OD
DE
EL
LA
AD
DO
OY
Y PPU
UE
ED
DE
EA
AFFIIR
RM
MA
AR
RSSE
EQ
QU
UE
E SSU
UA
APPL
LIIC
CA
AC
CIIÓ
ÓN
NA
AL
LC
CA
ASSO
OD
DE
EE
ESST
TU
UD
DIIO
O
PPA
AR
RT
TIIC
CU
UL
LA
AR
R FFU
UE
E SSA
AT
TIISSFFA
AC
CT
TO
OR
RIIA
A,, Y
YA
A Q
QU
UE
E SSE
E PPR
RO
OPPO
OR
RC
CIIO
ON
NA
AR
RO
ON
N L
LO
OSS
A
AR
RT
TE
EFFA
AC
CT
TO
OSS N
NE
EC
CE
ESSA
AR
RIIO
OSS PPA
AR
RA
A L
LA
A FFA
ASSE
E D
DE
E A
AN
NÁ
ÁL
LIISSIISS Y
Y D
DIISSE
EÑ
ÑO
O..
L
LO
OSS
O
OB
BJJE
ET
TIIV
VO
OSS D
DE
EL
LA
AT
TE
ESSIISS SSE
EC
CU
UM
MPPL
LIIE
ER
RO
ON
N,, Y
YA
AQ
QU
UE
E SSE
EL
LO
OG
GR
RÓ
ÓE
ESSPPE
EC
CIIFFIIC
CA
AR
RE
EL
L
D
DIISSE
EÑ
ÑO
OD
DE
EU
UN
NC
CA
ASSO
OD
DE
EE
ESST
TU
UD
DIIO
O,, A
APPE
EG
GÁ
ÁN
ND
DO
OSSE
EÉ
ÉSST
TE
E,, A
AL
LA
AN
NO
OT
TA
AC
CIIÓ
ÓN
ND
DE
EL
L
L
LE
EN
NG
GU
UA
AJJE
EU
UN
NIIFFIIC
CA
AD
DO
OD
DE
EM
MO
OD
DE
EL
LA
AD
DO
O .. L
LO
OSS T
TE
EM
MA
ASS C
CO
ON
NT
TE
EM
MPPL
LA
AD
DO
OSS D
DE
EN
NT
TR
RO
O
D
DE
EL
LM
MA
AR
RC
CO
OT
TE
EÓ
ÓR
RIIC
CO
O FFU
UE
ER
RO
ON
NA
AN
NA
AL
LIIZ
ZA
AD
DO
OSS Y
YA
APPL
LIIC
CA
AD
DO
OSS,, Y
Y PPE
ER
RM
MIIT
TIIE
ER
RO
ON
N
L
LL
LE
EG
GA
AR
RA
AU
UN
NA
AE
ESSPPE
EC
CIIFFIIC
CA
AC
CIIÓ
ÓN
ND
DE
ED
DIISSE
EÑ
ÑO
OD
DE
EFFIIN
NIIT
TIIV
VA
A,, L
LA
AC
CU
UA
AL
LC
CO
ON
NSST
TA
AD
DE
E
D
DIIA
AG
GR
RA
AM
MA
ASS D
DE
E SSE
EC
CU
UE
EN
NC
CIIA
A,, C
CO
ON
NT
TR
RA
AT
TO
OSS,, C
CA
ASSO
OSS D
DE
EU
USSO
O,,
D
DIIA
AG
GR
RA
AM
MA
ASS D
DE
E
C
CL
LA
ASSE
ESS Y
Y M
MO
OD
DE
EL
LO
OSS C
CO
ON
NC
CE
EPPT
TU
UA
AL
LE
ESS,, L
LO
OSS C
CU
UA
AL
LE
ESS E
EN
N SSU
U C
CO
ON
NJJU
UN
NT
TO
O
R
RE
EPPR
RE
ESSE
EN
NT
TA
AN
N L
LO
OSS PPL
LA
AN
NO
OSS Q
QU
UE
E E
ESSC
CE
EN
NIIFFIIC
CA
AN
N L
LA
A C
CO
ON
NSST
TR
RU
UC
CC
CIIÓ
ÓN
N D
DE
EL
L
SSO
OFFT
TW
WA
AR
RE
E..
Como experiencia particular, el incursionar en este tipo de trabajos ha
proporcionado al autor, una grata y rica experiencia de aprendizaje,
que le
permite analizar y darse cuenta de las diferentes formas que hay para resolver un
problema, en cuanto a diseño de software se refiere, y que el aplicar una nueva
estrategia y lograr los objetivos planteados puede resultar muy reconfortante.
Esto, tomando en cuenta que siempre debe apostarse por las nuevas tecnologías
que proporcionan herramientas más eficaces y especializadas para el desarrollo
de una tarea en particular.
Es definitivo que el modelado orientado a objetos es una realidad y que las
tendencias se inclinan cada vez más por lenguajes de diseño orientados a objetos
como el U.M.L., dejando de lado el enfoque algorítmico que por mucho tiempo ha
prevalecido y prevalece aún en nuestros días, haciendo del diseño de software
una tarea cada vez más complicada, debido a que el software, se vuelve cada
más extenso y complejo.
BIBLIOGRAFÍA
Arlow Jim, Neustadt Ila. Uml and the unified process: Practical Objetc-Oriented
Analysis and Design. Ed. Addison Wesley Professional. 1st edition. January 16,
2002. 416 pp.
Booch, G. Objetc-Oriented analysis and design. Ed. Benjamin/Cummnis. EUA.
1994.
Booch G., Rumbaugh J. Jacobson I. El lenguaje de modelado unificado. Ed.
Addison Wesley Iberoamericana, Madrid, 1999. 464 pp.
Clarence
Lee,
Rachel
Reuben,
Mike
Siekkinen,
http://www.terra.com.ve/informatica/que-es/irc.cfm. Terra
y
Lee
Smallbone.
Networks S.A. 1999.
Fecha de visita: Mayo 2002.
Crag
System
(1998).
http://rgai.i.inf.u-zeged.hu/~beszedes/munka/rose/UML
Tutorial.. Fecha de visita: Mayo 2002.
Elizalde
Vieyra
Guadalupe
(2000).
El
modelo
cliente
servidor:
http://www.fismat.umich.mx/~elizalde/tesis/node19.html
Flower Martín. UML gota a gota. Ed. Addison Wesley Longman de México, S.A. de
C.V. México, 1999. 203 pp.
Irc Hispano. http://www.irc-hispano.org/ayuda/quees.html. 2002. Fecha de visita:
Mayo 2002.
Jacobson, I. Object-Oriented Software Engineering: A use case driven approach.
Ed Addison Wesley, 1992.
Larman Graig. UML y Patrones Introducción al análisis y diseño orientado a
objetos. Ed. Prentice may, México, 1999. 536 pp.
Maldonado Villaverde Carlos. Manual de curso UML. Grupo Softpack.
México.1999
Meilir Page-Jones. Fundamentals of Object-Oriented Design in UML. Ed. AddisonWesley Pub Co. 1st edition October 29, 1999. 458 pp.
Muñoz Razo Carlos. Cómo elaborar y asesorar una investigación de tesis. Ed.
Prentice Hall. México 1998. 300 pp.
Salkind Neil J. Métodos de Investigación. Ed. Prentice Hall. México 1999. 400 pp.
ANEXO 1
Formato de la entrevista aplicada.
1.- ¿Cuál es su nombre?
2.- ¿Cuál es su profesión?
3.- ¿En donde trabaja actualmente?
4.- ¿Cuál es su puesto?
5.- ¿Ha trabajado alguna vez con el diseño orientado a objetos?
6.- ¿Cuantos años lleva trabajando en el diseño de software?
7.- ¿Cuál es su experiencia en el ramo del diseño orientado a objetos?
8.- ¿Ha elaborado productos de software que se comercialicen?
9.- ¿En cuáles de ellos el diseño ha sido orientado a objetos?
10.- ¿Qué lenguajes utiliza para diseñar y porque?
11.- ¿Cuál es su opinión respecto al diseño orientado a objetos?

Tesis - Dirección General de Servicios Telemáticos

Transcription

Similar documents

Modelado de Sistemas Embebidos

SesiÃ³n 1 - Apuntes - Muerte por PowerPoint

Metodología

l Antecedentes l Motivación l Objetivos l Metodología l El modelo en

T E S I S

Mecanismo de transformación de diagramas UML de casos de uso

resume

Descarregar versió en PDF