Document

Sistema Automatizado de Información para
las Oficinas de la Coordinación Divisional de
Docencia y Atención a Alumnos de CBI para
el Area de Posgrado.
(Modulo: Oficinade Gestión Escolar para Posgrado),
Realizado por: Jorge Alejandro Morales Orea
Reporte Final del Proyecto de Investigación
Asesor: Omar Lucio.Cabrera Jiménez
1 . Introducclon...........................................................................................
1 . l . Objetivos del proyecto.......................................................................
1.2. Metodología orientada a objetos ...........................................................
3
3
3
2 . UML-Lenguaje de ModeladoUnificado ....................................................
2.1. Descripción del UML.........................................................................
2.2. Historia del UML..............................................................................
2.3. Utilización del UML............................................................................
2.4. Tendencias del UML..........................................................................
5
5
6
6
7
3 . Programación Orientada a Objetos .........................................................
3.1. Un ejemplo de un lenguaje Orientado a Objetos......................................
3.2. Conceptos de la P O 0........................................................................
3.2.1. Propiedades, eventos y métodos.................................................
3.2.2. Objetos del mundo que nos rodea y del mundo informático..............
3.3. Características de la PO0..................................................................
3.3.1 Herencia.................................................................................
3.3.2 Polimorfismo...........................................................................
3.3.3 Encapsulación.........................................................................
3.3.3.1 Control del Acceso a métodos y propiedades......................
3.3.3.2 Acceso a propiedades y métodos desde el propio objeto. . . . . . .
3.4 Un ejemplo de como se traduce UML a un lenguaje Orientado a Objetos ......
7
7
8
10
10
11
11
13
14
14
15
15
4 . Análisis y Diseño Orientadoa Objetos......................................................
4.1 Modelo de Requerimientos...................................................................
4.1. IModelo de Casos ........................................................................
4.1.2 Modelo de lnterfaz ......................................................................
4.1.3 Modelo del Dominio del Problema..................................................
4.1.3.A Definición de clases y objetos............................................
4.1.3.B Determinación de objetos.................................................
4.1.3.C Atributos .......................................................................
4.1.3.D Diagramas de Clases.......................................................
4.2 Modelo de Análisis Dinámico .................................................................
4.2.1 Tipos de Objetos: Visuales 'y no Visuales ..........................................
4.2.2 Modelo de Tres Capas..................................................................
4.2.3 Análisis mediante escenarios.........................................................
4.2.4 Diagrama de Colaboración............................................................
4.2.5 Modelo de Clases Dinámicas.........................................................
4.3 Modelo de Construcción .......................................................................
4.3.1 Modelo de Diseño .......................................................................
4.3.1.A Diagrama de Secuencia.....................................................
4.3.1. B Criterios de Calidad para el Diseño......................................
4.3.2 Modelo de Componentes.............................................................
4.3.3 Modelo de Implementación..........................................................
18
21
21
24
26
27
27
30
32
45
45
46
46
48
52
54
54
54
56
58
59
. I
Universidad Autónoma MetroDolitana lztapalapa
5. Arquitectura del Desarrollo ......................................................................
5.1 Desarrollo de Prototipos.......................................................................
5.2Tres Características Importantes del Enfoque Iterativo..........................................
5.3 BeneficiosResultantes ...................................................................................
5.4 Actividades Detalladas del Ciclo Iterativo............................................................
5.5 SeleccionandoIteraciones ...............................................................................
5.6 No Existe una Solución Mágica ........................................................................
68
68
69
69
70
71
71
6 . Aplicaciones en Internet .........................................................................
72
7 . DBSP (Data Base Scripting Pages) ..............................................................
7.1 ISAPl (Internet Server Applicatiort Program Interface .................................
7.2Comofunciona DBSP? .......................................................................
73
74
75
8. JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1 Características de JavaScript .....................................................................
77
78
9 . Programación Orientada a Páginas WEB...................................................
9.1 Modelo de objetos del documento ..........................................................
9.2 Eventos esenciales de una Página WEB ..................................................
80
80
81
10. Modelado de una aplicación WEB usando DBSP....................................
10.1 Ejemplo de Implementación de una aplicación usando DBSP....................
83
83
11. Conclusiones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
116
12. Referencia Bibliográfica ........................................................................
117
.
13. Desarrollo Práctico (Anexo)
1.I.Objetivos del Proyecto
Los propósitos de este proyecto son:
O
O
O
O
0
Demostrar el desarrollo de software, usando el Análisis y Diseño Orientado a Objetos.
Hacer una descripción detallada decómo implementar un sistema con DBSP (Data
Base Scripting Pages) una tecnología basada en ISAPls, basándonos de un ADOO.
Explicar cuales son las diferencias para implementar entre un lenguaje en el que su
estructura de codificación se base en ADOO, como por ejemplo JAVA y DBSP.
Modelado de la aplicación para aplicarla dentro de una Intranet, así como también
para aplicarla sobre Internet.
Referencia para los estudiantes de Computación que desean aprender como aplicar
los conceptos teóricos a una aplicación real.
El proyecto se realizó en dos partes. En la primera se trabajo con los requerimientos
iniciales y se obtuvo un primer prototipo funcional del sistema. La segunda parte se
trabajo la depuración y adiciones a los requerimientos iniciales, así como nuevos
requerimientos, se obtuvo el siguiente prototipo más completo en cuanto a funcionalidad y
diseño visual.
En la primer apartado de este trabajo se explicarán los conceptos y el tipo de notación
que se utiliza para el modelado Orientado a Objetos. En el Anexo se describe es el
desarrollo practico del sistema de la Oficina de Docencia y Atención a Alumnos de
Posgrado de CBI.
Con respecto a la utilización de DBSP, vamos a mostrar que es muy rapido implementar
una aplicación orientada a Web, a diferencia de otras tecnologías utilizadas para este fin,
como la se Servlets de Java y CGI.
1.2 Metodología orientada a objetos.
La metodología orientada a objetos, es un nuevo paradigma que a demostrado buenos
resultados en el desarrollo de sistemas.
La mayor parte del software que se pro'duce en la actualidad no cumple con los requisitos
que espera el usuario final. No ofrecen una solución efectiva al problema por el que se
concibió principalmente el sistema, apenas, resuelve algunos aspectos de la
problemática. Sin embargo, se tienen que aceptar los costos no porque sean bajos, sino
porque, el tiempo invertido y la necesidad de la organización por el sistema no le dejan
más opción. Pero el mayor costo no es el desarrollo del sistema sino su mantenimiento, el
cual resulta el doble del costo de su construcción. En muchos casos, no solo es el doble,
sino que puede llegar a números mayores.
Para disminuir el costo de los sistemas se utiliza la reutilización de componentes.
Ubicando a los componentes como algo que esta bien construido y los cuales solo tienen
que incorporarse en los sistemas sin hacer una modificación a su interior.
...............................,...
~
~~~:.~;~:~.~...:..:.:..:.x::..::...i
:~~~~
.~.:.:.
....:.:.:<.:.:.:.:~~.:.:.:
........... .~<.~.....
..M.:.:.:.:<.
..,.<.:.:.:.:.t:
i.:.:.:.:.:.:.:.:~~.~
:.:.:.:.:.x<.: .,.,..<..,.+
, ........
.
A
...A,.,
Universidad Autónoma MetroDolitana IztaDalaDa
La definición del enfoque Orientado a IObjetosse basa en la idea de componentes. Los
sistemas construidos bajo este enfoque son más flexibles, con gran reutilización de partes
de sistemas. La comunidad del desarrollo de sistemas actualmente tiende al modelo con
Orientación a Objetos en respuesta a minimizar los costos de desarrollo y sobre todo los
costos de mantenimiento.
La razón por la quetodoestosurgióesque
la programación estructurada, éI último
paradigma, no satisfacía las necesidades de los programadores. La programación
estructurada recomendaba utilizar tantos procedimientos y funciones diferentes como
fuera necesario para dividir todas las tareas en sus funciones. Si cada función, era limpia,
no afectaba nada más, y se limpiaba después por sí misma, ¿qué podía estar mal?
Se suponía que la clave era el establecimiento de estándares de programación: numero
la
máximo de líneas decódigoqueun
procedimiento puede tener, los anchosde
tabulación estándar, nomenclaturas de ,funcionesy variables, y casi todos los aspectos del
estilo de programación a fin de poner en vigor la modularidad. Se suponía que se debía
crear un código con funcionalidad genérica que haría del mantenimiento del programa una
tarea fácil.
Se oía bien pero resulta que la programación modular estructurada era una teoría que no
efectuó la transición a la practica. El c6digo nunca puede ser lo suficientemente genérico
para emplearlo en todas partes. Hay una compensación constante ya sea que "clonemos
o modifiquemos" para cadasituación
ligeramente distinta o, si en realidad somos
dogmáticos, utilizamos una instrucción CASE para cadavariable,que
con el tiempo
produce el código, el cual es mucho m i s difícil de mantener que su idea original, simple y
elegante. Y si se descubrió un defecto fundamental en el código original o se necesita
hacer un cambio que afecte todos los casos, tenemos que hacer el seguimiento de todos
los clones y hacerles los mismos cambios a todos.
Los costosde mantenimiento de los sistemashechosconel
enfoque estructurado son
demasiado altos. Cada vezquehay
luna modificaciónalsistema,
la estructura básica
sufre un proceso de degeneración, hasta llegar a un punto que se complica tanto el flujo
de ejecución que el mantenimiento inyecta erroresque no existían antes. El disefio
Orientado a Objetos es la solución. Pone en practica la modularidad y reduce los gastos
generales de administración de códigos'.
En la actualidad la comunidad de desarrolladores con Orientación a Objetos sé
esta moviendo a UML para efectos de notación. UML permite incorporar todos los
conceptos planteados en las metodologías más importantes de desarrollo con Orientación
a Objetos, tales como Diagramas de Casos, Diagramas de Clases, Diagramas de
estados, Diagramas de Componentes, etc.
UML es una herramienta notational, que apoya los procesos de Análisis,
Construcción y Pruebas. Por lo mismo es conveniente incorporar herramientas CASE que
permitan utilizar notación UML como Rational Rose, para apoyar tales procesos.
Pero qué es UML, cuál es historia, sus conceptos y hacia donde va:
2.1 Descripción del UML
0
0
0
UML se entiende como Lenguaje de Modelado
Unificado (Unified Modeling Language por sus
siglas en inglés)
El UML combina lo mejor de
m
Conceptos de Modelado de Datos
(Diagramas E-R)
Modelado de Negocio (work flow)
Modelado de Objetos y de Componentes
El UML es el lenguaje estándar para la
visualización, especificación, construcción y
documentación de elementos de un sistema
intensivo en software.
Puede utilizarse con todo proceso a lo largo del
ciclo de vida del desarrollo y con diferentes
tecnologias de implantación.
m
Universidad Autónoma Metropolitana lztapalapa
.....................
. .................
. . . . ....
.......
....
......
.......
.....
......
.........
......
.....
.(..
..........
.......
...............
....
,,.:. :,,.
.,.::""
ff,terfhz de
Usu.&jo ,,,,:::::.~..."~""~.~'
"'"..'....
.....
'...
.....
..:....
....
.....
.....
.....
...
....
....
.....
....
....
....
...
....
(vls;ual
Basic
,
'
.......
'
:
:
:
.
:
$
Y
......
...
...
........
Java)
,,,:::f"$
....,
.:..
.....
....
...
..::::..
.:gógica deNegoci'fs
...
...
......
...
':$,: (C++, Java)
':$. . .
....
......
...
...
....
..........
....
....
....
....
.....
......
...
....
...
...
.....
.....
...
....
....
.:..
.
...
...
...
...
..
....
....
...
.A,..
...
..:.::..
.....
:::.:...
...
:.x
BD .:..
(C:++ 8 SQL) ...2;:
..
Servidorde
.......
....
...
Figura 2: UML define la Arquitectura del Software
Desarrollado en 1995 por
los tres metodistas de
Orientación a Objetos más
importantes:
0
Grady Booch
James Rumbaugh
0
Ivan Jacobson
En 1997 es aceptado por la
OMG (Object Managment
Group) como estándar.
Esto atrajo a miembros
importantes del software
como Microsoft, HP, IBM,
Oracle, etc.
0
El UML puede utilizarse para:
Mostrar los límites del sistema y sus principales funciones utilizando
Casos y Actores
Ilustrar las realizaciones de los Casos con diagramas de interacción
-
-
Representar una estructura estática del sistema utilizando los diagramas
de clases
Describir la implantación física de la arquitectura con diagramas de
componentes y distribución física.
Extender la funcionalidnd con estereotipos
2.4. Tendencias de UML
Se espera que en un futuro próximo UMLsea la única descripción de modelos con
Orientación a Objetos. Y sea establecido como el estándar en la industria.
En la actualidad varias herramientas de desarrollo como JBuilder 4, JCreator, Delphi,
utilizan la notación planteada por UML para efectos de identificación de componentes de
código.
Programación Orientada a Objetos. ¿Clue es eso de objetos? Y qué es lo debemos variar
respecto a nuestra programación estructurada tradicional, y además por qué hemos de
hacerlo. Estas son preguntas comunes que nos hemos hecho todos al empezar con un
lenguaje orientado a objetos. Vamos a intentar desvelar los misterios que esconde y a
convencernos de su validez y utilidad y, sobre todo, que no es tan complejo como parece
indicamos la teoría.
Evidentemente, Java no es el primer lenguaje orientado a objetos. Aunque da la impresión
de que esto es un invento de hace poco, la historia se remonta bastante atrás,
concretamente a 1967 y a un lenguaje llamado Simula, luego llegaron otros como el
Smallfalk, Flavors, Loops y por fin, el mas utilizado modernamente, el C y posteriormente
el C++ ya en plena década de los ochenta.
Java ..., pero, ¿qué es Java?
Java es un Lenguaje de Programación Orientado a Objetos ideado por
Sun Microsystem. Tiene muchas cosas que lo hacen parecerse a C++
pero es mucho más seguro y sobre todo mucho más fácil de leer. Es un
lenguaje de propósito general por lo que se podría crear cualquier tipo de
aplicación con éI, pero su mayor éxito se produce en Internet, con los
famosos Applets, las aplicaciones Chente/Servidor o las tan demoda
"Java Server Pages".
d y,:
:.y
:. $ '..
&.p.
I
+C-.
..:
. _ xt
JAVA
¿Por qué está de moda Java?
Habrás oído que con el lenguaje de programación Java, puedes "escribir
una vez, ejecutar en cualquier parte". Esto significa que cuando se
compila un programa, no se generan instrucciones para una plataforma
específica. En su lugar, se generan bytecodes Java, que son
instrucciones para la Máquina Virtual nJava(Java VM). Si tu plataformasea Windows, UNIX, MacOS o un navegador de internet-- tiene la Java
VM, podrá entender los bytecodes.
Figura 2.1 Un programa Java es independiente del Sistema Operativo
Por esta razón utilizamos Java en la construcción del sistema, así no tendremos que
preocuparnos por la plataforma en donde se instalara la aplicación.
La PO0 surge como una evolución natural de la programación estructurada. No es algo
que rompa esquemas clásicos como podría suponerse. La P O 0 formaliza técnicas
utilizadas en dicha programación estructurada. Esta es la mejor manera de comprender
enun primer momento su misión. Ahora bien, su definición es algo más obtusa y
filosófica, yaque académicamente podemosdecirque
la PO0 aplica los objetos del
mundo real a nuestras aplicaciones. De ahí el concepto de orientación a objetos, nuestras
aplicaciones las van a conformar entidades llamadas objetos.
Un objeto es algo tangible que tiene
características y un comportamiento. En el mundo
real podemos hablar del objeto silla, automáticamente construimos en nuestro cerebro un
determinado tipo desilla, pero en cualquiera de los casos lo hacemos siempre con las
características con las que nuestra percepción reconoce al objeto silla. Tendrá un
respaldo, un asiento, un soporte, un color, etc. Ese concepto de silla es lo que llamamos
clase. Una clase es una abstracción de un objeto, es algo intangible, es el conjunto de
ideas, no es algo real. A la acción de crear un objeto partiendo de una clase se le llama
instanciamiento.
Ya tenemos dos conceptos que en la PO0 van a ser fundamentales, las clases y los
objetos. Nosotros pasaremos gran partle del tiempo dedicándolo a diseñar clases, a crear
abstracciones que sean inherentes a muchos objetos, o mirándolo desde el punto de vista
informático, al código que utilicemos repetidamente en muchos módulos. He aquí una de
las claves de la PO0 reutilizar el código.
La forma en la representaremos gráficamente una clase será con la notación deUML:
Lenguaje Unificado de Modelado. En la actualidad esel modelo de notación quetiene
mayor aceptación dentro de la comunidad de desarrolladores con Orientación a Objetos.
Para aprender más acerca de esta notación puedes consultar las Notas deAnálisis y
Diseño Orientado a Objetos de Luis Fernando Castro Careaga.
Figura :2.2 Una clase en UML
Muchas veces hablaremos de
clases
y de objetos indistintamente, no hay que
confundirlos, pero tampoco hay que cclnsiderarlos como algo distinto. Nosotros podemos
manipular las clases y los objetos, mientras que el usuario sólo puede actuar sobre los
objetos. En nuestras aplicaciones, por tanto, siempre debemos convertir,esdecir,
instanciar las clases en objetos. Generalmente, se utiliza la palabra reservada new para
crear una instancia de una claseen la mayoría de los lenguajes de programación
orientada a objetos.
Volviendo al ejemplo de la silla, si a la abstracción, esto es, a la clase silla, le damos unas
características especificas como pueden ser: tapicería decuero,color
negro, soporte
giratorio y con ruedas, respaldo doble de alto, tendríamos en la mente el nombre silla de
ejecutivo. Es realmente un objeto, pero un objeto que tiene unas características tan
definidas y que se repiten en muchos objetos silla, que podemos considerar a este tipo
como una clasede silla. Ahora bien, al partir del concepto genérico desilla,estaremos
hablando de una subclase. Por tanto, de una clase genérica o mejor llamada clase base,
podemos crear subclases y éstas a su vez tener más subclases, así formaremos una
jerarquía de clases.
3.2.1 Propiedades, eventos y métodos
Hasta ahora hemos hablado de características de los objetos. Bien, en la terminología de
la POO, a estas se les llama propiedades. Por tanto, todos los objetos tienen unas
propiedades que los distinguen de otros. Del mismo modo, el mundo real es algo
dinámico y, por tanto, las cosas, esto es, los objetos, están expuestos a acciones externas
y, a pesar de ser inanimados, pueden cambiar su estado dependiendo de esas acciones.
Por ejemplo, si nos recostamos sobre el respaldo flexible de una silla, este se echará
hacia atrás. Se ha producido una acción, recostarse, y una reacción, echarse hacia atrás
el respaldo.
En la POO, a las acciones les llamaremos eventos y a las reacciones métodos. Si esto lo
aplicamos a la programación, los eventos serán acciones del usuario sobre nuestra
aplicación y los métodos serán código asociado a cada evento. Ahora bien, también
pueden existir métodos que no respondan a eventos, aunque esto no es del todo preciso,
ya que si responden a una acción, que es la nosotros realizamos programáticamente al
llamar dicho método. Bien, entonces ya tenemos los elementos con los que vamos a jugar
en la POO: las clases, los objetos, las propiedades, los eventos y los métodos. Esto es lo
que debemos saber y dominar, ni más ni menos.
I
NombreClase
I
-
Propiedad1 : tipo
Propiedad2 : tipo
!
$Metodo0
%€:vent00
Figura 2.3 Propiedades, Métodos y Eventos en UML
3.2.2 Objetos del mundo que nos rodea y del mundo informático
Llegado a este punto, es fácil que el ‘lector encuentre todo esto como un desvarío que
poco o nada tiene que ver con la programación y sí mucho con filosofía barata. Pero
hagamos ahora una traslación de lo dicho a nuestro mundo.
Parece que nos tenemos que dedicar a convertir nuestros programas en poco menos que
una colección de objetos tales como mesas, coches, arboles, etc. Realmente la P O 0 sí
que dice que esto sea así, un ejemplo menos estereotipado seria el objeto articulo, o el
objeto cliente, ambos son entidades que tienen unas propiedades y se realizan acciones
con ellos. Ahora bien, tan cierto es que éstos son objetos, como que también nuestro
mundo, el informático, tiene objetos. ¿,O no lo son, las ventanas, los botones, las listas
desplegables ...?
Todos ellos son elementos que tambikn tienen unas características propias y actúan de
diversa forma respecto a los eventos realizados por nuestro opuesto, que no es otro que
el usuario final. Por tanto, tal vez sea más fácil, asimilar la P O 0 pensando en objetos de
nuestro entorno de programación, de la interfaz, etc. que en algo tan vastocomo el
entorno vital. Nuestra mente cuadriculada lo agradecerá.
Los componentes están vistos, pero que más nos ofrece la PO0 para que sea más útil.
Bien veamos tres fundamentales.
3.3.1 Herencia
Una de las principales ventajas de la F'OO. La herencia se produce al crear subclases u
objetos. Consiste en que éstos tienen las propiedades y métodos que hayamos definido
en la clase base, por lo que no tendremos que repetirlos. Aquí aparece una de las
razones, la reutilización del código. Nosotros, en la programación estructurada, utilizamos
el famoso método de copiar y pegar todo lo que nos sirve de otro programa que
tuviéramos hecho.
En la POO, hay poner ese código que nos vale en una clase y, sólo con esto, todas las
subclases y objetos que creemos partiendo de esa clase tendrán, sin hacer nada, ese
código sin tener por tanto que reescriibirlo. Además, cuantas veces hemos tenido que
retocar un código por un pequeño errsr de sintaxis cuando ya lo habíamos "pegado" en
varios módulos y, por tanto, deberemos modificar en cada uno de ellos. O ese color de
ventana que no le gusta al usuario y que hemos empleado en las cuarenta y siete que
tiene la aplicación, por lo que ahora tenemos que modificarlas una a una.
tendremos que hacerlo, puesto que la herencia funciona
Gracias a la PO0 yano
automáticamente, por lo que iremos a la clase base y modificaremos esa propiedad o ese
método que estaba mal y listo, el cambio se reflejará en todas las subclases y objetos que
se crearon a partir de dicha clase. Sólo por esto, merece la pena programar con
orientación a objetos.
Claro, que muchas veces va a suceder que una determinada propiedad o método no nos
sirve. Esto tampoco representa un problema, ya que no estamos obligados a tener que
heredarlo, sino que podemos sobreescribir el método o la propiedad en cuestión.
Directamente sucederá cuando escribamos en la propiedad o en el método. También
podemos utilizar el código heredado y sumarle el propio que nos interese. En fin,
disponemos de todas las posibilidades.
Por último, podemos impedir que una propiedad o método heredado pueda ser modificado
en algún sitio que no sea la clase base, esto es lo que se denomina proteger la propiedad
o método.
En la notación de UML la relación de herencia entre dos clases se indica por medio de
una flecha hueca que apunta a la clase ascendiente. En general, se utiliza la palabra
reservada extends en la clase hija, para indicar que se hereda la funcionalidad de la clase
padre.
Clasepadre
t
Figura 2.4 Herencia en UML
Ejemplo
Un buen ejemplo en donde se puede aplicar la herencia es en los autos, existen dos tipos
estándar y automático. Vemos que los dos tipos de autos tienen cuatro ruedas, motor,
compartimento para pasajeros, volante, etc. sólo difieren en ciertos aspectos. De la misma
forma ambos tienen funciones similares de encendido, apagado, avance, retroceso, etc. A
continuación se muestra esta situación en la figura.
Ij
~
-
Autómovil
$gMa rca
$gModelo
$pií0
&Placas
$gDueiio
'@Apagado()
'bAvance()
'@Retroceso()
'@Vuelta()
@Velocidades
1
%CambioVelocidad()
2"""
1
%ktivaSobreMarcha()
~
Figura 2.5 La clase Automóvil tiene las subclases Estándar y Automático
Las subclases Estándar y Automático heredan las propiedades Marca, Modelo, Año,
Placas y Dueño de la clase Automóvil, así como las funciones. Cada subclase agrega su
propia funcionalidad para el tipo de transmisión.
Universidad Autónoma MetroDolitana IztaDalaDa
3.3.2 Polimorfismo
También es una característica propia de la PO0 y consiste en que varios objetos, aunque
partan de distintas clases, tengan métodos o propiedades con elmismo nombre y que
actúen de distinta forma. Tiene una relación directa con la herencia, ya que un método o
propiedad heredado se puede sobreescribir y por tanto puede actuar de distinta forma de
lo que lo hacia en la clase base.
Ejemplo
Quien no ha jugado o visto alguna vez un videojuego, donde los personajes son dibujados
en la pantalla de diferentes formas conforme va avanzando el juego. Es claro que si cada
se dibujara de acuerdo a sus
personaje es un obieto,
- . y- éstossondistintos,cadauno
propiedades. Si nosotros quisiéramos hacer ¡a función de dibujó del personaje por el
método estructurado, el código tendría la siguiente forma:
I(
Function
dibuja
(Personaje)
P
switch(P.Tipo) (
case T1: dibuja-personaje1 ( ) ;
case T2: dibuja-personaj
(e2
) ;
I
...
1
)
De la forma tradicional se tiene que por cada personaje hay un case y una función de
dibujo asociados. Ahora, desde el punto de vista del objeto que está ordenando que se
dibuje el personaje, no importara si es un personaje u otro, sólo ordena que se dibuje el
personaje que está solicitando. Si utilizamos Polimorfismo quedaría de la siguiente forma:
dibuja
(Personaje
P)
P.Dibuja();
Debido a que cada personaje tiene una función de dibujo, ésta es llamada sin importar a
que tipo de personaje pertenece, cada función de dibujo es implementada de acuerdo a
las características del personaje.
De esta forma vemos que la función de dibujo puede tomar varias formas, de acuerdo a
personaje pasado como parámetro. Es más fácil de entender y mantener el código en la
versión con Polimorfismo, por decir, si se desea agregar mas personajes al videojuego la
función de dibujo no sufrirá ningún cambio, al contrario de la versión sin Polimorfismo en
la que agregaríamos un case por cada nuevo personaje.
3.3.3 Encapsulación
Siguiendo con la dinámica de actuación de la POO, al crear clases lo que estamos
haciendo implícitamente es agrupar propiedades y métodos para que, cuando tengamos
que hacer otra aplicación, cojamos esa clase y la pongamos en ella sin tener que cambiar
nada. A esto se le llama encapsulación.
En la programación estructurada teníarnos código desperdigado en módulos, programas,
etc., y en la PO0 todo lo guardamos en el mismo sitio, en la clase u objeto, lo
encapsulamos. Si queremos utilizar una propiedad o método debemos llamar al objeto en
cuestión mediante mensajes. Lo podríamos asociar con las clásicas llamadas a funciones
o procedimientos almacenados en prgs, archivos h, o unit, por ejemplo.
Una propiedad o atributo puede ser accesible desde otros objetos; sin embargo, depende
de la visibilidad del mismo. Puede ser de alguno de estos tipos:
3.3.3.1 Control del Accesoa metodos y propiedades
Visibilidad Oculta o Privada
Las propiedades y métodos definidos como privados sólo son accesibles y visibles desde
la propia clase donde se definen. En cluanto a las propiedades, cualquier método inscrito
en la clase puede modificar el contenido de estas propiedades privadas; sin embargo, a
efectos de su visibilidad son invisibles desde cualquier otro objeto. Por tanto, se recurre
muchas veces a la utilización de un método visible para recoger el valor de una propiedad
privada y visualizarlo desde el exterior. En General se antepone la palabra reservada
private al nombre del método o propiedad.
Visibilidad Protegida
Se establece este tipo de visibiliclad para que propiedades y funciones sean
referenciables por código de funciones; de subclases dentro de la jerarquía de herencia.
En General se utiliza la palabra reservada protected.
Visibilidad Pública
Un método o propiedad con acceso publico tiene la visibilidad más amplia posible.
Cualquier objeto puede verlo y cualquiera puede utilizarlo. En General se utiliza la palabra
reservada public.
Visibilidad Amigo
Se utiliza el nivel amigo cuando se desea que sólo algunos objetos puedan tener acceso a
las propiedades y métodos definidos en la clase. En algunos lenguajes se tiene la noción
de visibilidad amigo de modo que solamente las funciones que están dentro de un
archivo fuente dado puedan verlas. En General esta noción es remplazada por la idea
más explícita de paquetes, los cuales pueden agrupar clases.
La encapsulación, por tanto, ayuda tarnbién a la reutilización del código y a hacer más
fácil su búsqueda en nuestras aplicaciones.
3.3.3.2 Acceso a propiedades y métodos desde el propio objeto
Para referenciar un objeto o método definido en una clase desde la propia clase se utiliza
el operador this, y su función es la de acceder al propio objeto. Se antepone this y punto
antes de la propiedad o método al que se desea acceder, esto se aplica con frecuencia
cuando se programan JavaScripts dentro del código de HTML, cuando se manejan
formularios especialmente.
Daremos un ejemplo ficticio de cómo traducir UML, utilizando Java. Supongamos que nos
piden llevar el registro del mobiliario de una oficina. El mobiliario se compone de sillas,
escritorios, mesas, sillones, equipo de computo, y artículos de oficina. Cada uno ellos son
objetos de la vida real, y de acuerdo a lo que nos dice la P O 0 también serán objetos de
nuestra aplicación.
Si recordamos en nuestro ejemplo de la silla anteriormente planteado, ésta presentó las
siguientes características: un respaldo, un asiento, un soporte, un color, etc.
publicclass
UML
Silla
(
Silla
(from Loqlcal Mew)
@respaldo : String
'&asiento : String
@soporte : String
&color: String
Java
// D e f i n i c i ó n de
String
String
String
String
protected
pro'tected
pro'tected
protected
...
// Método
l a s características
respaldo;
asiento;
soporte;
color;
constructor
puhlic Silla ( )
Dentro de la oficina también se encuentran las sillas ejecutivas. Un objeto Silla Ejecutiva
será una subclase del objeto Silla.
UML
P u b l i c class
SlllaEjecutiva extends Silla
(
// D e f i n i c i ó n de l a s c a r a c t e r l s t i c a s
private String marca;
private String
...
Silla
tapiceria;
// Método c o n s t r u c t o r
public SillaEjecutiva( )
Java
.
(
@asiento : String
@soporte :String
Q c o l o r : String
// Asignamos l a s c a r a c t e r í s t i c a s
tapiceria = "cuero";
color = "negro";
soporte = "giratorio y con ruedas";
respaldo = "doble alto";
...
/ / Método para asignarla marca
public voidsetMarca(String marca)
(
SillaEjecutim
this.marca
=
marca;
I
@marca : String
&tapiceria : String
"
"
~
...
I
.".
"
-
%etMarca(marca : Stnng)
"
"
."
A la hora del diseño de clases también tenemos que tener en cuenta que una clase puede
contener a otros objetos, son las llamadas clases contenedoras, que no debemos
confundir con las subclases, que nos abrirán más posibilidades.
La clase Oficina contiene diferentes tipos de objetos como sillas normales o ejecutivas,
escritorios, y todo objeto que sea parte del mobiliario.
Public
UML
t
Oficina
(from Logical View)
@SillaGerente : SillaEjecutiva
tZ$SillaCapturista : Silla
Escritoriol : Escritorio
Java
classOficina
// D e f i n i c i ó n de l a s propiedades
private SillaEjecutiva SillaGerente;
private silla Sillacapturista;
private Escritorio Escritoriol;
...
// Método c o n s t r u c t o r
public Oficina ( )
(
1
// Método paracrear
los mueblesde
la
// o f i c i n a
public voidcrearMobiliario0
I
// Instanciamos l a c l a s e s i l l a
SillaGerente = new SillaEjecutiva();
SillaGerente.
setMarca
("Bellini");
Sillacapturista = new Silla ( ) ;
Escritoriol = new Escritorio();
I
..
...
1
Universidad Autónoma Metropolitana IztaDalaDa
De esta forma cuando la aplicación haga una instancia de la clase oficina, podrá llamar a
su método crearMobiliario() para crear cada objeto de la oficina. Tal vez se quiera hacer
referencia a un objeto contenido en la clase oficina, para ello simplemente se creara un
método publico que devuelva una referencia a ese objeto.
La forma en que se paso de la notación de UML a Java, es solo una forma de hacerlo y
no es la única, mi intención es dar una idea de cómo convertir los diagramas de clase en
código, no intento decir que así se tenga que construir la aplicación. Es trabajo del lector
buscar la mejor forma de traducir la nlotación de UML a código. Si se cuenta con una
herramienta CASE como Rational Rose 2000, se puede crear código automáticamente
tanto para Java, Visual Basic, C++ y Or'acle8 a partir de los diagramas de clases.
Tradicionalmente, la creación de una aplicación siempre ha pasado por las fases de
análisis, diseño, programación, pruebas y documentación. Sin embargo, todos sabemos
que las dos primeras se acortaban hasta hacerse, en algunos casos, inexistentes.
Siempre tenemos que hacer las cosas para pasado mañana, con lo que el sacrificado
suele ser normalmente el análisis. Y no solo me refiero a pequeñas corporaciones en las
que el programador es a la vez analista, probador, documentador y, si me apuras,
instalador e instructor; me refiero también a equipos en programación que obvian en
demasía la importancia de la primera fase de una aplicación. El hecho de tener un gran
bagaje profesional, hace que se tomen a la ligera aspectos tal vez importantes en la
aplicación.
Bien, en la programación tradicional, puede, hasta cierto punto, consentirse todo esto y
podemos lanzarnos a programar con cuatro ideas y realizar las correcciones oportunas
"sobre la marcha". Siempre, por supuesto, obligados por la inmediatez de implantación de
la nueva aplicación. Cuando hablamos en programación orientada a objeto, el análisis y el
diseño cobran relevancia trascendental y por tanto constituyen una fase inexcusable en el
desarrollo de la aplicación.
Hay que tener muy clara la idea de que un buen análisis puede acortar considerablemente
la fase programática, por ello, no se deben escatimar horas en organizar y estructurar la
aplicación en cuestión. Vamos a ver en los párrafos siguientes en qué medida cambia el
análisis y diseño orientado a objeto respecto del tradicional. Primeramente, desglosemos
las diferentes partes en las que se divide cada uno de ellos:
Modelo de Casos
0
Modelo de lnterfaz
0
Modelo de Dominio del Problema
Modelo de Análisis
0
Definición de Escenarios
0
Modelo de Clases Dinámicas
0
Diagramas de Colaboración
Modelo de Diseño
0
Diagramas de Secuencia
0
Modelo de Componentes
Modelo de lmplementación
0
Construcción de Bases de Datos
Modelo de Pruebas
0
0
0
0
0
Análisis Funcional
Análisis de Datos
Análisis de las Reglas de Negocio
Modelo de Implantación
Diseño de la Aplicación
0
0
Esquema de Bases de Datos
Interface del Usuario
Pruebas
Vamos a utilizar una aplicación ficticia para comprobar los pasos que deberemos seguir.
ÉSta será una sencilla aplicación de inscripción a cursos para una universidad. Muchas de
las fases serán conocidas por cualquier analista, otras las obviaré, ya que no es mi
cometido hacer un completo curso del análisis, sino presentar las principales
características del ADOO. Para un cornpleto curso de ADOO recomiendo las Notas de
Análisis y Diseño Orientado a Objetos: Aplicado a Sistemas deInformación, de Luis
Fernando Castro Careaga.
La descripción de la aplicación se muestra a continuación:
O
La UAMl desea sistematizar su sistema de registro de Inscripción a Cursos
El coordinador define los cursos a impartir en un trimestre
-
-
Un curso puede tener varios grupos en los que se ofrece
Los estudiantes seleccionan cursos obligatorios y optativos sin exceder el
numero máximo de créditos permitidos en su carrera
Una vez que un estudiante se inscribe en un trimestre, se notifica al
sistema de pagos tal que el estudiante pueda cobrársele por el trimestre
Los estudiantes pueden utilizar el sistema para agregar o eliminar cursos
por un periodo de tiempo después de la inscripción.
Los profesores utilizan el sistema para recibir sus listas de grupo
A los usuarios del sistema de inscripción se les asignan contraseñas que
utilizan en la validación al entrar al sistema
Análisis de la Aplicación
AI llegar a nuestras manos la aplicación, debemos tomar los datos básicos que nos
puedan dar una idea del mismo.
Objetivo: Registrar a los alumnos en lcls cursos abiertos por los coordinadores y enviar la
información a los profesores y al sistema de pago.
Usuario: Los usuarios serán los alumnos, profesores, coordinadores y la gente
encargada del sistema de pago. Su experiencia en el manejo de programas informáticos
es nula.
Hardware y Software: Programa hecho con cualquier lenguaje de programación
orientado a objetos, ejecutado en una maquina Pentium Ill a 500 Mhz sobre Windows
2000.
Primera Impresión: Parece un prograrna sencillo en su dinámica, pero difícil en cuanto a
que debe de ser muy intuitivo para el usuario.
Primer Paso: Hablar con las personas interesadas en implantar el sistema, por lo regular
serán personas que ocupan altos puestos directivos. En esta primera cita se deben de
establecer las funciones y los limites del sistema, así como identificar a los usuarios clave
que harán uso intensivo del sistema. Se tendrán que realizar reuniones posteriores pero
con los usuarios clave, para obtener toda la información posible sobre las transacciones
que realizan para el proceso de inscripción.
Hagamos un pequeño esquema de lo que seria el proceso de mecanización, conseguido
a través del tradicional análisis funcional, luego lo compararemos con el análisis orientado
a objetos.
Análisis Funcional
Una de las técnicas utilizadas normalmente para el análisis funcional es el descrito por
Allan Albrecht en 1979, que busca y especifica las distintas funciones del trabajo del
usuario final. Según esto, podemos desglosar en nuestro ejemplo los siguientes puntos:
1.
2.
3.
4.
El coordinador abre los grupos
El alumno se inscribe
El profesor recibe la lista de sus alumnos
El Sistema de Pagos cobra a los alumnos inscritos
Estas serian las 4 funciones que atañen al objetivo del programa. Veamos ahora cómo
debemos matizarlas para un Análisis Orientado a Objetos.
Análisis y Diseño Orientado a Objetos (ADOO)
El desarrollo con enfoque Orientado a Objeto requiere de una metodología cuyos
objetivos, sean incorporar de una manera fácil la funcionalidad de las necesidades de los
usuarios, generar descripciones del sistema que lo integren y que sean compatibles ante
los cambios.
La metodología más destacada en la actualidad es la Ingeniería de Software Orientada a
Objetos (IS00 por sus siglas en ingles) descrita por Jacobson. Esta metodología
incorpora el levantamiento de requerimientos como su actividad principal.
Sus procesos se centran en la elaboración de modelos de/ sistema. Cada modelo es una
descripción de aspectos relevantes del sistema en distintos momentos del desarrollo.
Los procesos que integran a la I S 0 0 se muestran en la siguiente Figura: .
/
I
Figura 4.l:Proceso de Ingeniería de Software Orientada a Objetos.
A
....,.........
Los óvalos en la figura se refieren a los procesos, los rectángulos se refieren a los
distintos modelos que se generan. Se observa que el Modelo de Análisis también sirve
como entrada para el Proceso de Pruebas, debido a que describe los casos de prueba
más relevantes. En realidad los modelos de la IS00 están compuestos por dos o más
modelos detallados como se muestra a continuación.
El Modelo Análisis se compone a su vez de dos modelos:
0
Modelo de Requerimientos
0
Modelo de Análisis Dinámico
El Modelo de Construcción esta constituido por tres modelos más elementales:
0
Modelo de Diseño
0
Modelo de Componentes
0
Modelo de Implantación
Los modelos se explicarán con mayor profundidad en los siguientes capítulos. Para
efectos de incorporar los conceptos del ADOO, los modelos se describen a través de la
notación planteada por UML.
El objetivo principal de este modelo es acelerar el conocimiento que se extrae de los
usuarios clave, de tal forma que el equipo de desarrollo pueda llegar más rápido a la
solución del problema. A la vez que establecen los requerimientos básicos del sistema.
El modelo de Requerimientos se constituye a su vez de tres modelos:
0
Modelo de Casos
0
Modelo de lnterfaz
0
Modelo del Dominio del Problema
Enel Modelo de Casos se establecen las principales transacciones que contendrá el
sistema. Siendo una transacción cualquier interacción que el sistema tendrá con los
agentes externos a él.
Actores
0
.,,,,,, ,.fl,$gg..;: ..,.,.,.
.~
,.,., .,.,.,,.
: ..........,.....,
~ . .........,
~ :
... .. "....,........*........,. .'."
~~~~~~~~
Universidad Autónoma Metropolitana IztaDalaDa
Un actor es alguien o algo que debe interactuar con el sistema que se está
desarrollando.
En la siguiente Figura, se muestran 10s'actores que utilizarán el sistema.
P r o f Pago
ewr
Coordinador
de Sistema
Alumno
Figura 4.2: Actores involucrados en el sistema
Use Cases
0
0
Un Caso es un patrón de comportamiento que exhibe el sistema
Cada caso es una secuencia de transacciones relacionadas que son
efectuadas por un actor y el sistema dentro de un diálogo
Se analizan los actores para determinar sus necesidades
Coordinador -- mantiene los cursos y grupos
Profesor -- solicita una lista
Estudiante -- mantiene un horario
Sistema de Pagos -- recibe la información de cobro del proceso de
inscripción
La siguiente Figura se muestran las transacciones más importantes del sistema.
Mantenimiento
de
Cursos
Solicita
Lista
de
Curso
Mantenimiento
de Horario
Figura 4.3: Uses Cases del Sistema
Documentación de los Casos
A continuación en la descripción de cada Caso se planteará paso a paso en qué consiste
la transacción. La descripción del Caso debe de ser simple y puede contemplar algunas
verificaciones, sin embargo, omite cualquier aspecto de decisión o de manejo de errores.
Siempre se asumirá que el Caso es para las situaciones más comunes de la transacción.
Se construye un flujo de eventos para cada Caso
Se escribe desde el punto de vista del actor
Detalla lo que el sistema debe proporcionarle al actor cuando el Caso sea ejecutado
Por lo regular contiene
- Cómo inicia y termina el Caso
El flujo normal de eventos
El flujo alterno de eventos
El flujo excepcional de eventos
m
Universidad Autónoma Metropolitana lztapalapa
De nuestro ejemplo seleccionemoselCasode
siguiente descripción:
Mantenimiento de Homrio que tiene la
Diagrama de Casos
0
Los diagramas de Casos presentan una vista externa del sistema. Se crean para
visualizar las relaciones entre Actores y Casos
Los actores y sus relaciones con los casos se muestra en la Siguiente Figura:
í
'
"
"
"....
Aumno
Profesor
I
.......... /'
Solicita Lista de Curso
"""
"
'.
de
(
'
.,
1
"".."~.
->\"
..
l
Mantenimiento de Cursos
Sistema
Figura 4.4: Diagrama de Casos
Relaciones de Uses y Extends en los Casos
Conforme los Casos son documentados , se pueden descubrir relaciones con otros
Casos
Una relación de
Uses
(utilización) indica un comportamiento que es
común a uno o más Casos
-
Una relación de Extend (extensión) indica un comportamiento opcional
Las relaciones que se encontraron entre casos se muestran en la Siguiente Figura:
/'
"-..
i
~ " Y "
I
Validación de Acceso
\\~"/
Mantenimiento de Cursos
Figura 4.5:Casos que utilizan otro Caso para realizar su actividad
El Modelo de interfaz consta principalmente de la definición de las interfaces principales
que participaran en la ejecución de cada Caso cuando el sistema exista. Las interfaces
son las pantallas, reportes o llamadas a otros sistemas, perose aplica más a las
pantallas.
Diseño de lnterfaz de Usuario
Cuando enfocamos cualquier aplicación hecha en un entorno gráfico como Delphi, Visual
Basic, Power Builder, Java, debemos tener presente como punto de referencia la interfaz
de usuario que manejará los datos. El punto de vista del usuario es lo fundamental. Por
tanto, cualquier suposición pasará siempre el tamiz de la opinión del mismo. Ahora bien,
no debemos caer tampoco en una dependencia absoluta e intentaremos reconducir al
usuario por donde más nos interese. Els tarea del analista educar la usuario e informarle
en un lenguaje sencillo de las posibilidades y limitaciones del sistema a implantar.
El 60% o el 70% del tiempo queempleamos
en eldiseñode
una aplicación lo
centraremos en la interfaz de usuario, y es que realmente la parte que ve el usuario es tal
vez una de las cosas más importantes en un entorno visual.
En la Siguiente Figura, podemos observar una pantalla para registrar un curso.
Figura 4.6: Pantalla de Registro a Cursos
En esta pantalla se le puede explicar al usuario que tendrá que seleccionar de una lista un
curso disponible, el cual puede tener varios grupos. A continuación seleccionaría de una
lista el grupo al que quiere asistir. En la parte inferior de la pantalla se visualiza el horario,
el profesor y el salón asignado al grupo
Cuando se tienen varias pantallas involucradas, no sólo será necesario mostrar las más
importantes, sino además, señalar la forma en que se estarán activando dependiendo de
la interacción que tenga el usuario con el sistema. Para poder plasmar este tipo de
conocimiento, utilizamos los diagrama:; de Transición de Estados, en los se muestra el
estado de un objeto y sus cambios de estado a través de una transición.
Diagrama de Transición de Estados
0
0
Un diagrama de estados muestra
La historia deuna clase dada
Los eventos que provocan una transición de un estado a otro
Las acciones que resuitan de un cambio de estado
Los diagramas de transición de estados son creados para objetos con un
comportamiento dinámico significativo
Cada estado dentro de estos diagramas denota una pantalla en la que el usuario estará
introduciendo datos o bien navegando en la información. En la siguiente Figura, se
presenta el diagrama de Transición de Estados para el caso de registro a cursos.
.
Agregar Curso y
Continuar Registrando
[cuenta c Cred. Max]
1"(
Login y
Password
Registrar Cursos /
1
1'"""(
asignar cuenta= O
Principal
Fin del Programa
\
n
1
[cuenta <= Cred. Max ]
Figura 4.7: Navegación de pantallas en el Modelo de Casos
En este diagrama se tiene un estado inicial (circulo negro) que es donde parte la
ejecución del programa, se necesitara (le un Login y Password para acceder al sistema y
poder llegar a un estado o pantalla (rectángulo con leyenda) en la que el usuario puede
plantear acciones a realizar. En es c.aso,las acciones a que tiene acceso son dos:
Registrar Cursos o Finalizar el Programa. En caso que decida Registrar Cursos, cambia a
una pantalla en donde podrá ver la información de un curso y seleccionarlo. En esa
pantalla podrá agregar el Curso seleccionado a la Base de Datos y continuar registrando
otros Cursos sin excederse del número de créditos máximo permitido, o bien regresar a
la pantalla principal. Unavez que ha registrado todos sus cursos se muestra en una
pantalla su horario correspondiente y puede regresar a la pantalla principal. Cuando en la
pantalla principal se decide terminar el programa se selecciona la opción Fin del
Programa y se llega al estado final (círculo negro con marco).
El Modelo del Dominio del Problema tiene como objetivo principal identificar los objetos de
información y las relaciones que guardan entre sí. Lo anterior se plasma en un Diagrama
de Clases. Para cada Caso del Modelo de Casos, se obtiene un Diagrama de Clases, de
tal forma que éste contendrá los objetos que necesite para desarrollarse.
Para acometer la resolución del problema, se divide el análisis en una serie de fases.
Veamos cuáles son:
.,.. .......~
...~
.....,.... ,.....,..:.,.
:.:...~,:~,:...:<~.:.:.~~
.~.~~~~~~~
......<......., ,. c.:<... ....
~~~~~~~~~~~
Universidad Autónoma Metropolitana lztapalapa
"
Atributos
Definir estructura
Servicios
Temas
entidades reales en clases y objetos
Se han de definir atributos o propiedades
para definir un objeto. Los atributos son
datos almacenados en un objeto.
En esta fase se declaran las relaciones
existentes entre todas las entidades
Se definen como servicios aquellos
procesos que ha derealizar un objeto.
Esta fase agrupa varias entidades por algún
criterio temático
4.1.3.a Definición de clases y objetos
En esta fase se tratan de identificar los elementos de la realidad que se van a convertir en
definiciones de clases. Una clase no es más que una abstracción de un objeto, o lo que
es lo mismo, las características comunes a un grupo de objetos. Discernir qué conjunto de
objetos son susceptibles de crear una abstracción, o sea, una clase, será la labor del
analista. Posteriormente, estas definiciones se utilizarán para crear objetos dentro de la
aplicación.
. .
.,:. .,
.
: 4.,1.3,.bDeterminacibn -de:objetos
Como su propio nombre indica lo que nos importa en este análisis es discernir cuáles van
a ser los objetos que van a formar parte de la aplicación. Tal vez ésta es la tarea más
complicada del analista. En un primer momento, no debemos intentar enfocar con
rigurosidad los objetos que nos puedan hacer falta en nuestra aplicación. Lo que haremos
será un brain storming (tormenta de ideas) que depuraremos con posterioridad.
Una forma fácil de localizar objetos es encontrar en la aplicación:
0
0
0
0
0
Cosas
Lugares
Personas o funciones
Eventos
Conceptos
Organizaciones
Según esto, en nuestro ejemplo podemos conseguir los siguientes objetos:
Cosas "b Lista de Alumnos, Horario
Lugares -b Grupo
Conceptos ---+ Curso, Inscripción, Trimestre
Personas
Alumno, Profesor, Coordinador, Sistema de Pago
+
Podríamos, por tanto, a partir de aquí, crear unas clases candidatas, es decir, que
posiblemente serán las clases utilizadas en la aplicación. Cuando definimos las clases
.......,<...,......,.,.,...,,.......c.
....A,
......... .........,.,.,.......
..,..
,,
~~~~~~
.
Universidad Autónoma Metropolitana IztaDalaDa
:
.
:
~
,
~~~~~~~~
tenemos que indicar también cuales van a ser sus métodos y sus propiedades, así como
los términos específicos de la programación Orientada a Objeto. Para aquellosque no
están acostumbrados a esta terminologia, lo podemos comparar con los procedimientos y
variables que debe contener un módulo, donde podemos tomarnos la licencia de igualar
clase con módulo, procedimiento con método y variable con propiedad, con
las
salvedades de comparar estostérminossin
estar en mi ánimo el decir quesean
equivalentes.
El siguiente esquema podría ser válido para la definición de clases:
~....:......:..:...:..:.:.:.:....,...
i..:..i.:.........
.....:.:.:.(.
:.....(....
: .: ..: ,~,...,
:~,
.......
, :.:.:...:........
, , .
,
:
..............................................................,.,.
................
...........................
.. ... ..... ........ ,.... .....,.
,, ,, ,
~.....................
~ :
1 . . 1 .
....
:
.....
.., ;._.
: . . . . ..:. .....................:.................................................:.....................,.,..........,.....~
: ~ F ~
,
.....................................................,..,.,.
................../.
,. , , . ,... ...:......, ..,................. ............
,
, ,,
,,, , ,,,, ,,,, ,,, ,,,, , ,,,,
Nombre
Matricula
Carrera
CrearAlumno
RegistrarCurso
SolicitarHorario
Profesor
Nombre
No. de empleado
Area de investigación
Crearprofesor
SolicitarLista
ComprobarHorario
Coordinador
Nombre
No. de empleado
Area de investigacih
Carrera
Materia (UEA*)
Grupo
Trimestre Lectivo
No. de Alumnos
Profesor
CveGrupo
Salón
Horario
CrearCoordinador
AbrirCurso
EliminarCurso
...
...
Curso
Grupo
...
Crearcurso
ComprobarExisteMateria
CogerTrimestreActual
CogerProfesor.
...
CrearGrupo
CrearHorario
RegistrarSalon
...
Inscripción
Alumno
Calificación
Curso
Materia (UEA*)
Trimestre Lectivo
Crearlnscripcion
RegistrarAlumno
RegistrarCurso
RegistrarCalificacion
...
* Unidad de Enseñanza-Aprendizaje
Comprobamos que no todas las clases previamente encontradas se convierten en clases
reales. Por ejemplo, comprobamos que el Trimestre es una característica del Curso y que
en esta aplicación importa poco quien es el Sistema de Pago, ya que sólo se le notifica
que el Alumno esta inscrito y puedecobrarle por el trimestre. El Horario y la Lista de
Alumnos las proporcionara el sistema una vez realizada la inscripción.
El desglose que se hizo anteriormente muestra los objetos de la aplicación en general, sin
embargo, como el sistema cuenta con másde una transacción es necesario ser más
preciso en cuanto a la definición de los objetos que participan en cada una de ellas. Ya
quese parte del Caso, se tomará la descripción textual del Caso y se identificaran los
candidatos a objetos. La forma en que identificaremos a nuestros candidatos es mediante
~
~
~
~
los sustantivos de las oraciones, también es posible identificarlos con los verbos que
actúan sobre los sustantivos. A continuación se muestra el Caso de Mantenimiento de
Horan'o mostrando los candidatos a objetos marcados en negritas y los verbos marcados
con itálicas.
1
2
3
4
5
6
7
8
9
10
El Alumno da su número de matricula.
El sistema muestra los Cursos a los que se puede inscribir de acuerdo a su
Carrera.
El Alumno selecciona el Curso al que se desea inscribir.
El Alumno selecciona un Grupo correspondiente al Curso elegido.
El Alumno verifica el Horario, el Profesor y el Salón del Grupo
seleccionado.
El Alumno le indica al sistema que no hay problema en la elección del
Grupo, de tal manera que se desea inscribir en al Curso.
El sistema registra el Alumno al Curso y actualiza el número de Alumnos
Inscritos en el Grupo.
Mientras el Alumno no exceda el número de Créditos permitido puede seguir
registrando Cursos.
El Alumno le indica al sistema que haterminado de realizar su Inscripción.
El sistema muestra el Horario y lo imprime.
Fin del Caso.
Como habíamos visto antes algunos de los candidatos encontrados no se convertirán en
clases, pues son propiedades o acciones de otros. Pero contamos con información
adicional que no teníamos antes.
En el paso 2 tenemos que no todos los Cursos abiertos por la Universidad pueden ser
inscritos por el Alumno, sino sólo aquellos en los que se cumpla con los Requisitos y de
acuerdo a la Carrera cursada. Aquí tenemos una clase candidata: Carrera.
En el paso 8 al no exceder el número de Créditos permitido, nos obliga a que un Curso
debe de tener al menos una cantidad de Créditos asignada.
Por lo tanto, un Curso tendrá las propiedades de Número de Créditos y de Requisito, sin
embargo, aún nos falta detallar más este objeto como se verá más adelante.
Con referente al candidato sistema es obvio que no crearemos instancias de éI, pues es la
aplicación en si.
En este punto surgen aspectos que son importantes para una buena administración del
proyecto:
Una clase es una colección de objetos que tienen en común estructura,
comportamiento, relaciones y semántica
Una clase se dibuja como un rectángulo con tres separaciones
Las clases deben ser nombradas utilizando el vocabulario del dominio
Deben crearse estándares de nomenclatura
P.e., todas las clases tienen nombres en singular iniciando con la letra "c"
minúscula seguido de una letra mayúscula
La siguiente Figura, muestra las clases encontradas después de analizar el caso de
registro a cursos.
cCoordinador
Figura 4.8: Clases encontradas en la descripción del Caso
4.1.3.C Atributos
Definición de atributos
Los atributos se utilizan para guardar información en un objeto y diferenciarlo de los otros.
Existirán atributos comunes a todas las clases de una jerarquía de clases, que deberán
ser definidos en la clase origen de todas las demás. Es conveniente que los atributos de
un objeto sean manejados sólo por los servicios definidos en ese objeto. Si por cualquier
razón otro objeto necesita acceder a los atributos de este objeto, se creará un servicio
especifico para ello.
Ocultar la información
Del mismo modo que se diseñan los objetos para que funcionen en cualquier entorno, se
hade ocultar toda la información posible del interior del mismo. Estaremos utilizando
entonces el principio de encapsulación. Se debe de evitar, por tanto, que cualquier otra
clase pueda visualizar elementos ocultos de ésta.
Una vez establecidas las Clases iniciales, es posible asignarles los atributos básicos a
cada una.
0
0
La estructura de una clase se representa por sus atributos
Los atributos pueden encontrarse al analizar las definiciones de las clases, los
requerimientos del problema y por aplicar el conocimiento sobre el universo del
problema
Analizando la definición de la clase Alumno encontramos sus siguientes atributos:
Un alumno tiene un
nombre, matricula y
carrera
cAlurnno
&Carrera
Figura 4.9: Definición de Alumno
Algunas veces no estan directo encontrar los atributos de una clase porquepodemos
estar definiendo los atributos de otra, veamos la siguiente definición:
Cada curso ofrecido
tiene una clave,
lugar y horario
Figura 4.10: Definición de Curso
Debemos de ser cuidadosos porque aunque la definición se refiere a un curso, las
características antes descritas son las que presenta un Grupo (Figura 4.11), estoes lo
que pasa con las clases que están relacionadas con otras o son contenedoras. La Figura
4.12 muestra la definición de curso corregida.
Cada Grupo tiene
una clave, lugar y
horario
cGrupo
QCveGrupc
Figura 4.1 I :Definición de Grupo
Cada curso ofrecido
tiene al menos un
grupo asignado
Figura 4.12:Definición de Curso
No todas las clases y los atributos los encontraremos al analizar los requerimientos o las
definiciones, habrá clases o atributos que se irán agregando paulatinamente mientras se
va desarrollando la aplicación. A continuación en la Figura, se muestran lasclases
encontradas con sus atributos:
".
cProfesor
".
@Nombre
QNumEmpleado
I
ccurso
@Grupo
$>U EA
@Profesor
@NoAlumnos
&Trimestre
I
I
P
~-
.
cUEA
&Cve UEA
I@Creditos
@Requisito
1
"1
7
"
cCoordinador
~
@Nombre
@NumEmpleado
Wealnvestigacion
Carrera
@$vecarrera
1
clnscripción
I1
I
Figura 4.13 Clases con atributos
Si observamos la clase Curso, no tiene las propiedades de Créditos, Materia, y Requisito
como Io habíamos definido antes, esto se debe a que definimos la clase UEA dentro de la
clase Curso. Entonces un Curso tendrá un Grupo, una UEA, un Profesor, No. Alumnos y
Trimestre.
..
.
4.1.3.DDiagramas de Clases
El éxito en la etapa del análisis orientado a objetos se basa en identificar las entidades o
clases que intervendrán en el desarrollo final y cómo se van a interrelacionar. Por tanto,
se pretende convertir los elementos del mundo real en clases para intentar resolver el
problema propuesto. La ventaja que se obtiene de este tipo de análisis es que existe una
aproximación entre todos los participant.es deun proyecto, analistas y usuarios.
Un diagrama de clases muestra la existencia de clases y sus relaciones en la vista lógica
de un sistema. Además se les puede aplicar los elementos de modelado:
Clases con su estructura y comportamiento
Relaciones de asociación, agregación, dependencia y herencia
lndicadores de multiplicidad y navegación
Nombres de roles
Dado que el Modelo de Dominio del Problema esta centrado en los objetos de información
y sus relaciones, es posible a partir de los Diagramas de Clases establecer la estructura
que tendrá la base de datos. Por esta razón utilizaremos dos conceptos fundamentales
de las bases de datos relacionales: Entidad y Relación.
Entidad es una persona, lugar, cosa, concepto o suceso, real o abstracto, de interés para
la organización. Un entidad esta compuesta por atributos o características que la hacen
diferente a otras. En nuestro enfoque Orientado a Objetos es el objeto acerca del cual
queremos guardar información.
Una relación es una asociación o correspondencia entre entidades. Esta definición es
parecida a la que tenemos con los objetos, en la que establecemos los vínculos que
tendrán entre si los objetos.
Determinación de los atributos que pudiesen ser llaves relacionales
La llave relacional es un término que viene del diseño de bases de datos relacionales, su
significado es el de un identificador Único que puede formarse por uno o más atributos
que conforman la entidad. Se utiliza para poder identificar un registro de la base de datos
de manera única y sin ambigüedades. Por lo tanto, no pueden existir dos valores de llave
primaria iguales.
Por lo anterior es importante plantear las clases que serán la base para la definición de
relaciones, por lo que es necesario establecer los atributos que constituirán la llave
relacional.
El modelo queda de la siguiente forma:
Nombre
I
ccurso
&Grupo
3
Profesor
@Trimestre
cProfesor
cCoordinador
@NumEmpleado @
@Nombre
Wealnvestigacion
@NumEmpleado @
&Nombre
Q$cealnvestigacion
%Carrera
"~
I
I
&Nombre
QCreditos
@Requisito
cGrupo
1
I
clnscripción
Calificacion
QGru po
@Trimestre
1
I
i
Figura 4.14: Clases con Atributos llave señalados (@)
Tenemos problemas al querer asignar la llave relacional a las clases Curso e Inscripción,
debido a que el manejador de base de datos relacional no incluye tipos de datos
complejos como lo son los objetos, sólo acepta tipos de datos simples. Así que debemos
utilizar las llaves relacionales de los objetos contenidos en estas dos Clases (ver Figura
4.15) :
..
..
..
....................................................
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Universidad Autónoma Metropolitana ktaDalaDa
. ~ .
~
-
~~~
.
"
"
"
~~
~
ccurso
@CveGrupo @
@CWUEA@
@Trimestre @
@NumEmpleado
%NoAlumnos
Figura 4.15: Clases con Atributos llave formados por tipos de datos simples
Tipos de Asociaciones
Existen tres tipos de asociaciones:
Asociación
Agregación
0
0
0
Dependencia
Una asociación es una conexión bidireccional entre clases
Una asociación se indica con una línea conectando las
clases
relacionadas
Una agregación es una forma más rígida de relación donde la vinculación es entre un
todo y sus partes
Una agregación se indica con una línea conectando las clases relacionas
con rombo en el extremo de la clase que representa al todo
Una relación de dependencia es una forma másdébilde
relación que indica una
vinculación entre un cliente y proveedor en donde el cliente no tiene un conocimiento
semántico del proveedor
-
Una dependencia se indica con una línea punteada con dirección del
cliente al proveedor
Identificación de las asociaciones estáticas entre clases
La forma de establecer los vínculos que tendrán entre sí los objetos es la siguiente:
-
Buscamos todas las combinaciones validas deasociaciones binarias:
Profesor vs Curso
Profesor vs UEA
Profesor vs Grupo
Coordinador vs Carrera
Alumno vs Carrera
Alumno vs Curso
Alumno vs UEA
Alumno vs Grupo
Alumno vs Inscripción
.:.:.:......,......,.
.:.:.m:.:.:~m ......,.,..
:$$M
:
:*,:::...
~ A........I.....
~
...................................
............................ ..~
~
Carrera vs UEA
F
Curso vs UEA
Curso vs Grupo
Curso vs Inscripción
UEA vs Grupo
UEA vs Inscripción
Grupo vs Inscripción
Las asociaciones ternarias, cuatemarias y las que le siguen no las aplicaremos, nos
quedaremos sólo con las asociaciones hinarias. Las combinaciones marcadas con negrita
son las que tomaremos como validas.
Algunas combinaciones no se relacionan como pudiera parecer, por ejemplo un Alumno
no esta realmente relacionado con la UEA, sino con la Inscripción al Curso para acreditar
la UEA. Las siguientes combinaciones marcadas con itálica no tienen relación directa:
Profesor vs UEA
Profesor vs Grupo
Alumno vs UEA
Alumno vs Grupo
Alumno vs Curso
UEA vs Grupo
UEA vs Inscripción
Grupo vs Inscripción
Identificación de la multiplicidad
detectadas
13
cardinalidad de las asociaciones binarias
La multiplicidad define cuántos objetos participan en una relación, nos indicara las reglas
de negocio que la información debe de cumplir en todo momento para que guarde la
integridad entre los distintos elementos que la componen.
La multiplicidad es el número de instancias de una clase relacionados
con UNA instancia de Iraotra clase
Para cada asociacicln y agregación, existen dos decisiones de
multiplicidad que se tienen que hacer: una para cada extremo de la
relación
Aunque las asociaciones y las agregaciones son bidireccionales por omisión, con
frecuencia es deseable restringir la navegación en una sola dirección
-
Si se restringe la navegación, se agrega una flecha para indicar la
dirección de la navegación
La forma de determinar la cardinalidad, consiste en establecer cuantos elementos a lo
mínimo y a lo máximo podemos relacionar un objeto con los objetos del otro lado de la
asociación. Los valores pueden ser 0,1,2,...; cuando desconocemos el número preciso de
objetos que se relacionan, aplicamos el concepto de muchos (*) o N.
A continuación determinaremos la cardinalidad de las asociaciones validas de nuestro
ejemplo.
Asociación Grupo vs Curso
Un Grupo tiene asignado sólo un Curso y un Curso es abierto para un sólo Grupo (Figura
4.16)
1
Figura 4.16: Asociación Uno a Uno
Asociación UEA vs Carrera
Una Carrera puede tener varias UEA y una UEA puede ser impartida en varias Carreras
(Figura 4.17)
Figura 4.17: Asociacion Muchos a Muchos
Asociación Coordinador vs Carrera
Un Coordinador se encarga de una sola Carrera y una Carrera tiene sólo un Coordinador
(Figura 4.18)
Figura 4.1 8: Asociación dinámica
Esta relación en realidad no existe porque es dinámica , es decir, se da en tiempo de
ejecución de la aplicación. Un Coordinador en realidad es un Profesor que tiene a su
cargo la Coordinación de cierta Carrera, su función es planear las UEA que se abrirán en
el Trimestre.
Entonces un Profesor esta relacionado con la Coordinación y puede estar a su cargo o no
(Figura 4.19).
1
Coordinación
1
1 0..1
~"
11
1
Figura 4.19: Asociación Uno a Uno con opcionalidad
Ahora analicemos la asociación Coordinación vs Carrera, al ver sus características de
ambas nos damos cuenta que no están relacionadas porque son dos cosas diferentes, la
Coordinación no solamente se encarga deuna
Carrera, puede abarcar el Tronco
General, los laboratorios, el Posgrado y otras áreas de Universidad.
Debido a que una Coordinación tiene 1JEA asignadas y las UEA pueden estar en varias
Coordinaciones, obtenemos la siguiente asociación:
r
"
"
"
" -~
Coordinación
- -.
1..*
"~
Figura 4.20: Asociación Muchos a Muchos
Todas las relaciones se muestran a continuación:
cCoordinaci6n
QCveCoordinación
@Nombre
@Division
1
IQ
0..1
1..*
QCwProfesor
@Nombre
weatnvestigacion
cGrupo
@CveGrupo @
@Salon
@Horario
1
!
1
1
l..*
cUEA
I
I
ccurso
QCveGrupo
I
.
..
,/'
IQ
1
@Requisito
I
ccarrera
I
I
cAlumno
I
&Nombre
Figura 4.21: Diagrama de Clases que incluyen asociaciones con multiplicidad
Notemos que se cambio el nombre de la propiedad NumEmpleado de la clase Profesor
por CveProfesor con el fin de que sea más entendible el diagrama. También la clase
Alumno cambio su propiedad Carrera, un tipo de dato complejo, por el atributo llave
CveCarrera , un tipo de dato simple.
Remplazo de asociaciones cuya multiplicidadsea Uno a Uno o Muchos a Muchos.
La razón por la que se remplazarán tales asociaciones es que en ellas se establecen
vínculos complejos entre conjuntos de objetos, que un manejador de bases de datos
puede no soportar o sea difícil darles mantenimiento.
Las relaciones Uno a Uno normalmente corresponderán a situaciones en las que se
establecieron atributos como clases. Por lo que la estructura de una de las clases será
parte los atributos de la otra (Figura 4.22):
I
L
Clasel
I
I
Atributos de Clasel
Atributos de Clase2
Figura 4.22 Simplificación de la asociación Uno a Uno
Sin embargo, es necesario ser cuidadoso con la opcionalidad dentro de las asociaciones
Uno a Uno (Figura 4.23):
Figura 4.23: Asociación Uno a Uno con opcionalidad
Si decidiéramos unir los atributos de las clases, se tendrían algunos campos sin utilizar
con posibles problemas de llenados err'óneos. Por lo tanto, la clase con opcionalidad se le
agregara el atributo llave de la clase a la que esta vinculada.
La forma de simplificar las asociaciones muchos a muchos, consiste en incluir una nueva
clase en lugar de la asociación. Los atributos de la clase nueva serán las llaves
relacionales de las clases con quien se estará vinculando, más los atributos que
correspondan por situación propia. Como se muestra en la Figura 4.24.
m
Universidad Autónoma MetroDolitana IztaDalaDa
I 4
Clasel
Clasel
3
'
I
1 1
l..*
I====!
Clase2
I
~ 1 a s e 1 - ~ 1 a Is e 2
a) Asociacion Muchos a Muchos
b) Asociacion Muchos a Muchos Simplificada
Figura 4.24: La simplificación Muchos a Muchos contiene sólo asociaciones Muchos a
Uno y produce una nueva clase.
El modelo completo con los reemplazos correspondientes se muestra en la Figura 4.25:
cCoordinación
cProfesor
Q
QCveCoordinaciÓn
@Nombre
&Division
0..1
1..*
ccurso
&Nombre
@Creditos
&$Requisito
-4
@CveGrupo Q
QCveUEAQ
@Trimestre Q
@CveProfesor
1..* QNoAumnos
%Salon
@Horario
1
"
I
1
1..*
I
"
I
clnscripci6n
I1
$;Matricula Q
@Nombre
CveCarrera
1
@CveU=@
@vtatricula Q
QCveGrupo @
@Trimestre Q
QCalificaaon
Figura 4.25: Modelo que contiene sOlo asociaciones Muchos a Uno y Uno a Uno con
opcionalidad
Universidad Autónoma Metropolitana IztaDalaDa
Es interesante lo que paso entre las clases Grupo y Curso, al principio cuando se
definieron las clases hicimos la distincibn entre éstas dos, pero al analizar sus relaciones
llegamos a que el Grupo es parte de Curso. Tal vez el lector ya se había percatado de
esta situación, pero fue mi propósito dernostrar que siguiendo con el modelo llegaríamos a
las clases correctas.
También podemos comprobar que si no hubiéramos encontrado la clase Curso al analizar
los requerimientos, la pudimos haber obtenido con alguna de las asociaciones, por
ejemplo, la asociación Alumno vs UEA (Figura 4.26):
Figura 4.26: Asociacion sin la clase Curso
AI aplicar la simplifcación a esta asociacion obtenemos la clase Curso, que como
habiamos visto es la que realmente esta asociada con UEA y con Alumno (Figura 4.27).
1..*
Figura 4.27 La simplificación crea una nueva Clase
Sin embargo, todavia existe una relaciljn Muchos a Muchos en Curso vs Alumno, por lo
que, volvemos aplicar la simplificación a esta asociación para obtener la clase Inscripción
(figura 4.28):
Eh:H7,
clnscripción
,
cAlumno
Figura 4.28: Modelo con sólo relaciones Uno a Muchos
m
.....
Universidad Autónoma Metropolitana IztapalaDa
Aplicar los conceptos del Modelo Orientadoa Objetos
Hasta este punto se han seguido los mismos pasos que se encuentran en el Análisis de
Bases de Datos Relaciones. Sin embargo, nose
han incluido dentro del modelo
conceptos como herencia, polimorfismo, encapsulamiento, métodos, agregación y
composición. Por lo que en esta etapa iniciaremos a incluirlos.
Existen dos tipos de definición de estructuras dentro de esta fase:
Parte-Todo
Por ejemplo, Generalización-Vehículo, EspecializaciónAutonlóvil.
Emula la forma en que dividimos los objetos que nos
rodean. Por ejemplo: Vehículo , compuesto de ruedas,
motor. asientos. etc.
Parte-Todo
Este tipo define las relaciones que (existen entre las clases contenedoras y clases
contenidas. Las clases contenidas no heredan atributos o servicios de las clases padre.
El concepto más fácil de incluir es el de agregación simple,si recordamos una agregación
es una relación entre el todo y sus partes. La agregación composición es más restrictiva
que la agregación simple, se tiene que éI todo y sus partes tienen el mismo tiempo de
vida, es decir, si se crea el todo se crean las partes; por el contrario si se destruye el todo
también se eliminan sus partes.
En la Figura 4.29, se muestra el modelo completo con las asociaciones de agregación y
composición.
Universidad AutónomaMetropolitana IztaDalapa
cProfesor
0..1
l..*
UEA-Coordinacion
____I_
&CveCoordinacion
r-"
@
1 .*
l.'
l1
"
"~~~
1
C
l..*
1
I"I
1
€$Salon
@Horario
PlancleEstudios
@Cv&arrera@
@CVC!UEA@
1..*
,* + T I P ~ ~ J E A
1
"
A
cCarrera
Qcvecarrera @
o"----------@Nombre
i-"
1
I
clnscripción
cAlumno
@Matricula @
l..*
&Matricula @
QCveGrupo @
@Trimestre @
'
Figura 4.29: Asociaciones de Agregación y Composición
Se tiene que un Curso está compuesto por profesores, UEA y las inscripciones de los
alumnos al grupo. Pudiéndose crear cada uno de ellos en momentos muy distintos. En
cambio cuando se crea un alumno dekle existir una carrera, o de lo contrario no existe el
alumno; y cuando se elimine la carrera también se deben de eliminar los alumnos que
pertenezcan a ella. Pero una carrera puede existir sin alumnos, aunque suene ilógico
debemos tenerlo presente.
Las asociaciones de agregación sugieren que las operaciones de mantenimiento a esos
objetos tienen que hacerse dentro de una misma transacción. Por lo que es conveniente
indicarlas en el modelo.
Generalización-Especialización
Se utiliza este tipo para definir las relaciones de herencia entre una clase padre y su hija.
De esta forma, la herencia toma atributols y servicios de la clase padre.
O
O
0
La herencia es una relación entre una superclase y sus subclases
Existen dos formas de identificar la herencia:
Generalización
Especialización
En el nivel más alto aplicable en la ,jerarquía se indican los elementos comunes como
atributos, operaciones y/o relaciones
Si recordamos nuestra aplicación será accedida por los usuarios mediante un login y un
password, los usuarios son los profesores y los alumnos, entonces podemos establecer
una relación de herencia que defina los atributos de los usuarios en una clase de nivel
más alto. Como se muestra en la Figura 4.30:
@Login
@Password
~
I
QCveProfesor @
@Nombre
Qpcealnvestigacion
cAlurnno
@Matricula @
@Nombre
@$vecarrera
Figura 4.30 Asociación de Herencia
La asociación nos dice que tanto como Profesor y Alumno heredan las propiedades Login
y Password de la clase Usuario. No se mostró todo el modelo, porque resultaría difícil
dibujar esta relación en el diagrama de clases.
Los conceptos antes vistos son los que incluiremos en este modelo, los que faltan se
incluyen en las siguientes etapas. A este nivel también podemos definir los métodos
básicos de las clases, pero los dejaremos para el siguiente modelo. La encapsulación ya
la discutimos al definir los atributos.
Quiero detenerme en este instante para hacer notar al lector que aquí radica el 90% de
las diferencias entre el Diseño tradicional yel DOO. Es el trabajo pormenorizado y
concienzudo que determine las clases el que convertirá a Java en una herramienta que
facilite la programación de nuestras aplicaciones, o que sea un lenguaje más, con buenas
prestaciones y punto. Por tanto, es primordial que el analista o analista-programador sepa
que de éI depende que el programador tarde más o menos tiempo en desarrollar una
aplicación.
El problema surge, sin duda, a la hora de definición de clases. Es francamente difícil, por
no decir imposible, sentarse alrededor de una mesa y diseñar todas las clases. En la
práctica, este proceso será paulatino, iremos incorporando a las bibliotecas de clases las
que conelpaso
del tiempo vayamos considerando como reutilizables. Por tanto,
deberemos comenzar con un mínimo de clases a las que iremos incorporando nuevas, lo
que implica que realmente sacaremos provecho de la orientación objeto cuando llevemos
un cierto tiempo haciendo aplicaciones, o sea, que paciencia, ya que el resultado dará
paso a lo que todo programador desea y que es Io que se ha venido a llamar últimamente
R.A.D. (Rapid Application Development) o Desarrollo Rápido de Aplicaciones.
Discutido este punto pasemos a la siguiente etapa del desarrollo, el Modelo de Análisis
Dinámico.
Universidad Autónoma MetroDolitana IztaDalaDa
El objetivo de este proceso es identificar las principales interacciones dinámicas entre los
objetos obtenidos y por supuesto descubrir nuevos objetos dinámicos. En primer lugar se
establecen los distintos tipos de objetos que pueden estar dentro de un sistema. Se
plantea el mecanismo de colaboración entre los objetos, así como los mensajes y la
secuencia de los mismos.
Como hemos entrado de lleno en las clases que podríamos llamar informáticas, esta muy
clara la división que se puede hacer.
Por un lado, tenemos aquellas clases que se van a convertir en objetos en pantalla y que,
por tanto, tienen representación gráfica. Son las clases visuales; por el otro, las que son
una colección de propiedades y métodos que son llamados desde otros objetos pero que
no forman parte de la interfaz, son las clases no visuales. A estos, se han unido clases
que manipulan datos.
Por tanto, el diseño de las clases que anteriormente veíamos nunca puede ir desligado
con los objetos visuales que vaya a telner la aplicación. Según esto, hay una forma muy
clara de asociar las clases definidas a nivel analítico con los objetos que el usuario va a
ver.
Las categorías más simples de objetos son:
0
Objetos lnterfaz
0
Objetos de Negocio
0
Objetos de Datos
Objetos lnterfaz
I
I
I
n
Presentanlainformación
al usuario y/o
permiten la adquisición de información del
usuario hacia el sistema.
<<Nombre dclOtqetoIrLcrfnz>>
Objetos de Negocio
Se encargan de la lógica (los algoritmos)
de la
aplicación,
y delas
reglas
del
negocio.
0
< < N o n h e delObjdodeNegoc~e>
Objetos de Datos
1
CCNmnhre
o
del Objetode D a t o @ >
Establecen la conexión con las fuentes de
datos, así como la consulta y actualizaci6n
de los datos.
A
~~~~~~.~~
........................................,..
,<.,.,.....,~
.......................................
~~~~~~~
Universidad Autónoma MetroDolitana IztaDalaDa
Cuando un programa se constituye sólo con estos tres tipos de objetos se dice que se
está utilizando un modelo de Tres Capas o de three tier. Estemodelo permite mejores
niveles de mantenimiento, pues sólo será necesario cambiar la capa donde se solicitan
las modificaciones de funcionalidad del programa. Este modelo puede expandirse en un
modelo Multicapa o rnulfi tier, que incorpora más de tres niveles de comunicación.
UML utiliza el modelo de tres capas, en la Figura 4.31 muestra en que sentido fluye la
comunicación entre capas.
Figura 4.31 Modelo de tres capas con notación de Objectory
Todas las transacciones inician y terminan con la interacción entre un actor y un objeto
las
capas
adyacentes, no puede haber
interfaz. La comunicación es sólo entre
comunicación de otro tipo, por lo tanto no hay comunicación entre la capa de interfaz y la
capa de datos.
El primer paso que debemos hacer en un ADO0 será explicitar con mayor claridad los
puntos funcionales del sistema definidos en el Modelo de Requerimientos. Utilizaremos
para ello los escenarios.
Esta denominación vienedeanalizar
la realidad como si de una película se tratase,
viendo qué escenarios se producen. Normalmente derivarán de los puntos funcionales.
Un escenario es una instancia o ejemplo del Caso, en el se establecen los valores
específicos de cada paso del Caso y llas acciones que realiza el actor. Un escenario lo
componen las siguientes partes:
Descripción del Caso
Descripción de los valores para cada paso del Caso.
Para cada caso se seleccionan los escenarios mas probables y significativos:
Escenario de operación más simple
Escenario de operación correcta m i s representativa
Escenario de operación incorrecta
Escenario de operación con excepciones
De nuestra aplicación de ejemplo, acerca del Caso de Manfenirnienfo de Horan'o podemos
1 escenario siguiente (Tabla 4.'1):
lenera 3
.............................................................
.................... ?. ........*:.. ........... >..................................................
&Bj&l;p:c&
................................................
.:.
................
.....
...:.:.:.:
j:::::.:::..:.:............................ :.:.:.
~
...............
:...::.:......................
...............
. . . . . . . .......
: ................................................................
......................................
...............
1
2
3
8
9
10
:I Alumno da su número de matricula
3 sistema muestra los Cursos a los que
;e puede inscribir de acuerdo a su
>arrera.
~
~
~
~
2ursos para la Carrera de Computación:
Análisis y Diseño de Sistemas de
Computación
3 Introducción al Diseño de Bases de
Datos
ZI Análisis de Algoritmos
3 Alumno selecciona el Curso al que se J Análisis y Diseño de Sistemas de
Computación
lesea inscribir.
3
u
p
o = C151
3 Alumno selecciona un Grupo
:orrespondiente al Curso elegido.
3 Alumno verifica el Horario, el Profesor Horario
Teoría : Lunes, Miércoles y
el Salón del Grupo seleccionado.
Viernes de 18:OO a 19:30.
Practica : Jueves de 18:OO a 20:OO
Profesor
Luis F. Castro Careaga
Salón
B-310
La elección es OK
=I Alumno le indica al sistema que no
l a y problema en la elección del Grupo,
Je tal manera que se desea inscribir al
hso.
3 sistema registra el Alumno al Curso y Supóngase que el alumno se inscribió a
actualiza el numero de Alumnos
curso de ADSC, cuyo cupo era de 40
entonces su cupo será de 39.
nscritos en el Grupo.
Supongamos que registra sólo un curso
Mientras el Alumno no exceda el
?úmero de Créditos permitido puede
seguir registrando Cursos.
El Alumno le indica al sistema que ha
La inscripción es OK
terminado de realizar su Inscritxión.
El sistema muestra el horario y lo
Se imprime el horario con los datos:
Imprime.
Clave de la UEA: 212355
Nombre de la UEA: Análisis y Diseño dc
Sistemas de Computación
Grupo: C151
Profesor: Luis F. Castro Careaga
Horario:
Teoría : Lunes, Miércoles y Viernes de
18:OO a 19:30.
Practica : Jueves de 18:OO a 20:OO
Salón: B-31O
3
Fin del Caso
Tabla 4.1 Caso y un escenario asociados correspondientes a la inscripción de un Curso
:
Realizaciones de Casos
Para cada escenario, es necesario identificar los objetos con los que interactuará el actor,
los objetos que harán las operaciones relacionadas con el negocio y los objetos que
obtendrán la información dela base de datos. Para proceder a la identificación de los
distintos tipos de objetos nos apoyamos en los diagramas de interacción.
Los diagramas de interacción descritlen cómo se realizan los Casos por medio de
interacciones entre conjuntos de objetos.
Existen dos tipos de diagramas de interacción:
Diagramas de Colaboración
0
Diagramas de Secuencia
El Modelo de Análisis Dinámico utiliza los Diagramas de Colaboración para obtener las
clases dinámicas. La notación de éstos diagramas describe a las relaciones dinámicas
entre los objetos mediante líneas rectas y los mensajes que se envían a través de las
flechas. Los objetos se representan en forma de rectángulos en donde se indica a la clase
que pertenecen.
Un diagrama de colaboración muestra las interacciones de los objetos organizadas
alrededor de los objetos y sus ligas de unos con otros.
En la Figura 4.32 se puede observar un diagrama de colaboración para satisfacer el
primer punto del escenario de ejemplo (Tabla 4.1). Ya que el usuario estará inscribiendo
un curso abierto por la Universidad, la primera actividad que se tiene que realizar es
identificar al alumno para obtener los cursos que puede inscribir de acuerdo a su historial
académico.
La nomenclatura que utilizamos para nombrar los diferentes tipos de objetos es la
siguiente:
Todos los objetos tienen nombres en singular iniciando con la letra "o" minúscula
seguido de una letra mayúscula que indica el tipo (I interfaz, N negocio y D datos). Por
último se tiene el nombre del objeto.
1: matricula + OK
_..
,
I
clReqistroCursos
,
:Alumno
~
J;
2: validarMatricula( )
cNAlumno
1 4,
3: getExpediente( )
Figura 4.32 Diagrama de Colaboración para el escenario de ejemplo
La primera acción se da cuando el objeto interfaz correspondiente a la pantalla de registro
debe identificar al alumno. Como su función se limita a mostrar y recibir información, debe
solicitarle esta información a un objeto de negocio que es especialista en servicios sobre
los alumnos.
Por lo tanto, le envía una solicitud all objeto de negocio oNAlumno, éste validará la
matricula del alumno y para poder completar con su responsabilidad, debe consultar sus
datos, por lo que le pedirá este servicio al objeto de datos oDAlumno a través del servicio
getExpediente0. Este servicio devolveri la información correspondiente al alumno, la cuál
es necesaria para obtener los cursos disponibles.
Los diagramas de colaboración no describen una relación temporal, pero es conveniente
numerar los mensajes para saber cuál rnensaje se generó primero.
Para describir los diagramas de colaboración también podemos utilizar la notación de
UML con extensión a Objectory. Veamos la Figura 4.33.
1: matricula
:Alumno
+
OK
2: v31idarMatricula( )
olPantal1aReq:stro :
clReqistroCursos
3: getExpediente( )
oNAlumno: CNAlumno
oDAlumno: cDAlurnno
Figura 4.33 Diagrama de Colaboración en notación Objectory
Universidad Autónoma Metropolitana IztaDalaDa
El diagrama completo para el escenaricl antes descrito se muestra a continuación (Figura
4.34) :
-
8: Inscribir Curso
14: Cerrar( )
+OK
__j
2: wlidarMatricula()
1 : matricula + OK
3: getExpediente()
oNAturnno:
cNAlurnno
\9:
: Alumno
-.
.
I oDAlumno :
1 cDAlumno
I
j
Inscribir(lnteger, Integer)
10: setlnscripcion(lnteger, Integer)
5 : getCursos()
13: Cerrar( )
oDCurso :
cDCurso
.._
1L
6:getPlandeEstudio(1nteger)
.
clFinReaistroClJrso
.
...~
-
~~~~
7 : getkterias(
oNPlandeEstudio :
cNPlandeEstudio
)
oDPlandeEstudio :
cDPlandeEstudio
Figura 4.34 Diagrama de colaboración para el escenario de registro a un curso.
Una vezquese identifico al alumno, el objeto interfaz tiene que inicializar los controles
visuales con la lista de cursos que puede inscribir, por lo que solicita este servicio a un
objeto especializado en los cursos (oNChrso). Éste objeto consultara los cursos abiertos a
través del objeto oDCurso, pero comoes necesario seguir el plan de estudios solicita
también al objeto de negocio oNPlandeEstudio para traer las materias correspondientes a
la carrera del alumno. Una vez que se tenga el expediente del alumno, su plan de estudio
y los cursos abiertos es posible dar los cursos que puede inscribir, que a su vez serán
entregados al objeto interfaz. Enesemomento
la interfaz podrá mostrarlos en los
controles visuales y es cuando el Actor podrá seleccionar el cursoa inscribirse.
Cuando el Actor desee inscribir un Cursoel
objeto oNCurso validara los datos y
actualizara el cupo, para agregar el registro a la base de datos se solicita un servicio del
objeto oDCurso.
Identificación de Relaciones Dinámicas
Las relaciones dinámicas proporcionan un camino para la comunicación entreobjetos.
Para identificar las relaciones dinámicas se analizan los diagramas de interacción
Si dos objetos deben "platicar" ahí debe existir un vinculodecomunicación
entre ellos.
En la Figura 4.35 se observa el envío de mensajes entre dos objetos y como se establece
una relación dinámica entre ellos.
3: getExpediente()
oNAlumno :
cNAlumno
oDAlumno :
cDAlumno
*/'
I
Figura 4.35 Relacisón dinámica entre dos objetos
Definición de Servicios
Cuando un objeto le envía un mensaje a otro, se dice que está solicitando un servicio. Los
servicios permiten a los objetos realizar acciones. Digamos que un servicio es el código
del Método almacenado en un objeto. En principio, los servicios surgen de la necesidad
de proveer funcionalidades a otros objetos; sin embargo, también será necesario definir
servicios de uso interno para el propio objeto.Por
tanto, podemos distinguir entre
servicios de uso externo e interno.
Los servicios han de funcionar igual en todos los objetos creados a partir de una definición
de clase. Si esto no fuera así, quizá s'ería necesario crear una herencia para incorporar
esta diferencia de comportamiento.
Es importante identificar todos los objetos que va a necesitar este servicio y también los
objetos que se necesitan desde este sE?rvicio.La Figura presenta la forma en que definen
los métodos de las clases.
3: getExpediente()
oNAlumno :
cNAlumno
I
1
oDAlumno :
cDAlumno
cDAlumno
*getExpediente(fvlatricula : Integer) : tResultado
Figura 4.37Definición de los métodos
I
~
En este modelo se especifican las clases a partir de las cuales se crearán los objetos que
darán servicio al sistema. Estos obj'etos tendrán un tiempo de vida limitado por la
duración de la ejecución del programa. A diferencia del modelo de dominio del problema
en donde se definen principalmente los objetos persistentes.
Principalmente se definen los métodos de cada clase con toda la información necesaria
para su adecuada implementación.
En la Figura 4.38 se muestra el modelo de las clases dinámicas realizado a partir del
diagrama de colaboración de la figura. Se observa que las clases sólo contienen métodos.
Estas clases sirven para describir l a funcionalidad el escenario dado. Las líneas
punteadas indican que objeto instanciará a cual, es decir, que objeto creara a otro. En
nuestro ejemplo, un objeto de
la
clase cNAlumno será creado por un objeto
clRegistroCursos. Y un objeto cDAlumno será creado por un objeto cNAlumno.
I
1
" " " I
i
1
%alidaMatricula(Matricula : Integer) : Boolean
-
~"
r1""
~"
~
"
"
1
9
cDAlumno
'@getExpediente(Matricula: Integer) : tResultado
Figura 4.38 Diagrama de Clases para el modelo dinámico del ejemplo
Se puede seguir los siguientes consejos para crear un diagrama de clases dinámicas:
0
Las clases dinámicas se identifican examinando los objetos en los diagramas de
secuencia y colaboración
0
El comportamiento de una clase se representa mediante sus operaciones
0
Las operaciones pueden identificarse al examinar los diagramas de interacción
También enel diagrama de clases se puede especificar el estereotipo de lasclases.
Cuando un método se ejecute no por una llamada normal, sino cuando sé de un evento,
I
como la pulsación de un botón o la seYecciónde una opción en un menú, el método se
indicara con un estereotipo de evento.
En la Figura 4.39 se muestra el modelo de clases dinámicas completo.
<<lnterfaz>>
clRegistroCursos
<<Negocio>>
cNAlumno
"
"
-
4syalidaMatricula(Matricula : Integer) : Boolean
"
1
<<Datos>>
cDAlumno
%etExpediente(Matricula : Integer) : tResultado
I
<<Negocio>>
cNCurso
I
<<Datos>>
cDCurso
,
,
7".~
"
"
L
~
*getListaCursos(Expediente :Alumno) I
+Inscribir(CveCurso : Integer, Matricula 1 Integer)
1
<<Negocio>>
cNPlandeEstudio
I
1
-
+getCursos()
%etlnscripcion(CveCurso : Integer, Matricula : Integer)
<<Datos>>
*getPlandeEstudio(CveCarrera : Integer) :;tResultado
<<lnterfaz>>
Figura 4.39 Diagrama de clases dinámicas involucradas en el procedimiento del
escenario de registro a cursos.
El proceso de construcción se alimenta del modelo de análisis para generar un modelo
que detalle los aspectos de implantación y de calidad. El modelo de Construcción
además establece la estructura en que estarán distribuidos Para lograr su fin el Modelo
esta constituido por tres modelos más elementales.
0
Modelo deDiseño
0
Modelo de Componentes
0
Modelo de Implantación
El primero deja un modelo sensible a la implantación. Es segundo es el agrupamiento de
los objetos comocomponentesde
programación. El tercer modelo esen sí el código
fuente de los programas.
El modelo de
diseño
nos facilita entender la dinámica del sistema cuando está
procesando un escenario, tomando encuenta aspectos de implantación. Es necesario
evaluar ciertos criterios que aseguren la calidad de los productos obtenidos. La calidad se
vera reflejada en los costos de mantenimiento y en la efectividad del sistema a las
exigencias del usuario.
4.3.1 .A Diaarama de Secuencia
Una de las herramientas principales del diseño es el diagrama de secuencia. Un diagrama
de secuencia muestra las interacciorles de los objetos con base a una secuencia
temporal. Estos diagramas se obtienen a partir de los escenarios analizados en el Análisis
Dinámico y sirven para ver la ejecución temporal detallada de cada paso del escenario.
Un diagrama de secuencia es una gráfica condos ejes. El eje vertical representa la
dimensión del tiempo. El eje horizontal cuenta con los objetos participantes en el
escenario, colocados enel orden qua se van utilizando en base a la capa a la que
pertenecen, o sea, primero van los objetos de interfaz, en seguida los objetos de negocio
y por último los objetos de datos. En lo!; extremos se colocan los actores participantes. La
que simbolizanmensajes
interacción entre los objetossedescribe a travésdeflechas
entre los mismos.
En la Figura 4.40 se muestra el diagrama de secuencia para satisfacer el primer punto del
escenario de visto en el capitulo .
i
\
: Aumno
1
,
1: Matricula + OK
I
,
I
I
2:w~lidaMatricula(lnteger)
3: getExpediente(1nteger) I
-i
I
"
"
4
-0
I
5.
,-
I
I
I
I
I
i
Figura 4.40 Diagrama de Secuencia para el escenario de ejemplo
Se puede observar en la Figura 4.40 que los objetos que están activos se denotan con las
barras verticales sobre las líneas de vida de cada objeto. Una vez que el actor da el
número de su matricula y le indica al sistema que desea inscribir un curso, el objeto de
interfaz se activa y solicita el servicio al objeto especializado en alumnos (oNAlumno).
Éste objeto también se activa y para cumplir su tarea necesita consultar el expediente del
alumno en la base de datos a través ,del objeto oDAlumno. En este momento los tres
objetos están activos. Cuando el objeto dedatos devuelve el resultado de la consulta
pasa a un estado inactivo. Le sigue el objeto de negocio una vez que éste a procesado la
información y la entregado al objeto de interfaz. Por ultimo el objeto de interfaz muestra al
usuario la información obtenida y se queda inactivo en espera de otra interacción con el
actor.
Notemos que cada mensaje está asociado a un método de la clase a la que pertenece el
objeto y por Io regular también incluye los parámetros.
A continuación en la Figura 4.41 se muestra el diagrama de secuencia completo para el
escenario de ejemplo.
II
1
I
I
I
12: Abrir()
I
I
I
I
I
li
15 Cerrar()
I
I
I
I
I
I
I
1
I
I
I
setl+cripcionflntegeq
11:
Integer)
I
I
I
I
I
I
I
I
I
I
I
I
I
\
I
I
I
I
I
I
1
I
I
I
I
I
I
U
I
I
I
I
I
I
I
I
Figura 4.41 Diagrama de secuencia para el escenario de registro a un curso
Los diagramas de secuencia y los cliagramasde colaboración pueden considerarse
semánticamente idénticos, pero con notaciones distintas.
4.3.1 .B Criterios de Calidad para el Diseiio
Para poder evaluar la calidad de un diseño es necesario definir los criterios sobre los que
está basada.
Cohesión en el D O 0
Las clases contenidas en una jerarquía de clases deben tener sólo un fin; si tienen más
de uno, se han de dividir en clases más especializadas.
I
I
I
I
I
I
I
I
I
I
I
I
I
I
Acoplamiento en el DO0
Se han de diseñar las clases del modo más independiente posible. Cualquier clase que
necesite de otras para su correcto funcionamiento está sacrificando su portabilidad a otro
entorno distinto al que se diseño originalmente.
Reutilización del código
Es el paradigma de la programación clrientada al objeto. Cualquier sistema orientado a
objeto se basa en tres constantes fundamentales:
O
Productividad. Existe una gran cantidad de código que puede ser reutilizada dentro de
un proyecto e incluso entre proyectos distintos. Una parte del esfuerzo de desarrollo
se puede encaminar en este sentido, puesto que redundará en beneficios para el resto
de proyectos y desarrolladores.
O
Calidad. Un aumento de productividad sin calidad no sería lógico. La PO0 permite
establecer unas clases base bien probadas que impedirán que cualquier herencia
funcione incorrectamente. Del mismo modo, clases base mal diseñadas harán que el
resto de clases heredadas no funcionen como es debido. La ventaja es que sise
solucionan los errores en las clases base también lo haremos en el resto de las clases
heredadas.
0
Mantenimiento. Esel gran problema de cualquier aplicación. Incluso cuando éste
prácticamente finalizada, surgirán especificaciones no detalladas inicialmente que
harán necesario un replanteamiento de alguna parte de la aplicación. Suele ser normal
que el diseño se haga antes que la programación, pero en PO0 se permite el rediseño
tras la programación.
Como indicación básica, se pueden seguir los siguientes consejos:
Reutlización de clases existentes
AI comienzo de un desarrollo no es probable que existan muchas clases definidas. Sin
embargo, a medida que el proyecto crece, puede ser dificil encontrar la clase que se
necesita y sea mas rentable crearla.
Herencia
Cuando no se encuentre la clase que se ajuste a las necesidades concretas del momento,
será conveniente crear una nueva heredando de la clase que más se parezca a la
necesitada. De esta forma reaprovecharemos todo el código de la clase padre y
crearemos una especialización,
Diseño especifico
A
general
En programación estructurada la base de análisis se fundamenta sobre la filosofía topdown. Aquí es totalmente incorrecto utilizar esta filosofía. Se ha de diseñar la solución
especifica al problema, y a posteriori, investigar a qué clase se puede generalizar.
Minimizar definición de clase
Una clase debe ser lo más pequeña posible. Siempre que exista una especialización, se
ha de crear una herencia nueva para cubrirla. De este modo, las clases son más
manejables y es más fácil recordar qué prestaciones tienen. Sin embargo, tal cantidad de
clases puede resultar una complejidad innecesaria. La solución a este problema podría
ser la agrupación de clases por temas.
Un componente es una biblioteca que contendrá la definición de las clases dinámicas y
puede ser reutilizada por otras aplicaciones.
Las bibliotecas pueden estar constituidas por grupos de clases que realicen los mismos
tipos de servicios. Ejemplo deestetipode
bibliotecas puedeser, todas las clases de
Negocio del modulo Inscripción.
Otro tipo de agrupamiento declasespuedeser
por Temas. Este enfoque permite ver
distintos niveles de complejidad para un sistema o parte de él. De esta forma, se pueden
manejar temas complejos conteniendo otrossubsistemas,de forma que tengamos una
visión mas global del análisis.Ejemplodeestetipode
bibliotecas puede ser, todas las
clases que manejen la información referente a un Alumno, por lo tanto, esta biblioteca
contendrá las clases de negocio, datos, interfaz y cualquier otra relacionada con el tema.
La forma en que se integra la información de componentes esta dada por diagramas de
componentes.
Diagrama de Componentes
Los diagramas de
componentes
ilustran la organización y dependencia entre
componentes de software. Un componente puede ser:
Un componente decócligofuente
Un componente de tiempode ejecución o
Un componente ejecutable
En la Figura 4.42 se puede observar un diagrama de componentes para la aplicación de
ejemplo. Los componentes están agrupados por tipo de servicio.
.i
:. .I ..........I
I
.
i
.I
lnterfaz
Inscripción.dll
~.
,""~~."~~""~-
- --
---
1
I
I
:
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
,~
~
c: .....:.
i
..... ......
1 Negocio
I
............
Inscripción.dll
-
----
1
I
"." ......................................._.
,........
I .........Y
.........................
1: : : : : : : : :1
I
Datos
'
-:. 1
:
"""
...
i
Insctipción.dll [
..
.....................................
Figura 4.42 Estructura de Componentes
:
Las líneas punteadas indican la dependencia que hay entre los componentes, como la
que se da al instanciar los objetos de otro componente.
Estructura de Paquetes
Los componentes plantean servicios reutilizables principalmente y suelen ser librerías
dinámicas o mejor conocidas como dl/. También puede plantearse su distribución en
forma de paquetes que funcionará muy parecido al de componentes. Los paquetes se
agrupan de forma similar al directorio de archivos enun sistema. La jerarquía de
directorios permite una semejanza a la herencia, donde cada nivel representa por lo
general, un agrupamiento más pequeño y más especifico de las clases. Para efectos de
mantenimiento sólo se recurren a las clases de estos archivos.
Cada uno de los conjuntos de clase IO!; agruparemos en paquetes, de hecho, esto es lo
que va a ocurrir normalmente, que muchas clases van a estar interrelacionadas
estableciéndose una jerarquía de clase.
En la Figura 4.43 se muestra una estructura de paquetes similar a la antes vista, pero
agrupados por temas.
cursos
Inscripción
~
"
:...
~
"
"
"
~~
"
.
A
"
"
.
..
~..-
>
.....__._--'
.:
.................
................
"
"
"
"
"
.................
l
"
"
,
..........
...................
,. ..... . . . . . . . . .
Alumno
....................
.
._
í. ...
.....
.:........
,
Figura 4.43 Estructura de paquetes
Cuando construimos un sistema que administra información, es necesario almacenar los
datos en una base de datos. En la actualidad la mayor parte de los sistemas
administradores de bases de datos se basan en el Modelo Relacional. AI contrario existen
muy pocos administradores de bases de datos que se basen en el modelo OO. Por lo que
es necesario establecer una conversión entre los dos modelos cuando la aplicación que
se desarrolla sobre el modelo O 0 utilice una base de datos del modelo relacional.
Modelo Entidad- Relación
Modelar la información del mundo real a través de entidades y relaciones es descrito por
Peter Chen. En este modelo la entidad es una persona, lugar, cosa, concepto o suceso,
real o abstracto, de interés para la organización. Y relación es la asociación o
correspondencia entre entidades.
En el modelo O 0 una entidad es el objeto acerca del cual queremos guardar información
y éste se relaciona con otros objetos.
La forma en que se describen las entidades y sus relaciones con otras se muestra en la
Figura 4.44. Este diagrama modela la relación alumno "cursa" carrera. El nombre de la
entidad va dentro de un rectángulo y el nombre de sus propiedades van dentro óvalos
cada una. El nombre y las propiedades de la entidad están ligadas. La relación se denota
con una línea y con un rombo a la mitad de la línea. Alrededor del rombo se describe la
cardinalidad entre las entidades. La n se utiliza para describir uno o varios.
Figura 4.44 Diagrama Entidad - Relación
El diagrama se leería de la siguiente forma; un alumno cursa una sola carrera y una
carrera es cursada por uno o varios alumnos.
Modelo relacional
El modelo relacional de E. F. Codd describe a las entidades de información a través de
relaciones en forma de tablas. Las tablas están compuestas por renglones y columnas;
cada renglón es un objeto de información y cada columna es un atributo de los objetos de
información contenidos en la tabla. Las operaciones básicas sobre las tablas consideran
la consulta, agregar un,renglón a la tabla, modificar un renglón a la tabla y eliminar un
renglón de la tabla. La Figura 4.45 presenta el modelo relacional para relación AlumnoCarrera.
Alumno
Carrera
Figura 4.45 Tablas del Modelo Relaciona1
Análisis de Datos
Este análisis viene del modelo relacional, en el se obtienen las diferentes entidades de
datos que se convertirán en tablas.
Las tablas resultantes de agrupar los distintos datos de nuestro ejemplo serían:
Alumno
Profesor
Curso
Carrera
Inscripción
Constatamos después de este análisis, y seguramente se habrá percatado el lector, que
las clases pueden perfectamente ser las bases de datos y que las propiedades podrían se
los campos. Por tanto, si hiciésemos el Análisis de Datos, este debería coincidir con el
Análisis Orientado a Objetos, por lo que podemos sacar la conclusión de que ambos son
similares. Sin embargo, hay una diferencia que no está reflejada en esta comparación: el
A 0 0 debe pensarse también desde el punto de vista de la interfaz de usuario, a la que se
hizo referencia en el Modelo de lnterfaz .
Conversión de Clases y Objetos relacionados a Tablas
Cada clase del modelo de dominio debe corresponder a una tabla y cada propiedad de la
clase debe corresponder a un atributo o columna de la tabla. Cada propiedad o atributo
debe tener asociado un tipo de datos simple que pueda implantar el manejador de base
de datos relacional, tales como: números, cadenas, fechas, booleanos, imágenes y textos.
De nuestra aplicación de ejemplo, la clase Alumno genera la tabla que se muestra en la
Figura 4.46
@Nombre
@Edad
W
I
I
I
1
Figura 4.46 Clase persistente convertida a relación
Notamos que la conversión de formatoUML a notación relacional esmuysimple.
Sin
embargo, en la notación relacional se debe mantener la integridad de los datos y evitar su
duplicidad. Por esta razón es necesario destacar los atributos que serán la llave relacional
de la relación. En este caso la llave relacional esta formada por un solo atributo que es la
Matricula, pues con su valor se puede identificar de manera única un renglón dentro de la
tabla. La relación resultante es:
Alumno(Matricula, Nombre, Edad)
Una vez que se tienen los atributos es necesario aplicar los pasos de normalización a la
relación resultante. El primer paso de normalización nos asegura que todos los atributos
definidos los permite el manejador de bases de datos. Los siguientes pasos corresponden
a eliminar dependencias indeseables entre las tablas, para evitar dobles capturas, dobles
eliminaciones y dobles modificaciones. Cuando se tiene una relación sindependencias
indeseables se dice que está en 3a forma normal, lo que genera un modelo confiable y de
comportamiento deseable. Para una descripción detallada del modelo relacional y del
proceso de normalización puedes ir a la literatura existente tal como [Date].
Estructura de Bases de Datos
No me voy a extender innecesariamente en este punto, en principio el modelo de dominio
nos debió haber generado la estructura de la base de datos. Si se hizo un buen modelo
de objetos, el proceso de normalización sólo servirá para detallar más el modelo. El
modelo de dominio que obtuvimos se muestra en la Figura 4.47
&,CwCoordinaci6n
CwProfesor
Q
1
o..1
) 1:.
ccurso
I
4
QCreditos
&Requisito
l..'
j
I
I
1..-
clnscripcibn
&~&WUEAQ
+k+icula @
QCWGN~O @
%Trimestre Q
Qcalificacion
Figura 4.47 Modelo de dominio
Las relaciones definibles entre las tablas de nuestro ejemplo serán:
Alumno(Matricula, Nombre, Edad, CveCarrera)
Carrera(Clave, Nombre, Creditos)
Profesor(Clave, Nombre, Arealnvestigacion)
UEA(Clave, Nombre, Creditos, Requisito)
Coordinacion(Clave, Nombre, Division, CveProfesor)
PlandeEstudios(CveCarrera,CveUEA, TipoUEA)
Inscripcion(CveUEA, Matricula, CveGrupo, Trimestre, Calificacion)
Curso(CveUEA, CveGrupo, Trimestre, CveProfesor, NoAlumnos, Salon, Horario)
UEA-Coordinacion(CveUEA,CveCoordinacion)
Veamos en detalle la relación Alumno - Carrera
Si recordamos un alumno puede cursar una carrera y una carrera puede ser cursada por
varios alumnos, en la Figura 4.48 se muestra esta situación.
I
ccarrera
cAlurnno
I
%Matricula Q
Qcvecarrera @
@Nombre
@$redto
is
1
@Edad
Figura 4.48 Asociación binaria uno a muchos
AI convertir de formato UML al modelo relaciona1 notamos que la tabla alumno se le
añade el campo llave Clave de la tabla carrera para implantar la relación, como se puede
ver en la Figura 4.49.
Figura 4.49 Relación Alumno - Carrera
La forma genérica abreviada de convertir una asociación uno a muchos es:
A la relación correspondiente al extremo del muchos de la asociación, se le agregan los
atributos llave de la relación correspondiente al exfremo del unode la asociación.
Supongamos que se tienen almacenados los siguientes datos en las tablas:
Alumno
30
40
1
...
I
I
...
I
l
...
...
:..............
pf&*#j
Carrera
..............
............................
........................
..............
.........
...................
...................
............:.:..:.:.I.........
..................
.................
Lic.
Computación
Lic.
40 Medicina
...
...
I
I
472
460
...
La información que se obtiene al consultar las tablas puede ser la siguiente: "La alumna
con nombre Cony Ruiz cursa la carrera de Lic.Psicologia
'I.
Implantación Física
La implantación física de la relación Alumno - Carrera en un manejador de bases de datos
como lo es lnterbase se muestra a continuación:
CREATE
TABLEAlumno
(
Matricula
Nombre
Edad
CveCarrera
PRIMARYKEY
FOREIGNKEY
INTEGER NOT NULL,
CHAR ( 60) NOT NULL,
INTEGER NOT NULL,
SMALLINT NOT NULL,
(Matricula),
(CveCarrera) REFERENCES Carrera(C1ave)
);
CREATE TABLE Carrera
(
Clave
Nombre
Creditos
PRIMARYKEY
1;
SMALLINT NOT NULL,
CHAR (30) NOT NULL,
INTEGER NOT NULL,
(CveCarrera)
AnAlisis de las Reglas de Negocio
Es interesante en algunas aplicaciones técnicas
documentar
todos
los algoritmos
empleados por el usuario. Éstos son las reglas del
negocio. Una delas particularidades
del trabajo del analista es quedebedesaber
"un poco de todo" y el usuario siempre
supone que nosotros no solo sabemos ese poco, sino que estamos al corriente de en qué
consiste su trabajo. Es aquí donde debemos recopilar todas las peculiaridades del modus
operandi del usuario.
...........
....: :.:.@$;:;;;;;g
~~~~~.
_._
......,...,.,.........................,.,,:.x
................
~
A
Universidad Autónoma Metropolitana IztapalaDa
,
,, ,, ,
En nuestra aplicación, por ejemplo, hablaremos de la asignación de horarios, del número
de cursos que puede inscribir un alumno, la seriación de la materias, etc. En otros
programas tal vez tengamos que trabajar con una forma diferente de inscripción o
tengamos un sistema que siempre trabaje en dólares envez de pesos, o siempre en
centímetros en lugar de pulgadas, por lo que deberemos tener unos algoritmos de
conversión, que serán las reglas del negocio. Una idea interesante, si estas son muchas,
es crear una tabla con dichas reglas y acudir a ellas cuando haga falta.
Diseño de Aplicaciones
El diseño de una aplicación es la implementación del análisis teniendo en cuenta el
lenguaje con el que se va a programar.
Veamos primero qué componentes va a tener cualquier aplicación sea cual sea su
cometido:
1
.
.. .
... ...... )~..,...,.,...,.',~., , ,...........,
. .............. . ......_..___.._..
......... /.._..,
, ,, , ,, , ,, ,
... , , ... .. , .. , . ., , . ... . . . . , . . , .. . .. ........... ..... . . ,. . . . .. . . . . . . . .. . . , . . . . .. . . . . .. . . . . . . . . . . . , .. ,. . , .. ... , ,. ... ,., ,.,.,,.,..,, .,, ., , , , , , ,., , . ,.,,,,
~~~
,
Base de Datos
Tablas
Rutinas
Formularios
Menús
Queries
,
Reportes
Configuración
Bibliotecas de Clases
Podemos decir que éstos son prácticamente todos los componentes que podemos tener
en una aplicación realizada con los lenguajes orientado a objeto de la actualidad, como
Delphi, Power Builder, Java, Visual FoxPro, C++,
Visual Basic, etc.
Desarrollo de la estructura de una aplicación orientada a objeto
Esencialmente es una forma de organizar los elementos de un programa pensando que
éstos sean fácilmente repetibles. Dichos componentes de nuestras aplicaciones serán de
tres tipos:
1. Comunes para muchas aplicaciones
2. Comunes para el tipo de programa
3. Específicos de la aplicación
En este desglose se mezcla la información que podamos tener en módulos, clases,
archivos de procedimientos, etc. La mayor parte de esta forma global de ver las
aplicaciones es conocida por todos, sin embargo, en la P O 0 entra un concepto nuevo que
noes otro que el diseño, punto fundamental y trascendente en el desarrollo de la
aplicación que nos ocupe y en aplicaciones futuras. Desgranemos cuál será la influencia
directa de la creación de las clases.
Diseño de una estructura de clases
Si seguimos el mismo principio de segmentación que acabamos de ver podemos dividir la
estructura de clases en:
1. Genéricas
2. De dominio
3. Especificas
Cuando nos planteamos a programar en Java o cualquier otro lenguaje orientado a objeto,
debemos previamente hacer un estudio pormenorizado delas aplicaciones que hemos
desarrollado por métodos tradicionales y, comodiceel
lema de la POO, abstraer las
características comunes.
De esta abstracción comprobaremos que saldrán clases que nos valgan para todo tipo de
programas, esto es, que no tendremos que retocar su código sea cual sea la indole de la
aplicación. Éstas serán las clases genéricas. En nuestro ejemplo, una clase genérica
podría ser la Conexión a Fuentes de Datos. Sea cual sea la finalidad de la aplicación que
estemos desarrollando, tendremos este modulo.
Por otra parte, habrá una seriede clases (decódigo) que nos servirá siempre que la
aplicación sea de un tipo, por ejemplo, en nuestro caso, la clase Alumno podremos
utilizarla en innumerables programas, pero para todos, sólo para aquellos usuarios que
tengan de una institución educativa. Éstas serán las clases de dominio de aplicación.
Por último, tendremos lasclasesqueseanválidas
para la aplicación queestamos
desarrollando. Por supuesto, serán objetos repetitivos dentro de la aplicación. Por
ejemplo, en todas las pantallas aparecerá el logotipo de la Universidad en un vértice, esto
convierte automáticamente a la pantalla en una clase.
Resumen
Podemos observar que mucho de lo visto en los párrafos anteriores lo hemos hecho
alguna vez, o por lo menos ha sido intención nuestra hacerlo. Con la llegada de la POO,
es inevitable e inexcusable que pasemos por esta fase tediosa para algunos (no pueden
estar sin teclear más de dos horas seguidas). De ello dependerá en buena medida que la
aplicación salga bien, pero no sólo ésta sino las venideras.
Tampoco debemos llegar a la esquizofrenia en la búsqueda de clases, muchas de éstas
irán surgiendo progresivamente, sin darnos cuenta. Tendremos que rediseñar una y mil
veces algunas clases,estoes
normal. Cuandose consiga la clase perfecta (noes
imposible) será tan fácil como cogerla e insertarla en la aplicación que tengamos entre
manos.
La manera en que se plantean los principios para las formas de trabajo, la organización
de actividades y el enfoque con que se llevara a cabo la construcción de un sistema se le
denomina Arquitectura deDesarrollo.
La arquitectura plantea Métodos que son la
secuencia de pasos necesarios para desarrollar productos del sistema. Cada paso de un
método es un Proceso del Desarrollo, en éI se van cubriendo las etapas de desarrollo.
Existen varios enfoques para del desarrollo de sistemas, Desarrollo en Cascada,
Desarrollo Iterativo, Desarrollo en Espiral, por mencionar sólo algunos.
5.1 Desarrollo de Prototipos
Nosotros seguiremos el enfoque Iterativo, - el Desarrollo en Cascada tradicional presentó
'porqué debemos
muchos problemasy
riesgos para los equipos dedesarrollo,
fropezarnos con un enfoque erróneo, cuando otros ya vieron las dificultades y nos
advierten de las fallas? -. En cada iteración se obtiene un prototipo delsistema
incorporando mayor funcionalidad que el anterior. Cada iteración constituye una pequeña
cascada que ataca un problemamás reducido y controlable.
Resultados de la iteración previa
Descripción de Entrega
Actualizar la asignación
del riesgo
Controlar bibliotecas
Figura 5.1 El Ciclo de Vida Iterativo: Una Minicascada
Esta forma de desarrollo disminuye el riesgoquese adquiere, yaque al final de cada
prototipo, se evalúa si cumple con los requerimientos de los usuarios o bien es necesario
adecuado. Cada adecuación será implementada hasta el siguiente prototipo y no en la
kx
ia
Universidad Autónoma MetroDolitana IztaDalaDa
versión en donde se origino. Esto establece que el sistema deseado será una versión final
de una serie de versiones que se están creando.
T
Riesgo
:onstruccibn
Preliminary
Iteration
Architect.
Architect. Devel.
Iteration
Iteration Iteration
Tiempo
-
Devel. Devel.
Iteration Iteration
Transition Transition
PostIteration Iteration
deployment
Figura 5.2 Perfil de Riesgo de un Desarrollo lterativo
5.2 Tres Características Importantes del Enfoque lterativo
0
0
0
Integración continua
No se hace en un bloque cerca de la fecha de entrega
Entregas frecuentes deejecutables
Algunas internas, algunasde entrega a usuarios
Ataque al riesgo por medio de un avance comprobable
El avance esmedido en productos, no en documentación o en estimados
de ingeniería
5.3 Beneficios Resultantes
0
0
0
Las entregas son una función que obliga al equipo de desarrollo a administrarse para
cerrar a intervalos regulares
No se puede tener el fenómeno de “90% realizado con 90% por realizar”
Puede incorporar problemas/características/cambiosen las iteraciones futuras en
lugar de alterar la producción del momento
Se puede calendarizar mejor el trabajo de loselementosde apoyo a los proyectos
(equipo de pruebas, documentadores, elaboradores de herramientas, administración
de configuración, aseguramiento de calidad, etc.)
5.4 Actividades Detalladas del Ciclo lterativo
O
Planeacióndelaiteración
Antes que la iteración inicie, deben establecerse los objetivos generales
de la iteración en base a
Resultados de la iteración previa (si existen)
-
Evaluación del riesgo a la fecha del proyecto
Determinación del criterio de evaluación para esta iteración
Preparar el plan detallado de la iteración para incluirlo enel
desarrollo
plan de
Incluir los puntos de revisión intermedios para revisar el avance
O
0
O
0
Incluir revisiones y corridas a mano
IdentificacióndeRequerimientos
Seleccionar o definir los Casos a construirse en la iteración
Actualizar el modelo de objetos para que refleje las clases y asociaciones
adicionales que se han identificado
Desarrollar un plan de prueba para la iteración
Análisis y Diseño
Determinar las clases a ser desarrolladas o actualizadas en la iteración
Actualizar el modelo de objetos para que refleje las clases y asociaciones
adicionales que se han identificado
Actualizar la arquitectura documentada si es necesario
Comenzar el desarrollo de los procedimientos de prueba
Construcción
Generar código automAticamente a partir del modelo de diseño
Generar manualmente el código para las operaciones
Completar los procedimientos de prueba
Conducir las pruebas unitarias y de integración
Pruebas
Integrar y probar el código desarrollado con el resto del sistema (las
entregas previas)
Registrar y revisar los resultados de las pruebas
Evaluar los resultados de las pruebas con respecto a los criterios de
evaluación
Conducir una evaluación de la iteración
Preparar la descripción de la entrega
Sincronizar los modelos de código y de diseño
Colocar los productos de la iteración en bibliotecas controladas
-
0
Universidad Autónoma Metropolitana IztaDalapa
5.5 Seleccionando lteraciones
O
O
¿Cuántas iteraciones son necesarias?
En proyectos que toman 18 meses o menos, es frecuente encontrar de 3
a 6 iteraciones
¿Todas las iteraciones en un proyecto son de la misma longitud?
Por lo regular la longitud de la iteración puede variar por fase. Por
ejemplo, las iteraciones de elaboración pueden ser mas cortas que las de
construcción
5.6 No Existe una Soluci6n Mdgica
O
O
Recuerde la principal razón para utilizar el ciclo de vida iterativo:
No se tiene toda la información necesaria a la mano
Las cosas cambiarán durante el periodo de desarrollo
Debe esperarse que
Algunos riesgos no sean eliminados como fué planeado
-
-
Se descubrirán nuevos riesgos enel camino
Algún retrabajo será necesario; algunas líneas de código desarrollado por
una iteración anterior tendrán que tirarse
Los requerimientos cambiarán en el camino
:~ w ,~$ $ $. <p.p.:.:.:.:.:.::
~ <
~s~.
.:~.~~~~~~
+:.~.:.:$+>:.:.:.:.:.:.
.......
......... $ q?v#>
'
..............................
Conelauge
de Internet, la arquitectura cliente-servidor ha adquirido una mayor
relevancia, ya que la misma es el principio básico de funcionamiento de la World Wide
Web: un usuario que mediante un browser (cliente) solicita un servicio (páginas HTML,
etc.) a un computador quehace las veces de servidor. En su concepción más tradicional,
los servidores H77P se limitaban a enviar una página HTML cuando el usuario la requería
directamente o clicaba sobre un enlace. La interactividad de este proceso era mínima, ya
que el usuario podía pedir ficheros, pero no enviar sus datos personales de modo que
fueran almacenados en el servidor u obtuviera una respuesta personalizada.
Desde esa primera concepción del servidor H77P como mero servidor de ficheros HTML
el concepto haido evolucionando en dos direcciones complementarias:
1.Añadir más inteligencia en el servidor, y
2.Añadir más inteligencia en el cliente.
Las formas más extendidas de añadir inteligencia a los clientes (a las páginas HTML) han
sido Javascript y las applets de Java. Javascript es un lenguaje relativamente sencillo,
interpretado, cuyo código fuente se introduce en la página HTML por medio de los tags
<SCRIPT> ... </SCRIPT>; su nombre deriva de una cierta similitud sintáctica con Java.
Las applets de Java tienen mucha más capacidad de añadir inteligencia a las páginas
HTML que se visualizan en el browser, ya que son verdaderas clases de Java (ficheros
*.class) que se cargan y se ejecutan en el cliente. Sobre las posibilidades de las applets
de Java puedes consultar el manual “Aprenda Java como si estuviera en Primero”.
Pero tienen mucho más interés los caminos seguidos para añadir más inteligencia en el
servidor H77P La primera y más empleada tecnología ha sido la de los programas CGI
(Common Gateway Interface), unida a los formularios HTML. La alternativa que Java
ofrece a los programas CGI son los servlets. En la figura 9.1 se muestra la arquitectura
cliente-servidor seguidaactualmente.
DBSP
es una tecnología de
SCRIPTING
en el lado del servidor diseñada
específicamente para acelerar el proceso de construcción desitios 828 (Business to
Business), B2C (Business to Client) o cualquier sistema e-business o de información que
involucre la explotación de datos a través del Internet o Intranet.
L Como funciona DBSP ?
DBSP es una extensión a la tecnología HTML existente. Ciertos delimitadores son
insertados dentro del códigoHTML del documento. Posteriormente estos delimitadores
serán substituidos dinámicamente por información almacenada en una o varias bases de
a su destinatario, en forma deHTML
datos y finalmente eldocumentoseráenviado
estándar.
Además, DBSP incorpora una serie de mecanismos que permiten solucionar problemas
costosos en tiempo y recursos, como lo son la identificación y el control de los usuarios
del sistema, los privilegios de acceso, la seguridad y la confiabilidad de la información.
Todo esto permite acelerar los tiempos de respuesta en el desarrollo de aplicaciones y
disminuir los costos de producción.
Aún con todo lo complicado que una tecnología con estas características pudiese parecer,
DBSP tiene una filosofía simplista.Esto
facilita su aprendizaje y uso, permitiendo
prácticamente desde el primer momento obtener los resultados deseados.
i Que ventajas ofrece DBSP ?
DBSP reducenotablemente
los tiemposdedesarrollo.
A través de un estudio
postmortem a varios desarrollos deaplicacionesweb,
se determinó que en todos los
casos, las fases que más tiempo y recursos consumen son las de construcción,
depuración y pruebas, y sobre todo en secciones que el usuario final no tiene presentes,
como el acceso a datos, la seguridad, la concurrencia, estabilidad, etcétera. Con DBSP,
ya no es necesario construir todas estas piezas y en consecuencia es posible abatir
costos, mejorar los tiempos de respuesta o dedicar este tiempo a construir aplicaciones
más robustas, con una mejor calidad y usabilidad.
No es necesario modificar sus sistemas para trabajar con DBSP. Si usted ya cuenta
con un sistema que utiliza una base de datos relacional, entonces se tiene la posibilidad
de presentar esta información inmediatamente en Internet, sin necesidad de
modificaciones adicionales. DBSPseadhiere a la basede datos e inmediatamente es
posible explotar su información.
DBSP incorpora diversos esquemas de seguridad. DBSP utiliza las características de seguridad
que el sistema operativo y las bases de datos ofrecen. Adicionalmente, DBSP cuenta con algoritmos
de cifrado robustos (1 28 bits), lo que le permitirá almacenar su información de manera segura y en
consecuenciadisminuir los riesgos de que información sensiblecaiga en manosdepersonas
indeseables o equivocadas.
DBSP tiene un rendimiento superior a otras tecnologías. DBSP utiliza la tecnología ISAPI para
Web. Esto le permiteaprovechar las ventajas que los múltiples hilos ofrecen y conseguir un
rendimientosuperior al de otrasarquitecturascomo
CGI o Java Servlets. Además, DBSP se
comunica de manera nativa con los manejadores de bases de datos soportados, mantienendo vivas
sus conexiones, mejorando así los tiempos de transferencia de información.
7.1.- ISAPl (Internet Server Application ProgramInterface)
ISAPI es una alternativa a los ejecutables CGI, de mayor eficacia que éstos . Un servidor
HTTP responde a una petición de ejecución de CGI desde un ‘browser‘ creando un nuevo
proceso y pasando a continuación los datos recibidos desde el browser mediante
variables de entorno y la stdin. Los resultados recogidos por la aplicación CGI estarán
disponibles en la stdout del nuevo proceso. El servidor HTTP crea tantos procesos como
peticiones de ejecución del CGI recibe, por lo que este sistema tiende a consumir mucho
tiempo y a requerir grandes cantidades de memoria RAM, poniendo en peligro e
rendimiento global del servidor HTTP.
A diferencia de este sistema, las aplicaciones ISAPI son DLLs (Dynamic Link Libraries)
que se cargan en el mismo espacio de direcciones que el propio servidor HTTP, lo cual
supone que todos los recursos disponibles para éste lo están también para aquéllas. Hay
por tanto una sobrecarga mínima asociada con la ejecución de estas aplicaciones, ya que
cada petición de ejecución no requiere montar un nuevo proceso.
La interacción entre el servidor y una determinada DLL de la aplicación ISAPI se realiza
mediante un ‘extension control block’ (ECB), en lugar de hacerlo, como en el caso de CGI
mediante variables de entorno y las stdin/stdout.
Las DLLs de aplicaciones ISAPI deben estar construidas con capacidad multitarea
(multithread) dado que podrán recibir múltiples peticiones de ejecución simultáneamente.
EstructuralPartes de la norma
Filters
Functions
Modules
Structures
Internet Service Manager
- Program Structure
- Internet Service Manager Application
- Extension DLLs
- Internet Service Manager API (ISMAPI) Interface
Conexión con otras normas
HTML
HTTP
CGI
7.2.- Como funciona DBSP
t
t
En la figura anterior se muestra la estructura de la Arquitectura Cliente -Servidor
enfocado a programación en Web. Como se dijo anteriormente el DBSP queda a lado del
servidor, esto quiere decir que DBSP y el servidor de Bases de Datos, están en un mismo
Servidor.
El funcionamiento de la tecnología DBSP es muy simple:
Dentro de una pagina HTML se colocan varios tipos de etiquetas. Estas son leídas en un
momento dado por DBSP, de la pagina HTML, por ejemplo: cuando un usuario oprime un
boton de Aceptar dentro de un formulario, se genera un evento en el cual, todo el codigo
en la pagina WEB es leido. Posteriormente el DBSP interpreta las instrucciones que se le
establecieron con estas etiquetas, dando lugar a una conexión a la Base de Datos, a
través del BDE, el cual hace la petición directamente al manejador de bases de datos,
para obtener información.
Para que esto pueda realizarse es necesario a este nivel, contar con algo que nos
comunique en un lenguaje, por así decirlo, de entorno Web. Para eso necesitamos un
servidor Web o un Servidor de Información Web, el cual su función principal es despachar
las paginas que en algún momento dado solicitemos.
La arquitectura de DBSP hace que la escritura de aplicaciones que se ejecuten en el
servidor sea relativamente sencilla y que sean aplicaciones muy robustas. La principal
ventaja de utilizar DBSP es que se puede incrustar a través de etiquetas,
la información que va a proporcionar entre peticiones el cliente.
DBSP permite además la utilización de cookies y sesiones, de forma que se puede
guardar información específica acerca de un usuario determinado, personalizando de esta
forma la interacción cliente-servidor, y liberando de trabajo extra al servidor. Una clara
aplicación es mantener la sesión con un cliente.
EL funcionamiento que tiene el BDE (Borland Database Engine), es de encargarse de
crear conexiones directas al manejador de Bases de Datos, no solo a una Base, si no a
varias de ellas. DBSP, solicita al BDE información, y el BDE se encarga de hacer la
conexión a la Base de Datos y traer la información solicitada.
La característica multithread de DBSP hace que se adecuen perfectamente el tipo de
tareas en donde existen muchas transacciones, esto se refiere a que muchos clientes
acceden a la Base de Datos, para actualizarla al mismo tiempo o bien cuando muchos
clientes consultan a las bases de datos, mientras otros la modifican. Esto va de la mano,
cuando se usan servidores de base de datos, que incluyen soporte para múltiples
conexiones simultaneas.
Mas adelante vamos a desarrollar una aplicación para mostrar como funciona DBSP.
Javascript es un nuevo lenguaje escrito. Los 'scripts' de Javascript pueden ser
introducidos dentro de sus páginas de HTML. Con Javascript se puede dar respuesta a
eventos iniciados por el usuario, eventostales como la entrada de una forma o algún
enlace. Esto sucede sin ningún tipo de transmisión. De tal forma que cuando un usuario
escribe algo en una forma, noes necesario que sea transmitido hacia el servidor,
verificado y devuelto. Las entradas son verificadas por la aplicación cliente y pueden ser
transmitidas después de esto. También se puede pensar de programa que se ejecuta en
la versión cliente.
Gracias a los programas (llamados guiones) escritos en este lenguaje y embebidos en las
páginas HTML, se pueden conseguir interesantes efectos en las páginas web, comprobar
la validez de la entrada de formularios, abrir y cerrar ventanas, cambiar dinámicamente el
aspecto y los contenidos de una página, cálculos matemáticos sencillos y mucho más.
¿Qué es JavaScript?
Netscape enun esfuerzo por extender la funcionalidadde su navegador (browser),
desarrolló un lenguaje de programación que se puede colocar dentro de archivos HTML.
Originalmente fue llamado Livescript, pero después fue renombrado a JavaScript con la
idea de capitalizar la fama de Java, lenguaje desarrollado por Sun Microsystems.
JavaScript, al igual que Java o VRML, es una de las múltiples maneras que han surgido
para extender las capacidades del lenguaje HTML. AI ser la más sencilla,es por el
momento la más extendida. Antes que nada conviene aclarar un par de cosas:
1. JavaScript no es un lenguaje de programación propiamente dicho. Es un lenguaje
script u orientado a documento, como pueden ser los lenguajes de macros que
tienen muchos procesadores de texto. Nunca podrás hacer un programa con
JavaScript, tan sólo podrás mejorar tu página Web con algunas cosas sencillas
(revisión de formularios, efectos en la barra de estado, etc...) y, ahora, no tan
sencillas (animaciones usando HTML dinámico, por ejemplo).
2. JavaScript y Java son dos cosas distintas. Principalmente porque Java sí que es
un lenguaje de programación completo. LoÚnico que comparten es la misma
sintaxis.
JavaScript fue diseñado para ser un lenguaje de elaboración descripts que pudieran
incrustarse en archivos HTML. No es compilado, sino que, en vez de ello, es interpretado
por el navegador. A diferencia de Java, que primero es convertido a código de byte fácil
de interpretar, JavaScript es leído por el navegador como código fuente. Esto facilita el
aprendizaje de JavaScript mediante ejemplos, debido a que se puede ver la manera en
que otros usan JavaScript en sus páginas.
8.1 Características de JavaScript
A continuación damos algunas características importantes de este lenguaje, que es
necesario conocer antes de comenzar a utilizarlo:
JavaScript es un lenguaje de guiones
JavaScriptpuede realizar diversas tareas y funciones que le sean especificadas al
introducir sucódigo fuente dentro de los documentos HTML. De esta forma, cuando el
navegador de un usuario carga una página que contiene una serie de instrucciones como
script, el browser se encargará de encontrar los mecanismos para "correr" el programa y
ejecutar los procedimientos indicados en el guión.
La mayor parte de estos miniprogramas nose compilan, sólo se interpretan línea por línea
o instrucción, mientras que la aplicación siguesu ejecución normal. JavaScript es un
lenguaje de guiones, y su sintaxis se parece mucho a la de C, C++, Pascal o Delphi.
JavaScript esta basado en objetos
Está orientado a objetos, conuna serie de limitaciones, cuyocometido principal es
prevenir que se altere el sistema ficheros del cliente, por lo que no puede leer, escribir,
crear, borrar o listar ficheros (excepto cookies). Carece además de primitivas de red, de
manera que no puede establecer conexión directa con otras máquinas (excepto enviar
correo).
Cabe señalar que aun dada la característica del manejo de objetos, JavaScript no
comienzadesde cero, pues existe ya una biblioteca de objetos(consus
métodos
respectivos) a partir de los cuales pueden ser creados muchos otros.
JavaScript maneja eventos
Esta característica nos indica que durante el tiempo que el usuario visualice la página con
el script en cuestión, JavaScript podrá reaccionar ante cualquier evento (hacer click en un
botón, arrastrar o apuntar conel mouse, carga ydescarga de páginas, envío deun
formulario, etc.) que se le indique debido aque este lenguaje está capacitado para
detectar un sin número de eventos y reaccionar de acuerdo a como el programador lo
indique.
JavaScript es independientede la plataforma
Dado que JavaScript tiene su fundamento en Java y es interpretado por el navegador,
cualquier "script" escrito en cualquier plataforma podrá ser ejecutado en otras.
JavaScript solamentese ve limitado porla versión y el tipo de browser en el que se
ejecute.
JavaScript no es Java
Muchaspersonasno entienden la diferencia entre Javay JavaScript y generalmente
tienden a confundirlos pensando que se trata del mismo lenguaje. Java fue desarrollado
porSunMicrosystems
como un lenguaje orientado a objetos opuestoal lenguaje de
bolsillo de JavaScript cuya estructura está basada en objetos. En Java se pueden crear
m
Universidad Autónoma MetroDolitana IztaDalaDa
aplicaciones independientes para Web llamadas applets. Los applets son programas en
binario independientes dela plataforma; así a semejanza de C se compilan en forma
binaria. El applet se puede ejecutar en cualquier plataforma con la única restricción de
que se tenga elsoftware para operarlo.
Por su parte, JavaScript sólo permite manipular objetos conocidos por el navegador
(presentes en su versión de HTML).
fd#Vg$@rf@
~...,....
.:.:.:.:.:.:.:.:.:.:.:.:<
: : .,_,...,.,.,...........
: : .:.....i....i:..,.....,.....,..,
. : ~:.:.:.:.:.:.:.:.:
: ~ . : :.:.:,:,
i ::,:,:,
~ : i . i
.......................
.......... ......,..,...
,.,....,.,.,.,..,..,..
,,).(....................
i
............._.......l....
~
0
0
0
Se compila y como resultado el
compilador genera un archivo binario
que se da al cliente para su ejecución
Un applet es referenciado desde un
documento HTML, pero se transfiere al
cliente como un archivo diferente
Java requiere la declaración de
variables
la etiqueta para llamar a un applet es:
<APPLET>
las referencias a los objetos se verifican
a tiempo de compilación
0
0
0
0
0
~~~~
.
...................................
sólo se requiere un archivo de texto que
será interpretado por el browser
la codificación de los scripts se coloca
dentro del documento HTML
JavaScript no requiere la declaración de
variables
a etiquetapara
declarar un guión es:
<SCRIPT>
las referencias del objeto se verifican
durante el tiempo de ejecución
Diferencias entre Java y JavaScript
Otro concepto más que añadir a los manidos P O 0 y POE (Programación orientada a
eventos) es la Programación Orientada a Páginas WEB.
Mucho se ha escrito respecto a la programación orientada a objeto, pero indudablemente
tenemos que tener en cuenta queestamos
hablando de un concepto quesurgió
básicamente como solución para entornos de programación donde la interfaz de usuario
era algo secundario. Sin embargo, elpaso del tiempo y la implantación cada día mas
palpable del entorno Windows en el que, como su propio nombre indica, las ventanas
toman extrema importancia, los programadores nos vemos condicionados totalmente y
debemos hacer primar la interfaz sobre otros elementos de las aplicaciones.
Tal vez esta forma de conceptuar undiseñode una aplicación con PO0 sea un tanto
limitada en cuanto a que solo lo centramos en la parte visual, pero jacaso no estamos
haciendo una aplicación en un entorno gráfico?
Una aplicación hecha en entorno WEB exige el manejo de fluido e ilimitado de ventanas o
páginas. Una Página WEB lo es todo, presenta la información y permite que el usuario
pueda modificarla o crear otra nueva. Es el medio por el cual la información fluye del
cliente al servidor y viceversa.
Dicho esto, y viendo su importancia, podemos decir que la programación que hagamos
debe también enfocarse hacia la Página WEB . Veamos, a continuación, por tanto, las
cuestiones básicas que debemos saber sobre ella.
9.1 Modelo de objetos del documento
Cuando funciona en un navegador, el lenguaje JavaScript dispone de una serie de objetos
que se refieren a cosas como la ventana actual, el documento sobre el que trabajamos, o
el navegador que estamos utilizando.
La jerarquía de dichos objetos toma la siguiente forma (Figura 9.1):
Figura 9.1 Jerarquía de objetos contenidos en una página WEB
Universidad Autónoma Metropolitana lztapalapa
Para los más iniciados en la programación orientada a objetos, conviene aclarar que en
esta jerarquía, contra lo que pueda parecer, no existe herencia alguna. Los objetos se
relacionan por composición, es decir, un objeto Window se compone (entre otras cosas)
de un objeto Document, y éste a su vez se compone de diversos
objetos Form, Image,
etc..
El padre de esta jerarquía es el objeto Window, que representa una ventana de nuestro
navegador. Dado que cada marco se considera una ventana distinta, cada uno de ellos
dispone de su propio objeto Window. El objeto Document representa el documento HTML
y cada uno de los objetos que lo componen se corresponden con diversas etiquetas
HTML.
9.2 Eventos esenciales deuna PBgina WEB
Como se ha comentado, los eventos son sucesos que ocurren siempre como respuesta a
un mensaje del sistema o del usuario. Lo que significa que muchasvecesel sistema
espera una respuesta por parte del usuario. Cuando ésta se produce, por ejemplo,al
hacer click en un botón, se genera una llamada al evento que controla la pulsación del
botón, Paso seguido es que el programador decida utilizar ese evento en provecho propio
y añada código para adecuar ese evento a sus necesidades.
Lista de eventos
Un evento, comosumismonombre
indica, es algo que ocurre. Para que una rutina
nuestra se ejecute sólo cuando suceda algo extraño deberemos llamarla desde un
controlador de eventos.
Aquí tienes una pequeña guía de eventos definidos en JavaScript relacionados con una
ventana del navegador.
-.;.;.;.Ewj$&$j
......................
..............
.......
;:.:/.:.:.:..
. .
............................................
OnLoad
Ocurre cuando se abre la ventana. Terminar de cargarse una
página, se carga la página o documento
UnLoad
Ocurrecuandosecierralaventana.Salir
(descargarla), el usuario sale de la página
OnMouseOver
El ratón es colocado sobre una imagen, vínculo o ancla
OnMouseOut
El ratón salga del área que ocupa una imagen, vínculo o ancla
OnSubmit
El usuario envía un formulario
OnClick
El usuario hace click en un elemento o vínculo del documento
OnBlur
Un elemento del documento pierde el enfoque
OnChange
Cambia el texto, área de texto o el valor de un elemento
seleccionado
OnFocus
Un elemento del formulario obtiene el enfoque
OnSelect
El usuario selecciona un campo de entrada de un elemento del
formulario
<FRAMESET...>
de una página <BODY ...>
<FRAMESET... >
<A HREF..>
<AREA ...>
<A HREF..>
<AREA... >
<FORM ...>
<INPUT TYPE="button, checkbox,
link, radio"...>
<INPUT TYPE="text"...>
<TEXTAREA...>
<INPUT TYPE="text"...>
<TEXTAR EA..
.>
<INPUT TYPE="text"...>
<TEXTAREA...>
<INPUT TYPE="text"...>
<TEXTAREA...>
Para más información acerca de los eventos y propiedades de los objetos puedes leer la
guía de Netscape o consultar un manual de la referencia bibliográfica.
Validar formularios
Los formularios representan una forma rápida y eficaz de enviar información desde el
ordenador del usuario hasta el servidor web. Generalmente, constan de varios campos de
texto, botones de selección y listas desplegables, que el usuario rellena
convenientemente y transmite al servidor pulsando finalmente en un botón de envío. A
menudo, muchos de los campos que el usuario debe completar obedecen a un formato
determinado, por Io que conviene queel usuario los rellene correctamente para evitar
errores al procesar en el servidor los datos recibidos. JavaScript constituye una manera
muy conveniente de trasladar esta labor de validación de la información al ordenador del
cliente, descargando así al servidor de esta tarea.
En JavaScript, los formularios son objetos form, que dependen a suvez del objeto
document. En la Figura 9.2 se muestra la validación de un campo de texto que necesita
ser llenado.
Para mostrar como se modela una aplicación Web usando DBSP, se dará como ejemplo
el desarrollo que se realizo para crear la parte de la aplicación de Registro de
Acreditaciones, Revalidaciones y Equivalencias para el Alumno de Posgrado, para la
Oficina de CBI.
Utilizaremos, las mismas etapas de ADOO, para desarrollar esta aplicación, vistas en los
capítulos anteriores y conforme se desarrolla la aplicación veremos que elementos del
análisis cambian en la manera de interpretación e implementación usando DBSP.Daré
por hecho el desarrollo del análisis y me enfocare a la descripción de implantación.
Una delas cosas que hay que recalcar desde este momento, esquelas aplicaciones
desarrolladas con DBSP, no se apegan en cuanto a forma con el ADOO, con relación al
manejo de clases y objetos. En cuanto al fondo, es esencial tener un
ADOO,
básicamente para interpretar la estructura que va a tener nuestra aplicación.
Otro punto a recalcar es que no se va a tener una capa de negocios como tal, finalmente
como consecuencia de que DBSP es un scripting a nivel de HTML, mas sin embargo el
ADOO a nivel de clases de negocios nos sirve para interpretar, el cómo podemos manejar
estas a nivel de Scripting. Con lo anterior quiero decir que la semi capa de negocios la
manejaremos tanto a nivel de interfaz con JavaScript, como a nivel de Datos con scripts
de SQL usando las operaciones básicas que SQL maneja. Algo muy importante que hay
que decir es que siempre vamos a pensar en un modelo de tres capas donde la capa de
Negocios es la DLL. Todo esto lo podemos ver en la siguiente figura:
........,...,
..... ..:.....:...........,.............,..:.:.:
..,.,.,.,......
.:.:.:.:+:.:.:.
....
P
k
I
2.'*."'"
A,...
.';
i
ij
i
,
'L""
Objeto de
HTML +
JavaScript
Negocio
Comunicación
dbsp.dll
Objeto
de
Negocio
b
Figura 10.1 Modelo de Multicapa con notación de Objectory
Empezemos a desarrollar la aplicación:
>
$
1,
c
:
'".",S'
Objeto de
Datos
Modelo de Casos
Tenemos el siguiente usecase Registro de Acreditaciones, Revalidaciones y
Equivalencias por Alumno de Posgrado:
UC Registro de Acreditaciones, Rewlidaciones y Equivalencias
por Alumno de Posgrado
u
Registro de A R E
Asistente de
Posgrado
porAlumno
1. Dar la matricula del alumno (usuario).
2 . Extraee de la base de datos la información del alumno (sistema).
3. Mostrar el expediente del alumno (sistema).
4. Seleccionar el tipo de tramite (Acreditación, Revalidación o Equiwlencia) (usuario).
5.Seleccionar el nombre de la escuela de procedencia (usuario).
6.Seleccionar el nombre de la licenciatura anterior (usuario).
7 . Obtener de la Base de Datos las materias que corresponden al tipo de tramite
(tabla de materias equiwlentes al tipo de consulta) (sistema).
8 . Mostrar los datos del tramite y la tabla de equivalencias (sistema).
9 Seleccionar de la tabla de equivalencias las UEA's que se desean registrar (usuario).
10. Registrar la Información (sistema).
11. Generar el reporte (sistema).
E
7
Acreditaciones
Revalidaciones y
Equivalencias
El modelo de casos no se ve afectado porque las transacciones del sistema siguen siendo
las mismas, así como los actores que interactúan con el sistema.
Modelo de lnterfaz
Teniendo en mente de que nuestra aplicación será enfocada a WEB, tendríamos que
pensar en objetos de Interfaz, estableciendo las páginas HTML a las que el usuario tendrá
acceso. Esto es que, un objeto de interfaz se encargara del contenido de la Página WEB.
Este objeto enviara todo el código HTML a la maquina del cliente para que pueda
visualizar la página.
Si esta aplicación la llevaremos por ejemplo a Java (Servlets), el pensar en un objeto de
lnterfaz seria muy útil. Por ejemplo, debido a que en las pantallas se tiene el mismo fondo,
el mismo encabezado, el mismo logotipo, etc. se puede crear una clase de interfaz que
contenga estas características. Esto nos evitara que cuando se queramos cambiar una
característica de la página como el fondo, solamente lo haríamos en la clase padre y
automáticamente todos sus descendientes heredaran esta particularidad, imaginemos si
se tienen varias paginas seria muy laborioso andar cambiando cada página y se puede
caer en errores.
Aquí nos encontramos con un primer problema, una clase de Interfaz. Dado que la
manera de implementar una aplicación para WEB usando DBSP, no maneja objetos y
clases a este nivel, tenemos que pensar como interpretar esto.
~~~~~~~~
Universidad Autónoma Metropolitana lztapalapa
Para nuestra aplicación, podríamos solucionar el problema de la siguiente forma:
Pensemos que sí tenemos un objeto de interfaz, en el cual tendremos un encabezado con
el logotipo de la UAM y un titulo cualquiera, así mismo tendremos un fondo Único para
todas las paginas, así como también tipos de letra, las cuales tendrán varios tamaños y
colores. Podemos pensar que también vamos a manejar tablas, tal vez ciertos campos de
estas, irían de un color en particular como en el caso de títulos. También tendríamos
botones para tener eventos entre formularios, los cuales no necesariamente tienen que
ser como los que todos conocemos, podemos crearlos con imágenes, sombras y colores.
Todo esto lo podemos manejar a nivel de lenguaje de HTML, con Frames, CSS (Hoja de
Estilos), etc. Por ejemplo: el encabezado que propusimos anteriormente, quedaría en un
Frame, esto para que a lo largo de la aplicación siempre lo tengamos en pantalla y a nivel
de HTML solamente se interpretará una sola vez, cuando se llama a la página principal.
En el caso de los botones, tiposde letra, etc.,que mencionamos anteriormente, los
podemos tener en una hoja de estilos la cual vamos a tener a lo largo de la aplicación,
únicamente incrustando dentro del código HTML de cada pagina la referencia a esta hoja,
para generar los botones, fondos, etc.
Lamentablemente cada pagina que necesitemos dentro de la aplicación, tendrá que ser
un archivo independiente, esto es, si una página llamada “uno.html” llama a otra llamada
“dos.html”, tendremos que codificar la primera y la segunda por separado y guardarlas en
un solo directorio.
La Figura 10.1 y la Figura 10.2, muestran las características comunes en las paginas y lo
que puede cambiar en su contenido. Una página HTML puede mostrar la información que
envía el servidor, así como contener una forma para enviar datos o links para solicitar
servicios.
~~~,~~~
,,,
?:!
............................ .........<.,.,...
....:.:.:.:.
.
......
.,,,.,.,.,.,.,..
....................................
Figura 10.1 Características comunes en las paginas
En el ovalo rojo, vemos el encabezado que tendremos a lo largo de toda la aplicación y
además está dentro de un Frame. En el ovalo azul vemos que este título en especial no
cambiara a lo largo del apartado “Registro de ARE por Alumno” de la aplicación de
Gestión Escolar.
Figura 10.2 Cambia el contenido de las páginas.
:~.~,:~,:~,:~).:~*:~,:
..................................
,)$))$;A
~~~~~~~~~~~~
&!!J!!h
Universidad Autónoma Metropolitana lztapalapa
~
...,,....A.
: . .,., A...A.>~
.......
Modelo de Dominiode Problema
Tenemos el siguiente diagrama:
I
W v e U E A : Integer
W o m b r e U E A : String
@Creditos : Integer
HorasTeoria : Double
HorasPractica : Double
I'
I
I
cAlurnno
I
W a t r i c u l a : Integer
@Nombre : String
@Nombrecarrera : String
W v e c a r r e r a : integer
@Estado : Integer
WveAreaConcentracion : Integer
WreditosAcumuiados : Integer
cCarrera
.
cPlandeEsludio
-vecarrera
: Integer
UEA : cUEA
@T¡POUEA : String
@Trimestre : Integer
"
"
1
W v e c a r r e r a : Integer
rL
ARE = Acreditaciones,
Revalidaciones y. Equivalencias
.
-
J
"--
Figura 10.3. Diagrama de Dominio. Relaciones entre clases
Daré por hecho el análisisquecondujoal
consultar el Capítulo 4 de este documento.
WscuelaProcedencia : String
&icenciaturahterior
: String
&veUEA
: integer
m a t e r i a :String
I
diagrama anterior, si se presentan dudas
La definición de las clases estáticasno sufre cambios debido a que los objetos de
información son los mismos y sus relaciones también son las mismas. Esta parte no
cambia la manera en que se implantará la aplicación con DBSP. Porque si recordamos
que a partir de este modelo se obtendrd la estructura de la base de datos, por lo tanto la
implantación de la base dedatos tampoco sufrirá cambios. DBSP no tiene que ver
directamente con la implantación de la Base de Datos, únicamente la utiliza para generar
Query's a ella. Por lo tanto, esta parte del análisis queda totalmente transparente al
implementar posteriormente la aplicación con DBSP.
Modelo de Análisis Dinámico
En este modelo se establecen las principales interacciones entre los objetos dinámicos,
entonces veamos como se desarrolla el Modelo de Análisis dinámico.
Escenarios
1. Se ingresa la matricula del Alumno“952 13148”.
2. Se selecciona el tipo de tramite “Acreditación”.
3. Se captura el nombre de la escuela “UNAM”.
4. Se captura el nombre del Posgrado o Doctorado anterior “Posgradoen Matemáticas”
5 . Se captura el Registro ARE :
Mecánica y Fluidos - Física I
Introducción a las Ciencias de la Computación - Informática I
Cálculo Diferencial - Matemáticas I
6. Se registra la información “Aceptar”.
El Análisis de escenarios se mantienen sin cambios porque se definen a partir de los
uses cases y éstos no fueron modificados, por lo tanto se tendrán los mismos escenarios.
Diagrama de Colaboración
Tenemos el siguiente diagrama:
11 Capturar Historlco ARE +OK
”-3
2, ValMatncula(rnatrlcula)
oNAlunno
1: OK
A
.I
olHistoricoARE
1
1
3: getPlurnno(rnatricula)
-.
Y
I owlurnno
I
4- getPlandeEsbdb(C\eCarrera)
ti
I
Aslstente de
Posarado
5 getUE&CwUEA)
j
.
Estujio
I
6 getTipoTrarnlte()
7 Selecclonar Unlwmdad de Procedencla
9 Selecclonar Posgrado M e n o r
12 regTipoTrarnIte(rnatr,UniProc,PosPnt.HistLIRE)
8. getUnivF‘rocedencta(TipoTrarnite,CveCarrera)
10 getUnlvPnteria(TipoTrarnLe,CwCarrera,Escfrocedencia)
13. setTlpoTrarnIte(malr.UnIvProc,PosPnt,HlstPRE)
olFinHistoricoARE
oNMaterlaAR
+
Figura 10.4 Diagrama de Colaboración de una aplicación hecha para el WEB
oDMateria
ARE
Podemos ver que en el diagrama anterior existen objetos que no habíamos planteado,
estos son: olHistoricoARE, oNMateriaARE y oDMateriaARE. Estos objetos pertenecen a
otro apartado de la aplicación, pero explicare un poco acerca de ellos.
Dentro de la aplicación, existe un catalogo de materias por así decirlo, cuando un alumno
se le va a aplicar algún tipo de tramite, ( Lo que estamos trabajando en este momento),
debe de haber información acerca de las materias que son equivalentes para el tipo de
Trámite, esto con un vínculo entre el Posgrado o Doctorado en el que esta inscrito
actualmente el alumno en la UAM y la Universidad de Procedencia en la cual el alumno
cursaba un posgrado o doctorado Por este motivo existe un catalogo, en donde se guarda
la información necesaria para llevar a cabo un trámite en particular sobre el alumno. En el
caso de que no exista información, el usuario tendrá que crear un catalogo con los datos
requeridos.
Como ya había mencionado al principio de este capítulo, no vamos a tener una capa de
Negocios. En el diagrama anterior se ven claramente, cuales objetos son los de negocio,
lo que querría decir que tendríamos que implementar algún tipode código, tanto para
conectamos a las Bases de Datos, como para hacer los GETS y los SETS, entre muchas
otras cosas más.
Si utilizáramos Java (Servlets), tendríamos que crear clasesque nos permitieran hacer
esto, así como también podríamos ver esta aplicación como una aplicación Multicapa, en
donde los Servlets llaman a estas clases de Negocios para mandar y recibir información
de la Base de Datos, así como también establecer las conexiones necesarias, y hacer
algunas operaciones mas.
Entendamos esto, porque creo que es importante, para entender como implementar esto
mismo con DBSP. Los objetos de interfaz son páginas HTML que envían la información a
un servlet; éste recibe la información y llama a los objetos de negocio para validar la
información; a su vez los objetos de negocio llaman a los objetos de datos para solicitar
datos y devolverlos al servlet. Finalmente el servlet envía una página HTML al usuario con
la información correspondiente al servicio solicitado
Con el siguiente Diagrama obtendremos la solución a este problema.
Diagrama de Clases Dinámicas
clRegistrarAlm noARE
cNAlurnno
1
____
.
%pen()
+envlarPaglna()
*<<event>> capturarMatrlcula()
*<<event>> selTlpoTrarnIte()
*<<event>> reglstraro
+close()
*<<event>> flnlsh()
j
i
1
t
cDAlurnno
- "
"
/
1
"
"
"
2
"
i
cNPlandeEstudio
\
"
"
\
cDUEA
QtgetPlandeEstudio()
\
\
,
\
\
\
clFinRegistrarAlurnnoARE
*Post()
*enuarPagina()
*<<event>> O K 0
*Destroy0
cNMateriaARE
%alDatos()
*RegistrarMaterlaARE()
"
I
Figura 10.5 Diagrama de Clases Dinámicas de una aplicación hecha para el WEB
Para empezar, como podemos observar a nivel de Interfaz, se trata únicamente de una
pagina HTML, la cual tieneeventosyoperaciones
de abrirycerrar. ¿Cómo podemos
interpretar esto, sin pensar ahora en una Clase o Objeto?, Simplemente como una pagina
otra, estoutilizando la capa
HTML individual y conatributosúnicos,lacualllamaa
los Servlets. Pero no hay capa de negocios,
negocios de conexión, como en el caso de
aquí es donde entra DBSP.
Dpsp.dll, se encargaenprimer
lugardehacer
las conexiones necesarias tanto del
usuario, como a la BasedeDatos,estodesdeque
el usuariohace una petición.Así
mismo se crea una Sesión de usuario, además esta sesión queda registrada a nivel del
cliente (Maquina del Cliente) y no a nivel del servidor, cada vez queel usuario pide alguna
pagina, dpsp.dll verifica si esta en sesión, si lo esta le da servicio, en caso contrario le
dice que no le puede dar servicio hasta que entre en una nueva sesión. Por consiguiente,
se le puede prestar el servicio a varios usuarios ala vez.
Despuésque hacemos con lacapa de negocios?,ennuestrocasocon
la clasede
negocios Alumno, Plan de Estudios y MateriaARE.
Si observamos cada clase tiene métodos como get, set, registrar, etc., estos métodos se
transformaran directamente en lenguaje SQL en forma de Query’s, que quedaran dentro
de la Base de Datos, con delimitadores especiales para que cuando se requiera DBSP,
los busque, los ejecute y genere una respuesta.
Básicamente lo que hace DBSP es leer lo que el usuario solicita, establecer la conexión
con la Base de Datos, ejecutar una instrucción (Query) y regresar una respuesta.
¿Pero dónde quedan las validacionesylasoperacionesesenciales?,Estasquedana
y para operacionesmáscomplejas,seutilizan
nivel de HTML, usandoJavaScript,
directamente sobre la Base de Datos, Scripts de SQL. Mas adelante, todo esto quedara
aclarado, cuando implementemos esta parte de la aplicación.
Primero acabemos de hacer el ADOO.
Diagrama de Secuencia
El diagrama de secuencia es equivalente con el diagrama de colaboración. En la siguiente
Figura, se muestra la ejecuciónpasoapaso
del escenario de RegistrodeAREpor
alumno.
P
]
i
.
.
.
1
1
OlFlnHistorlco
oNMateriaA
L
Aslstente de
I
I
1
I
I
I
I
I
I
5
i
I
I
I
rera)
gyUEA(CveUEq)
I
I
I
I
/I
I
I
I
I
I
Selecclonar Edcuela de Proceddncla
'
getEscPrbcedencia(TipdTrarnite,CveC&rera)
I
-.,
I
I
I
I
I
I
I
I
I
I
I
I
-. EscProceden 9 ia)
getPosAnprior(TipoTralite,CveCarrera
I
I
I
I
+
9CaqturarHlstorlco
ATE
I
I
OK
I
I
1
I
regTipoTrarn]te(rnatr,EscProc,~icAnt,H~stARE)
1
I
I
I
setTipoT/arnlte(rnatr.EsjcProc.LicAnt.H+tE)
I
I
I
I
Post(Ur0
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
1
I
I
I
I
I
I
I
I
I
I
I
I
I
getTipoTrarnite0
d
getPlandefstudlo(CveCa
ii
I
I
I
I
I
I
U
P
OK
'
I
-
/
Y
I
Figura 10.6 Diagrama de Secuencia de una aplicación hecha en el WEB
Diagrama de Componentes
Si establecemos la estructura de paquetes agrupados por temas, añadiremos un nuevo
paquete que contiene DBSPque serán utilizados por el sistema, en la Figura 9.13 se
muestra la estructura y sus dependencias.
> LI
U
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
DBSP.dl1
Alumno
F
I
I
J
v
Registro de AREi
/
Plan de Estudio
..
\
UEA
->E
MateriaARE
\
\
\
\
Figura 10.7 Estructura de paquetes de una aplicación para elWEB
10.2 Ejemplo de Implementación usandoDBSP:
El afán de esta parte de documento es presentar de una manera muy general como se
implanta una aplicación con DBSP, no profundizaremos en como funciona DBSP a nivel
de software y en donde se realizan los Query's para generar las consultas. Así como
también no profundizaremos sobre código de HTML y JavaScript, si el lector le surgiese
alguna duda, por favor utilice las referencias Bibliográficas, mencionadas al final del
presente documento.
Antes de empezar a implementaresta aplicación, hay que mencionar cómo DBSP se va a
comunicar entre pagina y pagina, esto quiere decir que habrá alguna manera de
comunicarse. Se tiene el siguiente URL:
http:// hosffalias de la aplicación/dpsp.dll/page?doc=
(parámetros)
En donde
Host = Dirección ip del Servidor.
Alias = nombre de la aplicación usando el BDE, este último contendrá la dirección física
de la Base de Datos.
Dbsp.dll = Dynamic link language
Page?doc = Parámetro quesirve para crear un vínculo entre paginas.
Parámetros = Manejo tanto de html's como de carpetas en donde estarán los archivos.
Ejemplo:
http://l27.0.0.1/POSGRADO/dbsp.dll/pane?doc=comun\Principal.html
Tenemos la siguiente página con la cual comenzaremos nuestro análisis:
Código HTML dela Página anterior, únicamentese presentará aquel código que sirva
para mostrar como funciona DBSP, para ver todo el código consulte la aplicación:
<html>
<head>
HOJA DE ESTlLOS
...
</head><body bgcolor="#FFFFFF" text="#000000" class="fondo">
<title>Untitled Document</title>
~#K~~~~K~:E~I;~NAME~~~~GRAM;~A~R~~ORIB
'. ..~....~
... .K
. .....i. .-. ..~
....C
.. ..o
....a
.. ...K
.....I..E
.., ..,. .~
....~
....M
, . ....
E....~
..., .E
....S C
, ., ..U
, ....~
.....t..A
.... .P R Q G E D E N C l ~ ~
...
....... .......... .............. ... . ..... . ......................... ... ..... . . . . . . . ...... ........ . ..
,
.....
</body>
</html>
En el código anterior se pueden observar etiquetas llamadas KILLCOOKIE, la explicación
de cómo funcionan estas se verá posteriormente
........
. ......
. .......................
.(~:,.,.,..’..,..’.
.. .. . ... .. .........
. ...... .,.,. ::.,.::.:.:.:....:.:..:.:.:.:::.:.:.::.....\........ .
:....:.:.:............/..:... .................
Este ultimo link, parece un poco
raro (%a
~ d o ~ = d .r r s ~ ~ A ~
. .b
.. ... ..~
. .. .. ~
... . . ~.. : ..i.. ....p
........a
.......~
.. . ~
... . . .... ......... . . .. .. . .. ..........
Esta es la manera en queDBSP se va a comunicar entre paginas.
La página anteriormente mostrada, es un menú con varias opciones que tendrá nuestra
aplicación, cada opción ejecuta un parte del total de la aplicación.
Como ya habíamos mencionado,el usuario tendrá que crear una Sesión, utilizando un
nombre de usuario y un password. Estandoen sesión el usuario podrá moverse alo largo
y a lo ancho de la aplicación.
AI oprimir el link de “REGISTRO DE ARE POR ALUMNO”, pasaremos a esta parte del
sistema y el URL se vería de la Siguiente manera:
,,
,, ,
,
....,....I../.....
,
Donde aAREcapalmas.htm1 es la siguiente
pagina.
,
En esta pagina ya entramos al Registro de Acreditaciones, Revalidaciones y
Equivalencias por Alumno.
Analicemos el Código de la Página:
.. .. ... .. ..
..............
.............
.........
..?:...:.j::.:.$
.......
: :
: ~ ~ J ~ ~ R i p ~ ~ :
:.:.:.:: ............:..:...................
<link rel="stylesheet"href="../styles/styles.css"
type="text/css">
</head>
Veamos el código del a siguiente pagina, no se mostrara la pagina como interfaz:
htmb
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="texUhtml; charset=iso-8859-1">
clink rel="stylesheet"href="../../styles/styles.css"
type="textfcss">
<table width="64%" border="O" height="36" class="fondoprin" align="center">
<tP
<td>
ediv align="center">
cp><span class="headtabletxt"> Acreditaciones, Revalidaciones </span><span
class="headtabletxt">
y Equivalencias por Alumno<br>
</span></p>
</div>
<Ad>
</tP
</table>
<bP
<table width="31%" border="O">
<tP
<td><b>EXPEDIENTEDEL ALUMNO:</b></td>
</tP
</table>
<hr>
*,~~&~:wi&f@Ifjji,
%:..:bfrr4iiw;:o:~
J;:
.............
.....
*#DATASET A~€AS=P.OSORADOI.O~~ERY~D~:~:~~
ETIQUETA DATASET
<tP
<td class="tabledata2"width="l4%" height="29">
cdiv align="right">Nombre:</div>
<td class="tabledata2" width="14%" height="28">
cdiv align="right">Matrícula:</div>
....
<i j
~
~
~
L~g~tta3w$$$$
~ ..........................
~
~
.......~ ::.:::.:::
. . ..::.,,:~...
::.:::,:,:::.:
...~...
::. i.: ’: ...:....:.:i ..........................................................................................................................
...............................
~
También el elementoDATASET se encarga de traer los elementos de la consulta que le
solicitamos, y ponerlos dentro del código HTML, en forma de etiquetas, las cuales son
generalmente, los campos que le estarnos solicitando en la consulta.
Para mayor información sobre estas etiquetas ver la ayuda de DBSP.
APOSGRADO.APMATERN0,
APOSGRADO.NOMBRE,
APOSGRADO.MATRICULA,
CARRERA.CVECARRERA,
CARRERA.NOMBRECARRERA
FROM APOSGRAD0,CARRERA
WHERE APOSGRADO.MATRICULA=:MATRICULA
AND
APOSGRADO.CVECARRERA=CARRERA.CVECARRERA
AND
APOSGRADO.MATRICULA IN (SELECT MATRICULA
FROM ALUMNOMATERIA-ARE)
-
Si el DATASET encuentra información sobre esta matrícula, regresa la información
que se le solicito con la consulta, y genera un aviso al Usuario de que este alumno
ya se le había hecho un trámite anteriormente
- Si al alumno ya se le ha realizado un trámite previamente, se da la opción de
. .. . . . . volver a generarotro trámite, borrando el anterior.
.....................................................
...
*::::.:.:::::Si
el DATASET, no
encuentra información, redirección a otra pagina, para
................
<#REDIRECT
DOC="docs\aAREcapalmasdat.html">
La pagina siguiente es: aAREcapalmasdat.htm1 que a continuación se muestra:
pagina="page?doc=docs\\InGes.html";
document.location.replace(pagina);
1
</script>
clink rel="stylesheet"href="../styIes/styles.css"
type="text/css">
</head>
<body bgcoloc-r"#FFFFFF"text="#000000" class="fondo">
<#SETCOOKIE NAME="MATRICULA" EXPRESSION="txtMATRICULA">
CbP
ctable width="73%"border="O" height="36" class="fondoprin" align="center">
....
</table>
<br>
<table width="23%" border="O" class="tablefield">
CtP
<td><b>Expediente del Alurnno:</b></td>
</tP
</table>
ChP
<table width="63%" border="O">
gmATA&T
AttAS&pOSG.qADO:QuERYIw:$2>
..............................................................................
. . ... . . .. . . ... . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
.
<tP
<td class="tabledata2" width="14%" height="29">
cdiv align="right">Nombre:c/div>
c/td>
................................................................................................................................................................
.......................................
~
~
~
~
~
d
s
j
~ ................................................................................
~
n
f
~
~
~
~
~
.....................................................................................................................................................................................
:@N:~M~R~&&&~&
..........................
.................................
..........
!:;+ifp
...
.....
............
............
~
~
~
~
'
'
<td width="66%" height="45" class="tablefield">
<div alian="left">
¿Qué hace esta pagina? :
Primero se verifica que el alumno exista, cómo pero si ya lo verificamos?, No hemos
verificado que el alumno exista en nuestra base de datos, únicamente verificamos que no
existiera un Tramite hecho anteriormente sobre este Alumno.
Por supuesto ahora vemos que el diagrama deClases expuesto anteriormente empieza a
verse en la practica. Tenemos hasta este momento, una tabla dentro de la Base de Datos,
que la vamos a utilizar para registrar todos los tramites que se realizan, pero también
vamos a tener una tabla que guarda a todos los alumnos inscritos en la UAM a nivel de
Posgrado y Doctorado.
Así como también tendremos una tabla, la cual es un catalogo de Materias, creado con
anterioridad para determinar que materias vamos a Revalidaro Equivaler, o Acreditar,
para un Trámite en específico. Estas son las famosas Clases que obtuvimos alrealizar el
ADOO, entre muchas otras más.
Podríamos pensarque es ilógico pensar que si al alumnoya aparece con un Trámite no
exista dentro de la tabla Alumnos. Entonces para que validar tantas veces lo mismo.
No, no es validar tantas veces lo mismo. Estamos tratando de llevar a la práctica la
famosa capa de Negocios (control).
Notemos algo: En la página anterior, se verificó que no existiera un Trámite sobre este
alumno. Como no existió algún trámite, no podemos asegurar en este momento que el
alumno exista dentro de la Tabla Alumnos, lo que sí sabemos es que a este alumno no se
le ha aplicado un Tramite, entonces el sistema nos manda a esta pagina, para verificar
ahora sí, la existencia de este alumno.
Si el alumno existe, proseguimos con la aplicación.
En el caso de que en la página anterior, existiese un Trámite sobre este alumno, es lógico
que el alumno existe en la Base de Datos. Entonces en este momento el sistema nos da
la opción de volver a hacer el trámite o dejarlo como estaba. Pero no nos deja proseguir
con la aplicación hasta que tomemos una decisión.
Pasos que realiza la página:
-
Se realiza una consulta por medio del DATASET, utilizando el valor de la matrícula
guardada en la COOKIE MATRICULA
<#DATASET ALIAS=POSGRADO
QUERYID=12>
El código de la Consulta de SQL es el siguiente:
SELECT APOSGRADO.APPATERN0,
APOSGRADO.APMATERN0,
APOSGRADO.NOMBRE,
APOSGRADO.MATRlCULA,
CARRERA.CVECARRERA,
CARRERA.NOMBRECARRERA
FROM APOSGRAD0,CARRERA
WHERE APOSGRADO.MATRICULA=:MATRICULAAND
APOSGRADO.CVECARRERA=CARRERA.CVECARRERA
-
Si existe este alumno, el DATASET, trae los datos que le solicitamos y los pone en
la pagina.(Expediente del Alumno).
I <td class="tabledata2" width="14%" heiaht="29">
1
cdiv align="right">Nombre:</div>
</td>
..................
ctd class="tablefield"
width="86%"
height="29"~js~~PATERNa,~
..........................
~ A P M A T E ~ ~ . .~. . . .~. . . ~ # N ~ M ~ ~ E ~ < ~ d >
...
<div align="right">Matrícula:</div>
<td class=lltablefieldtlw ~ ~ ~ ~ ~ l
</tP
CtP
l
~
~
O
/
o
....................................
.......................................
<td class="tabledata2" width="l4%" height="30">
<div align="right">Carrera:</div>
ctd
class="tablefield" width="86%" height="30">
zrWNOMBREGARRERA
. .............................................
. . . . . . . . .
...........>c/td>
</tP
l
l
~
e
~
g
~
~
~
l
l
<,,z'l l d ! ~ ~ ~ e ~ e r , , = a f j e nld!JZS>
6uel
:.............
.................
" : : : : : : : : : : : :
..............
*t::::.:.:.:';:.:.:.:.:
...............................
~ ~ ~ ~ ~ ~ ~ r s ~ ~ ~ : ~ ~ , ~ ~ ~ ~ ~ ~
.....:.:.,.:..:.:.:::.:
#-.:..:.:.:<.: ::.....:.:.:.;::*$
3ed
3
-
La siguiente pagina es: "aAREcapalmasdat1.html":
El código HTML de la pagina:
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
clink rel="stylesheet" href="../../styles/styles.css"
type="text/css">
<script language="JavaScriptl.2"src="../public/dbsp.js"></SCRIPT>
<script language="JavaScriptl.2">
function Inicio0 {
pagina="page?doc=docs\\lnGes.html";
document.location.replace(pagina);
1
</script>
clink rel="stylesheet" href="../styles/styles. css"type="te:N
</head>
....
<td width="58%"><b>Datos del Alumno:</b></td>
C,SS">
..................
<PI/>
<A!p/>:aJqLuON~~,l~6U,,=U6!le
A!P>
<,,6Zll=146!a4 ,,%6,,=4lP!M ,,Z~WPalq~l,,=s~W
PI>
a >
~
. . . . . . .~
.
~ - ~ r ~ ~ ~ n # ~ ~ ~ ~ ~
....................................
<uOto=JaPJoq
u%P6u=4lP!M
al4el>
~~*:~38.~Ntsi:ss~~~d~
......................................................................................................................................
VH33=r
:''':3yuw
3,:xm13$&
....................................................................................................................
............................................................................................................
.................
....................................................
w.:..:,...::. ..::....::...e=
.: .::..L..:.. j:.:.;:
.........................
..............8
<#KILLCOOKIE NAME="sindatos">
</form>
</body>
</html>
¿Qué hace esta página? :
Primero se guardan en Cookies el Tipo de Tramite, Clave de la Carrera y la Fecha
de Inicio del Trámite generados en la pagina anterior.
<#SETCOOKIE NAME="TIPOTRAMITE"
EXPRESSION="selTIPOTRAMITE"~
<#SETCOOKIE NAME="CVECARRERA"
EXPRESSION="selCVECARRERA">
<#SETCOOKIE NAME="FECHA" EXPRESSION="txtFECHA">
Para evitar guardar todos los datos del Expediente del Alumno, se vuelve a
generar la misma consulta por medio del DATASET sobre la matricula del Alumno
guardada en la Cookie.
<#DATASET ALIAS=POSGRADO QUERYID=12>
1
I
El DATASET genera la consulta y pone en la pagina el expediente del Alumno
El dato del Trámite también se pone en la pagina para referencia.
El sistema solicita que se seleccione una Universidad de Procedencia, esto quiere
decir que el Usuario debe escoger del Campo de Selección, la universidad de la
que provenga el alumno.
Aquí pasan dos cosas:
- El sistema hace una consulta por medio de otro DATASET, para traer todas las
Universidades guardadas en el Catalogo de Materias, que coincidan tanto con la
Carrera inscrita del Alumno, como el Tipo de Tramite que se quiere realizar.
<#DATASET ALIAS="POSGRADO" QUERYID=13>
<select name="selESCUElAPROCEDENClA~~~
<#QRYLlST FIELDTEXT="ESCUELAPROCEDENCIA"
VALUE="ESCUELAPROCEDENCIA">
El código en SQL es el siguiente:
SELECT DISTINCT
ESCUELAPROCEDENCIA
FROM MATERIA-ARE
WHERE
TIPOTRAMITE= :selTIPOTRAMlTE AND
CVECARRERA= :selCVECARRERA
-Si el Usuario no encontró la Universidad que requiere, dentro de Campo de
Selección. El usuario tendrá que salir de Registro deARE por Alumno y Generar
una entrada en el Catalogo de materias, usando los mismos datos que están
siendo utilizados en este momento con respecto al Tipo de Tramite y el de la
Carrera inscrita del Alumno, asi como también de la Universidad de Procedencia
y Posgrado o Doctorado Anterior.
-Si el Sistema no encontró alguna Universidad que cumpla con las condiciones del
-
Tipo de Trámite y Carrera Inscrita. Desplegara el sistema un mensaje, el cual
avisará al Usuario de que no existen Universidades bajo esas condiciones,
entonces el Usuario tendrá que Generar un registro en el Catálogo, como
anteriormente se mencionó.
Si el usuario encontró en el campode Selección, la Universidad que estaba
buscando, simplemente la selecciona y oprime el Botón ACEPTAR para proseguir
con la aplicación.
El evento que genera el Botón es llamar directamente a la pagina siguiente
llevándose consigo el valor del campo de selección, que no es mas que el nombre
de la Universidad de procedencia. ( "selESCUELAPROCEDENCIA")
<form name="form" method="post"
action="page?doc=docs\aAREcapalmasdat2.htmltt>
La siguiente pagina es aAREcapalmasdat2.htmI
Datos &A
.a?mUn3,0:
x)iitw fie8 Tr&n$Ss$a R . d k W ;
.......................................................................................................................................................................................................................................................
El desarrollo de esta página es casi igual que la Anterior. Esta pagina lo que hace es
mostrar los Posgrados o Doctorados que cumplen con las condiciones del tipo de tramite,
y la Escuela de procedencia, utilizadas anteriormente. El comportamiento de esta página
en cuanto a las Consultas y las condiciones de los DATASETS, son los mismos que los
utilizados en la pagina anterior.
En esta página, se guarda en una Cookie el valor obtenido de la pagina anterior con
respecto a la Escuela de Procedencia y se actualiza esta pantalla con esta información,
como lo podemos ver en la figura.
Finalmente la siguiente pagina que produce esta pagina es: aAREcapalmasdat3.htmll que
a continuación se muestra.
Veamos su código en HTML:
chtrnb
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="texVhtml; charset=iso-8859-1">
clink rel="stylesheet" href="../styles/styles.css"
type="text/css">
cscript language="JavaScriptl.2"
src="../public/dbsp.js">c/SCRlPT>
<script language="JavaScriptl.2">
function Valida0 {
var ID = RevisaSeleccion(document.Forma,"Debe
seleccionar una materia!");
if (ID!=") {
pagina="page?doc=docs\\aAREcapalmasdat4.html&CVEUEA="+lD;
document.Forma.action=pagina
document.Forma.submit0;
1
1
function ImprimirO{
pagina="page?doc=docs\\lmprimiraAREcapalmasdat.html";
document.Forma.action=pagina
document.Forma.submit0;
1
function Inicio0{
pagina="page?doc=docs\\lnGes.html";
document.location.replace(pagina);
1
</script>
....
cbody bgcolot="#FFFFFF"text="#000000" class="fondo">
...
CtP
ctd width="48%"><b>Datosdel Alumno</b>cRd>
ctd width="52%">cb> Datos del TrámiteRealizaW/bWtd>
a
C/tP
</table>
chr>
........................
:. . .;.:.:.:.A:.:.:...,:.........:............:....?. .. ,.::...:..:
.................
~~~~~~K~:~~~~~ME=*P~~~RA~UAN~RI~~~~EXPR.ESS€
ctable width="lOO%"bordet="O">
~
~ ~ ~ ~ ~ ~ : r l : ~ ~ f ~ ~ = p ~ ~ ~ ~ ~ ~ ~ a t f ~ ~ r
.................................................
CtP
ctd class="tabledata2" width="9%" height="35">
cdiv align="right">Nombre:c/div>
</td>
."
<td class="tablefield"~ i d t h = " 3 6h~ ~
e "i g h t = l 1 3 5 ' ' = c ~ # A F F E R ~ ~ ~ ~ A ~ M ~ ~ E R ~ ~
*NQMBRE$.?&g$g
................................................................................................
........................................
.....................................
ctd class="tabledata2" width="27%" height="35">
cdiv align="right">Tipode Trámite:c/div>
ctd class="tablefield"
C/tP
......................................................
hwidth="28%"
e i g h t = ".................................................
35''=c~~POT~~]VES.~~d>
CtP
ctd class="tabledataZ" width="9%" height="28">
cdiv align="right">Matrícula:c/div>
c/td>
<td class="tablefield"~ i d t h = " 3 6height="28l'S~~~~~RfC,WfA></td>
~~"
........................................
ctd class="tabledata2" width="27%" height="28">
cdiv align="right">Escuela de Procedencia:c/div>
<Ad>
height=ll28'l~~E~~C;UE~~~~E~EN~~A~</td>
<td class=lltablefieldll width=l1280/oll
4tP
..............
. .
CtP
ctd class="tabledata2" width="9%" height="35">
cdiv align="right">Carrera:c/div>
ctd class="tabledata2" width="27%" height="35">
cdiv align="right">Posgradoo Doctorado Anterior:c/div>
</td>
...........................................................
ctd class="tablefield" width="28%"h e i g h t = " 3 5 ' ~ ~ P 9 s ~ : ~ ~ A ~ ~ ~ ~ l ~ ~ ~ ~ d
</tP
.............................................
.................................
..............
z#@/&TA5,FF"T,
</table>
<hr>
<table width="99%" border="O">
<tP
ctd width="34%" height="2">cfontcolot="#OOOOOO">Seleccionela UEA y registre
</p>
<#KILLCOOKIE NAME="sindatos">
</form>
</body>
¿Qué hace esta pagina? :
-
-
Hasta el momento tenemos 5 COOKIES guardadas en el sistema, las cuales son:
Matricula, Tipo de Trámite, Universidad de Procedencia y Cve de la Carrera del
alumno al cual se le esta aplicando el trámite. En esta pagina se guarda en una
cookie el valor que nos pasa la página anterior, el cual es el Posgrado o
Doctorado Anterior. Finalmente vamos a tener 5 Cookies activas.
Como en las páginas anteriores, se hace una consulta por medio de un DATASET
para generar el expediente del alumno y ponerlo en la página, utilizando
únicamente la matrícula del alumno, que esta guardada en la Cookie matrícula.
Ya con todos estos valores guardados, el sistema genera la consulta final, que se
encarga de traer todas las materias ya pareadas del Catalogo de Materias
(cMateriaARE), que cumplan con las condiciones guardadas. Esto es, se
generará una consulta por medio del DATASET, con los siguientes valores:
Cve de la Carrera: l=Posgrado en Física.
Tipo de Trámite: Acreditación.
Escuela de Procedencia: UAM
Posgrado o Doctorado Anterior: Posgrado en Matemáticas
<#DATASET ALIAS=POSGRADO QUERYlD=lI
FULLSET>
;odigo del query en SQL:
SELECT
PLANDEESTUDIOS.CVECARRERA,
PLANDEESTUDIOS.CVEUEA,
PLANDEESTUDIOS.OBL-OPT,
PLANDEESTUDIOS.TRIMESTRE,
UEA.NOMBREUEA,
UEA.NUMCREDITOS,
MATERIA-ARE.MATERlA
'ROM
PLANDEESTUDIOS, UEA,MATERIA-ARE
UHERE
PLANDEESTUDIOS.CVECARRERA= :CVECARRERA AND
PLANDEESTUD1OS.CVEUEA= UEA.CVEUEA AND
PLANDEESTUDI0S.CVEUEA =MATERIA-ARE.CVEUEA AND
MATERIA-ARE.TIPOTRAMITE = :TIPOTRAMITEAND
MATERIA-ARE.ESCUELAPROCEDENClA= :ESCUELAPROCEDENCIA AND
MATERIA-ARE.POSGRADOANTERlOR = :POSGRADOANTERIOR AND
PLANDEESTUDIOS.CVEUEA NOT IN (SELECT CVEUEA FROM
ALUMNOMATERIA-ARE
WHERE
TIPOTRAMITE= :TIPOTRAMITE AND
ESCUELAPROCEDENCIA= :ESCUELAPROCEDENCIAAND
POSGRADOANTERIOR= :POSGRADOANTERIORAND
MATRICULA= :MATRICULA)
ORDER BY
PlANDEESTUDIOS.OBL-OPT;
I
I
El resultado de esta consulta es puesta en la página para mostrar toda esta
información.
<td class="tablefield" width="4%">
<input type="radio" name="rb" value="<#CVEUEA>">
</td>
<td class="tablefield" width="12%" ><#CVEUEA></td>
<td class="tablefield" width="l7%" ><#NOMBREUEA></td>
<td class="tablefield" width="l9%" ><#NUMCREDITOS></td>
<td class="tablefield" width="13%" ><#OBL OPT></td>
<td class="tablefield" width="l5%" ><#TRIfiESTRE></td>
<td class="tablefield" width="2O0/~"><#MATERIA></td>
<td class="tablefield" width="20%" ><a href=Y#opcion">opcion</aWtd>
<INPUT TYPE="HIDDEN" VALUE="<#MATERIA>" NAME="MATERIA">
</tr>
-
-
Ya que tenemos toda la información necesaria en pantalla, el Usuario tendrá que
seleccionar aquellas materias que necesite, lamentablemente no podrá
seleccionarlas todas de un solo golpe. Únicamente podrá seleccionar y registrar
una materia de vez en vez.
Cuando el usuario seleccione una materia, el acto seguido será oprimir el Botón
"REGISTRAR", el cual llamara a un JavaScript validando la selección. Este
JavaScript, llevara la información de la materia seleccionada a otra pagina. Esta
pagina tiene como única función registrar la materia seleccionada, junto con la
matrícula del alumno y la fecha del Trámite en la tabla AlumnoMateriaARE
(cAlumnoMateriaARE), la cual se encarga de guardar todos los registros de
Trámites de ARE.
<input type="button" name="Button" value="REGISTRAR"
onClick="Valida()">
<script language="JavaScriptl.2">
function Valida() {
var ID = RevisaSeleccion(document.Forma,"Debeseleccionar una
materia!");
if (ID!=") {
p
a
g
~
n
a
~
.
l .. . .l .
........ .:..... ...
. ....,,........
document.Forma.action=pagina
document.Forma.submit();
1
. . .. p
. ....... ...a
...... .....g
.. .. . . .. .e
. ... ..... ..~
... ..
.................... ... ... ... .. . ...................... ..
~
... ...
.. .............
o
c
~
~
o
c
El Query de SQL que se utiliza es el siguiente:
INSERT INTO ALUMNOMATERIA-ARE VALUES(:MATRICULA,
:CVECARRERA,
:TIPOTRAMITE,
:ESCUELAPROCEDENCIA,
:POSGRADOANTERIOR,
:MATERIA,
:CVEUEA,
:FECHA)
-
Si el usuario, ha acabado de seleccionar las materias que necesita para el trámite,
a lo mejor querrá imprimirlas, entonces únicamente tendrá que oprimir el botón "IR
A IMPRESIóN", el cual ejecutara otro JavaScript, que mandará llamar a otra
pagina, la cual contendrá el Expediente del Alumno y todas las materias que se
registraron.
<input type="button" name="Submit3" vaIue="lR A IMPRESION"
onClick="lmprimir()">
function Imprimir(){
. . .. . .. .. . .. ... .. ..... ..
pagina="page?doc=docs~~l~~~;~~~RE~p~~~~~~a~,h~:l11
. . . ..... . ............... ............... .. . . . . . .. ... ............ ..... . . . . . .
document.Forma.action=pagina
document.Forma.submit();
1
-
Dentro de la página lmprimiraAHEcapalmasdat.html, habrá un botón "IMPRIMIR",
el cual mandara llamar, al control de impresión del Sistema operativo para,
seleccionar varios tipos de impresión. Ver la siguiente Figura:
Como vimos a lo largo de todo este documento, el Análisis y Diseño Orientado a Objetos,
esunametodología muy poderosa, la cual nos facilita la abstracciónde un problema
dado, para llevarlo a una aplicación a nivel de software.
Con el ADOO, prácticamentetenemos el 90% de la aplicación hecha, únicamentenos
faltaría llevar este análisis a un código en cualquier lenguaje de programación para tener
la aplicación que necesitamos.
Ahora bien, como también
analizamos,
la Programación Orientada a
Objetos
nos
proporciona, Reutilizar el código, Modificar, deuna solavez,varias
partes de una
aplicación dada, Ordenar y agrupar código según su finalidad, Analizar
con mayor rigor
nuestras aplicaciones,Adaptar nuestro códigoaotrasaplicacionesaunque
no sean
nuestras, encontrar errores más rápidamente,
agregar
nuevas
capacidades
y
prestaciones, interactuar con el usuario y controlar mejor sus
acciones,
eliminar
redundancias decódigo, documentar mas cómodamente las aplicaciones
En relación, a la implantación deuna aplicacióncon la tecnología DBSP, podemos
concluir que:
- La implantación de una aplicación es muy rápida y eficiente.
- En comparación con otras tecnologías, requiere de muy poco código, o casi nada
de él.
- Utilizando ADOO, y como DBSP no es un lenguaje en el cual podamos aplicar
POO, tenemos que interpretar, muchas de las clases para llevarlas a nivel de
HTML con JavaScript y SQL.
- Es muy fácil de entender como funciona, y como se implanta.
- Como en todo lenguaje de programación, DBSP maneja primitivas, las cuales
llevan todo el control de la aplicación.
Existen dos desventajas que tiene el implantar una aplicación con DBSP.
La primera seria, que esta tecnología se casa con la Plataforma Windows(win32),
Y la Segunda seria, que talvez, aplicaciones muy complejas, no
se puedan llevar a este
nivel, o en su defecto, se tendrían que utilizar otro tipo de artificios a nivel de software.
Universidad Autónoma MetroDolitana IztaDalaDa
Luis Fernando Castro Careaga
Notas del Curso de Ingeniería se Software
UAM 2000.
Luis Fernando Castro Careaga, Análisis y Diseño Orientado a Objetos, Aplicadoa
Sistemas de Información
UAM 1999.
Roger S. Pressman, Ingeniería del Software,un enfoque Práctico
Mc GrawHiII , 1997. Cuarta Edición
Jacobson, Ivar; Booch, Grady; Rumbaugh, James, The Unified Software
Development Process
Addison Wesley, 1999.
Date, C.S. , Introducción a los Sistemas de Bases de Datos, Volumen1
Addison Wesley 5aEdición.
Juan Carlos Orós, Diseno de páginas Web intercativas con JavaScript
Alfaomega- ra-ma. 2000. 28 Edición
Software utilizado para desarrollar la aplicación
0
0
0
0
0
0
0
Rational Rose 2000 Enterprise Edition
Thorcom DBSP.
BDE (Borland DataBase Engine), de Delphi 5
Macromedia Dreamweaver 4
Evrsoft 1st Page 2000, editor de HTML
Internet Information Server 5.0
Windows 2000. Advanced Server.
World Wide Web
Tutoriales de HTML:
0
0
Guía para escribir documentos HTML
http://sestud.uv.es/manual.esp/indice.htm
Web Maestro. Crea tu página del web
http://216.167.93.139/webmaestro/index.htrnl
Tutoriales de JavaScript:
0
JavaScript
0
Curso de JavaScript 1.2
http://www.iec.csic.es/criptonomicon/iavascript/
http://html.programacion.net/is/index.php
0
Introducción a JavaScript
http://www.publimas.com/tutoriales/iava/index.htm