UNIVERSIDAD AUTóNOMA METROPOLlTANA Unidad lztapalapa

Casa abierta al tiempo

~ DlVlSlÓN DE CIENCIAS BÁSICAS E INGENIERíA

f’

Licenciatura en Computaci6n

Materia: PROYECTO DE INUESTIGACIÓN II

Título: “Desarrollo de una Aplicación con Metodología de Orientacjdn a Objetos y UML”

’Fecha: Noviembre de 1997 ”----

- ’Alumno: Cordero López Efraín

\

\ Matrícula: 9231 8986 -$A bK

1

Asesor: Profesor Luis Fernando Castro Careaga

Introduccicin. iii

1. hfarcu teórico. i

1 . 1 Conceptos Básicos 1

1 .2 Desarrollo de Sistemas con Metodología Orientada a Objetos 2 I ,2,1 Modelo de Requerimientos 2 I 2 . 2 Modelo del Dominio del Problenla 8 1.2.3 Modelo de Análisis 9 1.2.4 Disefio del Sistema 15 1.2.5 Construcción 16 I .2.6 Especiali7~ción de la Base de Datos 19

1.3 Lenguaje de Modelo Unificado (UML) 22 1.3.1 Generalidades 22 1.3.2 Diagramas 26

1.4 Definiciones Generales sobre el Diseño de Bases de Datos 32

1.5 Herramientas 35 1.5.1 Rational Rose 4.0 35 1.5.2 Delphi 1.0 35

2. Descripcicin del prohiema. 36

2.1 Descripción del problema. 36

3. Modelo de requerimientos. 38

3.1 Modelo de Use case. 38 Use case 1 : Control de compras y ventas del día 38 Use case 2: Regmro dc nueva compraventa 38 Use case 3 : Actualización o lnodificación de compraventa registrada 39 Use case 4: Cancelación de compraventa. 40 Use case 5: Control de movimientos de compraventa. 41 Use case 6: Registro de movimientos de compraventa. 41 Use case 4: Modificación de movimiento de compraventa. 42 Use case 8: Eliminación de movimiento de compraventa. 42

3.2 Modelo de interfaz. 43 Interfaz para el Control de compras y ventas del día. 43 Interfaz para el Regstro de nueva compraventa. 43 Interfa;.. para la Actualización o modificación de compraventa registrada. 43 Interflu para la Cancelación de compraventa. 44 Interfaz para el Control de movimientos de compraventa. 44 Intedaz para el Registro de movimicntos de una compraventa. 44 Interfaz para la Modtficacibn de movimientos registrados. 44 Interfaz para la Eliminación de movimientos registrados. 45 Conclusiones sobre l a s interfaces. 45

3.3 Diagrama de clases. 46

4. Mudelo de análisis. 511

i

5. Moddo de diseño. 54

6. Modeio de programacidn, 64 Descripción de los módulos. 64

7. Conclusiones. 68

Anexo: Glosario de términos dei área del problema 69

BibliograJia 71

Introduccibn.

En la actualidad la gente se preocupa por la manera en c6mo automatizar las operaciones de sus empresas, negocios, etc., para tener un mejor funcionamiento, rendimiento, organizaci6n y agilizaci6n de sus operaciones diarias. Esto es, buscan sistemas que cumplan con ciertos requerimientos y que ademas tes sean útiles para cubrir todas sus necesidades con un bajo costo y un alto rendimiento, así tambien, que sirvan de apoyo en la toma de decisiones sobre las operaciones de sus empresas.

Mucha gente ha enfocado su atenci6n hacia tales aspectos, hacia su estudio y hacia la creacidn de vanas formas de resolver ciertos problemas, elaborando metodologlas que incluyen modelos, diagramas, esquemas, etc..

En el presente trabajo se estudia una metodología que comienza a tomar auge en el desarrollo de sistemas computacionales, y que cumple con los caracterfsticas mencionadas anteriormente. Dicha metodología se conoce como Metodología de Orientacidn a Objetos basada en el Lenguaje de Modelo Unificado (UML), cuyos principales autores - Grady Booch, James Rumbaugh e lvar Jacobson -, son los principales impuisores del paradigma de Orientaci6n a Objetos.

La aplicacidn sobre la cual se enfocara bsta metodología es la automatitacidn de las operaciones de compra y venta de una Casa de Cambio de divisas.

En las siguientes secciones del trabajo se detallara todo el proceso que se sigui6 y mediante el cual se logr6 desarrollar el sistema para la Casa de Cambio, contemplando desde el estudio de la metodología hasta la implantaci6n del sistema.

La manera en que se organiz6 el proyecto fue en un conjunto de secciones y un anexo, de los cuales se da una breve semplanza a continuaci6n:

- Introducci6n La seccibn actual.

- Marco te6rico En esta seccidn mencionan todos los conceptos que sirven de soporte para el desarrollo del sistema. Se manejan conceptos generales de Bases de Datos, Paradigma de 0rientacic)n a Objetos, Modelo de Lenguaje Unificado (UML) y Metodología de Análisis y Diseño de Sistemas Orientados a Objetos.

- Descripción del problema Una descripci6n informal del Area del problema.

- Modelo de requerimientos La primera fase del desarrollo del proyecto. En esta seccidn se trata el modelo de Use cases, el modelo de interfaz y el diagrama de clases del sistema.

- Modelo de andllsis La segunda fase del proceso de desarrollo. Incluye las descripciones de los diagramas de colaboracibn desarrollados para el proyecto.

- Modelo de diseiio La tercera fase del proceso de desarrollo. Entre otros aspectos, trata las descripciones de los diagramas de secuencia del proyecto.

iii

- Modelo de programación La fase final del proceso de desarrollo. Incluye algunas consideracimes sobre las plataformas utilizadas para el desarrollo de la programación, y la manera en que se estructuró al sistema.

- Conclusiones La resultados obtenidos se analizan en esta sección. Aquí se muestra la importancia que tuvo la realización del proyecto, los conocimientos que se obtuvieron y la problemática encontrada.

- Anexo: Glosario de t6minos del brea del problema En esta secci6n se proporeionan las definiciones de algunos terminos tecnicos utilizados en al área del problema.

- Bibliografía

iv

l. Marco teórico.

1. I Conceptos BBsicos

Programacidn Orientada a Objetos (POO): Es un método de implementación en el cual los programas son organizados eomo colecciones cooperativas de objetos, donde cada una de las cuales representa una instancia de alguna clase, y ademas todas las etases son miembros de una jerarquía de clases que está unida mediante tipos de relaciones.

Diseño Orientado a Objetos: Es un método de diseño que abarca el proceso de descomposición orientado a objetos y una notación que describe tanto los modelos tógicos y físicos, como los modelos estáticos y dinámicos, del sistema que se está diseñando.

Análisis Orientado a Objetos: Es un método de análisis que examina los requerimientos desde la perspectiva de las clases y los objetos encontrados en el vocabulario del dominio del problema.

El Modelo de Objetos está constituido de cuatro elementos principales (Abstracción, Encagsutamiento, Modularidad y JerafquSa 1 y tres elementos secundarios ( TipiTiacidn, Concurrencia y Persistencia ), que se definen a continuación.

Abstracción: Denota las características esenciales de un objeto que lo distinguen de otros tipos de objetos y así provee los límites conceptuales definidos, que son relativos a la perspectiva del observador.

Encapsulamiento: Es un proceso de dividir y meter en compartimentos los elementos de una abstracción que constituyen su estructura y su comportamiento. Et encapsulamiento sirve para separar la interfaz contractual de una abstracción y su implementación.

Modularidad: Es la propiedad de un sistema que ha sido descompuesto en módulos cohesivos y dkbilmente acoplados.

Jerarquía: Es una categoría u orden de abstracciones.

Típificación: Es la coacción de la clase de un objetos, tal que los objetos de tipos diferentes no pueden ser intercambiados, o pueden ser intercambiados solo de manera muy restringida.

Concurrencia: Es la propiedad que distingue un objeto activo de uno que no es activo.

Persistencia: Es la propiedad de un objeto por medio de la cual su existencia trasciende tiempo y/o espacio.

Un objeto tiene estado, comportamiento é identidad; la estructura y el comportamiento de objetos similares son definidos en su clase común; los tbrminos “instancia” y “objeto” son intercambiables.

El estado de un objeto abarca todas las propiedades (estáticas usualmente) del objeto mas los valores (dinámicos usualmente) actuales de cada una de estas propiedades.

1

El comportamiento es cómo actúa y reacciona el objeto en términos de los cambios de su estado y el paso de mensajes.

La identidad es la propiedad de un objeto que lo hace distinguible de todos los demás objetos.

Los tipos de jerarquías entre objetos son las relaciones de agregacicin y las ligas.

Los tipos de jerarquías entre clases incluyen asociación, herencia, agregación, uso, instanciacicin y metaclase.

l. 2 Desarro//o de Sisfemas con Mefodo/ogía Orienfada a Objetos

Ingeniería de Software Orientada a Objetos

Son una serie de técnicas utilizadas para desarrollar y comunicar el diseño de un sistema que será implementado primeramente en software.

Comparado con los métodos de diseño de sistemas utilizados previamente para el desarrollo de software la Ingenieria:

a) Es más flexible para el mundo real, para su entendimiento o cambios b) Provee unidades que se ajustan al ambiente específico de un sistema y se puede aplicar a

c) Hace el sistema más fácil de entender, y así mismo entendible para los clientes o los cualquier sistema relacionado con la parte de ese ambiente

diseñadores del software

El diseño orientado a objetos provee un modelo para soportar un análisis y diseAo sólido, además permite a tos diseñadores e implementadores corregir y mantener el mismo modelo consistentemente desde el inicio del análisis hasta la codificación e implementación.

Pasos de la Ingeniería de Software Orientada a Objetos

I. Modelo de requerimientos, el cual provee las bases para las funciones del sistema. It. Modelo del dominio del problema, provee la llave lógica de la estructura del sistema Ill. Modeto de anhlisis IV. Diseiio del sistema, provee la llave física de la estructura del sistema, los mapeos de

V. Construcción, el cual provee el Modelo de Diseno VI. Especialización de Bases de Datos

la estructura 16gica y versiones ejecutables trabajando

1.2.1 Modelo de Requerimientos

Es el proceso de determinar que es lo que el cliente quiere que haga el sistema. Es una fase de alto nivel que identifica las funciones clave que el sistema debe ejecutar, define el entorno del

2

dominio del sistema que se debe soportar y documenta las prácticas clave y políticas de la empresa que el sistema debe soportar.

El modelo Use Case formalizado inicialmente por lvar Jacobson es un método muy poderoso para describir las funciones del sistema. Jacobson define un Use Case como "una forma particular o patr6n o ejemplo de utitizacicin, un escenario que comienza con algún usuario iniciando alguna transacción o secuencia de eventos inteffelacionados. Estos Use Cases son utilizados a través del análisis y diseño para encontrar clases y operaciones, validación y pruebas.

Este modelo gobemará el desarrollo de todos los otros modelos, par lo tanto, este modelo es el central en todo el desarrollo del sistema. El modelo de requerimientos estará estructurado por et modelo de anáhsis, reatizado por el modelo de diseiio, implementado por el modelo de implementación y examinado por el modelo de examen. El modelo de requerimientos también funcionará como una base para el desarrollo de instrucciones y manuales aperxionales, cualquier cosa que el sistema haga es descrito aquí desde una perspectiva de usuario.

El modelo de requerimientos consiste de tres partes; el Modelo de Use Case, el Modelo de Objeto del Dominio d e l Problema y las Descripciones de lnterfat de Usuario. El modelo de Use Case especifica la funcionalidad que el sistema tiene que ofrecer desde una perspectiva de usuario y, definiremos que lugar tomaría dentro det sistema. Et modelo usa actores para representar los roles que los usuarios pueden jugar, y los Use Cases representan lo que los usuarios serian capaces de hacer con el sistema. Cada Use Case es un curso completo de eventos en el sistema desde una perspectiva del usuario. Si es apropiado, las descripciones de interfaz también pueden ser desarrolladas. Para dar un cuadro conceptual y un mejor entendimiento del sistema, se usan objetos que representan ocurrencias en el dominio del problema. Este modelo servirá como un fundamento comrjn para toda la gente involucrada en el análisis de requerimientos: desarrolladores y personas que requieren el sistema.

De forma general el Modelo de Requerimientos contempla los siguientes puntos:

Objetivo

El análisis de requerimientos esencialmente forma un contrato entre el cliente y los desarrolladores en el cual el sistema es provisto pafa el cliente. Este contrato no es fijo; como el ciclo de desarrollo continúa, éSe podrá cambtaf. S i e pafa tener un punto &? inicio y una referencia central para lo que el sistema debe de realizar.

Avances

El método requiere dos productos formales para esta etapa:

Un documento del sistema, el cual delinea las responsabilidades del sistema Una declaración de las funciones del sistema el cual delinea el prop6sito del

sistema

Durante esta fase, es común desarrullar escenafios para las entradas y &idas clave del sistema, o una lista de referencias de las politicas, sistemas existentes y procedimientos. Muchas compañias y agencias necesitan otros enunciados de requefimientos en un formato en particular que pueden ser considerados avances de esta fase.

3

Pasos

No existen pasos formales para el anáiisis de requerimientos, ya que este proceso cambia radicalmente dependiendo de las nuevas necesidades d e l sistema CMO la disponibilidad y nivel de aprobación de los clientes y los expertos de políticas, además de la disponibilidad de documentos adicionales que explican lo que el sistema debe cumplir.

Participantes

La calidad del mátisis de requerimientos depende dd equipo de trabajo, de los expertos en la materia, de las personas que se encargan de mantener las políticas, de los gerentes, negociadores y comunicadores.

Como parte del modelo de requerimientos se tienen los siguientes elementos:

Actores

Para ser capaz de identificar el Use Case que está siendo realizado en el sistema, se identificarán l o s u s u a r i o s d e l sistema. Esto es realizado por l o s actores. Los actores modelan a los probables usuarios; el actor es un tipo de usuario 6 categoría, y cuando un usuario realiza algo, BI actúa como una ocurrencia de este tipo. Una persona puede instanciar (jugar el rol de) varios actores Mefentes. Los actores, de este modo, definen roles que los usuarios pueden jugar.

Los actores modelan cualquier cosa que necesite intercambio de informacibn con el sistema. Los actores pueden modelar usuarios humanos, pero tarnbkh pueden modelar otros sistemas que vayan a comunicarse con el sistema. El punto escencial es qw? los actores constituyen cualquier cosa que es externa al sistema que se está desarrollando.

De este modo, se tendrá que hacer una Delimitaci6n del Sistema para definir dónde está el límite entre los actores y los Use Cases. Se identificará un actor como todo lo externo que se comunique con el sistema.

Un buen punto de comienzo es a menudo el verificar por qué el sistema está siendo dke7tado. ¿Quienes son los actores a tos que el sistema está supuestamente ayudando? . Los actores que van a hacer uso del sistema directamente (quizá en su trabajo &ario) s e r h ltarnabos Actuns Primarios. Cada uno de estos actores realizará una ó varias de las tareas principales del sistema.

Como todas las funciones importantes del sistema son investtgadas, más y m& actores primarios son identificados. Junto a estos actores primarios hay actores supervisando y manteniendo el sistema, a ellos se les llama Actores Secuncfafiias. Los actores secundarios existen solo cuando los actores primarios pueden usar el sistema.

S e hard la división dentro de actores primarios y secundarios debido que se desea que la estructura del sistema esté definida en terminos de la funcionalidad principal. Los actores primarios gobernarán la estructura del sistema. Así, cuando se identifiquen l o s Use Cases, tambien se comenzarA con los actores primarios. En esta forma, se puede garantizar que la arquitectura del sistema estara adaptada a \os usuarios mAs importantes. Los cambios del sistema vendrftn principalmente de estos actores.

4

Use Cases

Después que hemos definido qué es externo a nuestro sistema podemos definir la funcionalidad dentro de éste. Haremos esto por especificar los use cases. Un Use Case es un forma específica de usar el sistema por usar alguna parte de la funcionalidad. Cada use case constituye un curso completo de eventos iniciados pol" un actor y éste especifica ta interacción que toma lugar entre un ador y el sistema. Un use case es de este modo una secuencia especiat de transiciones relacionadas realizadas por un actor y et sistema en un diaogo. Los use cases reunidos especifican todas las formas existentes de uso del sistema.

Para comprender los use cases podemos ver sus descripciones como gráficas de transición de estados. Cada estímulo enviado entre un actor y el sistema lleva a cabo un cambio de estado en esta gráfica. Podemos de este modo ver un use case como existiendo en estados diferentes. Las transacciones relacionadas mencionadas antes son de este modo tas transiciones en esta gráfica. Cada actor realizará un número de use cases para el sistema.

Como los actores, los use cases pueden ser instanciados y esto es hecho cada vez que un usuario lleva a cabo un use case en el sistema. Como varios use cases pueden comenzar en una forma sirnitar, esto 170 es siempre posible pafa decidir que use case ha sido instanciado hasta que este es completado.

Los use cases son identificados a través de los actores. Para cada curso completo de eventos iniciados por un actor se identifica un use case. AI visualizar cada actor, se decide en qué use case participa tal actor.

Para identificar el use case, se puede leer ta especificación de requerimientos desde una perspectiva del actor, y seguir en discusiones con aquellos que participarán como actores. Esto ayudará a elaborar un número de preguntas tales como:

O ¿Cuáles son las principales tareas de cada actor? O ¿Ten&á el actor que leer/escribir/carnbiar cualquier información del sistema?

¿Tendrá el actor que informar at sistema acerca de cambios externos? O 'Deseará el actor ser informado acerca de cambios inesperados?

No es siempre obvio que la funcionatidad ser6 puesta en un use case separado, y que &e es solo una variante del mismo use case. La cornptejidad del use case es importante en este contexto. Se tiene un número caminos diferente de caminos para expresar variantes.

Hasta ahora, se ha discuttdo solo la identificación de los use cases. Esto, a menudo es un proceso muy iterativo donde se realizan varios intentos. Cuando et cuadro se estabiliza, cada use case será descrito con más detalle. Entonces , se describe el Curso Básico, el cual es el curso más importante dando el mejor comportamiento del use case. Las variantes del curso básico y errores que pueden ocurrir están descritos en Cursos Afternativos. Normalmente un use case tiene solo un CUBO bdsico, pero varios cursos atternativos. Las descripciones pueden ser hechas antes, pero desde el modelo de requerimientos inicialmente sufrirá varios cambios, también mucho trabajo que no se haya realizado con anterioridad se dejará fuera.

Cuando se analice y describa el use case en detalle, el sistema estará descrito muy detalladamente. Desde el use case, a menudo se enfoca a una cierta funcionalidad del sistema, esto se realiza para anatizar l a s funcionalidades en una forma amplificada. En este modo, se pueden desarrotlar use cases para diferentes Areas de funcionalidad al inicio ,y después unir esos use cases para formar el modelo de requerimientos de forma completa.

5

Extensiones

Un poderoso concepto que es usado para estructurar y relacionar las descripciones use case, es la asociación extendida. La extensión relata cómo la descripción de un use case puede ser insertada en la descripción de otro use case, y a s í extenderto. De esta manera, las extensiones de los use cases pueden ser descritas en una forma simple y, especialmente, los cambios y las adiciones de funcionalidad se pueden hacer fácilmente.

El use case donde sería insertada la nueva funcionalidad, debe ser por sí mismo un curso completo . De esta manera, la descripción no presta atención a algunos cursos que pueden ser insertados y de este modo se evita la complejidad.

Para definir la asociación extendida, el sistema será presentado dando en una buena y modificable estructura. Como es posible describir varios use cases independientemente uno de otro, sus descripciones serán simples.

La extensión es usada para modelar extensiones de otros use cases completos. A continuación se dan algunos ejemplos de como usar la extensi6n:

0 Para modelar partes opcionales de los use cases. 0 Para modelar cursos comptetos y alternativos que rara vez ocurren. 0 Para modelar subcursos separados los cuates son ejecutados solo en ciertos casos. 0 Para modelar que diferentes use cases puedan ser insertados en un use case especial.

Descripciones de Intertaz

Cuando se describen los use cases y se comunican a los usuarios potenciales, con frecuencia es apropiado describir las interfaces en más detalte. Si es una IHM (tnterfaz Hombre-Máquina) se pueden utilizar bosquejos de lo que el usuario verá en la pantalla cuando realice el use case en simulaciones más sofisticadas, usando un SAlU (sistema Administrador de lnterfaz de Usuario). De esta manera, se pueden simular los use case en la forma en que apareceran ante los usuarios antes de tener la forma en que serán implementados.

Estas descripciones de interfaz son una parte escencial que acompaña a las descripciones de los use case. Cuando se diseñan interfaces de usuario, es escemial tener a los usuarios involucrados en este desarrollo. Adicionalmente, cuando se diseiian interfaces de usuario es escencial que la interfaz como tal refleje la vista lógica del usuario del sistema.

El modelo del dominio del problema (próximamente discutido) es exactamente tat como una perspectiva. Este es actuatrnente uno de los principios fundamentales del diseño de interfaz- humano; la consistencia entre el cuadro conceptual de usuarios del sistema y el comportamiento actual del sistema.

Objetos del Dominio del Problema

Cuando se trabaja con el modelo de requerirnientos, este pude algunas veces ser elaborado para definir la tarea del sistema y especialmente la delimitación del sistema. Este es típicamente el caso en que la especificación de los requerimientos existe sdlo en una forma muy vaga.

6

Entonces, una herramienta muy buena es comenzar a desarrollar un vista lógica del sistema usando objetos del dominio del problema, es decir, objetos que tierren un homólogo directo en el ambiente de aplicación y que son parte de la información que el sistema maneja.

Tal modelo del dominio del problema, será un soporte fuerte cuando se especifiquen los use cases. Entonces, este modelo definirá los conceptos con tos que estará trabajando. De esta forma, se tendrá un glosario que puede ser utilizado para formular la funcionalidad de los use cases.

Sin embargo, el principal beneficio de tal modelo, es que es una muy buena herramienta con la cual es posible comunicar el sistema. Desde que los usuarios y las personas que requieren el sistema reconocen todos los conceptos, el modeio puede ser utilizado en el momento en que se defina qué es lo que hará el sistema.

L Entonces qué tan amplio sería actualmente et modelo det dominio del problema? Para responder a esto, se tienen diferentes grados posibles de refinamiento. Desde que el propósito principal es formar una base común de entendimiento para desarrollar el modelo de requerimientos, y no para definir totalmente el sistema, se cree que el nombre del objeto y, posiblemente también tos atributos lógicos y l a s asociaciones de instancias estáttcas (esto es, las referencias estáticas entre esos objetos) están en un nivel apropiado para quedarse.

La experiencia demuestra que muchos (si no es que todos) los objetos del dominio destacarán como objetos entidades en et modelo de análisis. Sin ernbargo, este mapeo mecánico es peligroso de realizar, puesto que ahí pueden muy bien ser cambiados.

Este modeto del dominio del problema puede ser usado para varios propósitos. Se ha discutido anteriormente su r o l , como un soporte para la formulación de las descripciones del use case y también para et diseño de IHM. Otro uso del modelo del dominio del problema es cuando se hacen modelos empfesariales. Adicionalmente a esto estará una primera versión de un modelo de requerimientos del sistema requerido en la empresa. En tal forma, la transición entre el modelado de ta empresa y et desarrollo det sistema puede ser hecho de igual forma. Esto significa que un modelo del dominio del problema desarrollado con alguna tkcnica, servira como un entrada muy sólida para el desarrollo del sistema.

Refinamiento posterior de/ Modelo de Requerimientos

El Modelo de Requerimientos como se describió anteriormente será suficiente para especificar la funcionalidad det sistema. Sin embargo, se puede elaborar este modeto posteriormente, no solo para incrementar su reuso, sino también para pfeparar la transición del modelo de análisis. Cabe aclarar que este trabajo no es muy interesante para el que requiere el sistema.

Este refinamiento es hecho principalmente para identificar partes similares de tos use cases y extraer estas partes similares. Tales use cases que son extraidos, se llamarán Use Cases Abstractos, tomando en cuenta que éstos aún no son instanciados propiamente, pero esto es solo significativo para describir partes comunes entre otros use cases. El use case que realmente será instanciado se llamara Use Case Concreto.

Las descripciones de tos use case abstractos son usadas en las descripciones de tos use cases concretos. Esto signfica que cuando una instancia de un use case sigue la descripción de un use case concreto, en un cierto punto se puede continuar la descripción del use case abstracto instanciado. Estas retaaciones están en atgitn tipo de herencia. Sin embargo, esta no es exactamente la misma semélntica de la herencia, en ta que se tiene en un lenguaje de programaci6n orientado a objetos, aquí se le da un nombre diferente, se le llama a esta relacidn una Relación de Uso.

7

Normalmente, el comportamiento similar entre use cases es identificado después que los uses cases han sido descritos. Sin embargo, en algunos casos esto hace posible que sean identificados con anterioridad.

Aunque el reuso entre use cases puede ser también de usos múttiples. Varias partes habían sido extraídas de un use case que son comunes con otros use cases. Un use case específico puede usar después todos estos use cases abstractos.

La ventaja de modelar actores abstractos, es que expresa similitudes en los use cases. Si el mismo (parte de) use case sería realizado por varios actores distintos, los use cases después necesitan ser especificados con respecto a un actor en lugar de varios.

La asociación de uso es utilizada cuando dos o más use cases tienen comportamiento común. Normalmente, no hay razón para crear use cases abstractos que son usados sólo por un use case. Sin embargo, se tiene esa situación con la asociación extendida. Un use case extendido puede ser visto como un use case abstracto.

1.2.2 Modelo del Dominio del Problema

El modelo del dominio del problema es el proceso de definición del modelo orientado a objetos de manera precisa y concisa, de la parte del mundo real de la empresa que es relevante para el sistema (Dominio del problema). Este es el proceso a través del cual los diseñadores obtienen el conocimiento detallado del dominio del problema para crear un sistema capaz de cumplir con las funciones requeridas. Durante un etapa posterior, el sistema del dominio asume gran importancia.

Objetivo

El modelo del dominio del probtema identifica la mayor cantidad de objetos en el dominio, incluyendo todos los datos y la mayoría de operaciones que las funciones del sistema debe realizar.

Un buen modelo del dominio también afiade niveles apropiados de abstracción para un sistema. Con un cuidadoso analisis y definición de l a s áreas del dominio, las estructuras pueden ser construidas y pueden directamente ser reutilizables en muchos sistemas del Area de la empresa.

Avances

Los avances del modelo del dominio incluyen:

0 Diagrama de Clases, el cual identifica las clases clave o tipos del dominio 0 Especificaciones de clases, las cuales contienen todas tas definiciones semAnticas de las clases, sus relaciones, sus atributos y sus operaciones clave 0 Diagrama de Objeto Escenario, el cual ilustra cómo interactúan los objetos para soportar las funciones clave del sistema 0 Diccionario de Datos, el cual lista todas las entidades del dominio incluyendo clases, relaciones y atributos

8

Pasos

Los siguientes pasos son realizados durante el modelo del dominio:

0 Definición de clases, que incluye identificación de la mayoria de tipos de objetos del dominio y la definición de éstos 0 Definición de relaciones, donde se describen la mayoria de asociaciones entre esos objetos

Definici6n de operaciones, el cual inctuye la identificación de ta mayoría de operaciones requeridas para soportar la estructura de clases y funciones del sistema

Encontrar atributos, aqui se determinan las propiedades que describen las clases Definición de herencia, el cual incluye encontrar generalizaciones y

especializaciones con tipos de dominio similares

0 Validación e iteración, donde se incluye una revisión, prueba y reparación del modelo, además de las ocurrencias actuales de los procesos

Participantes

Generalmente un Ingeniero de Software o Arquitecto de Software posee un buen conocimiento de las abstracciones y de las semánticas de un sistema orientado a objetos el cual es requerido para producir los avances.

El modelo del dominio no puede ser realizado aisladamente. Los productos pueden ser elaborados por los clientes o un analista de sistemas el cual tenga conocimientos de diseño orientado a objetos. Frecuentemente estos avances son producidos por un pequeño equipo de expertos del dominio e ingenieros de software quienes tienen un alto nivel de comunicación con el cliente.

1.2.3 Modelo de Análisis

Cuando el Modelo de Requerimientos ha sido desarrollado y con frecuencia también señalado por los que requieren el sistema, nos podernos enfocar en estructurar el sistema. Esto se hace inicialmente desarrollando el modelo de análisis. En et modelo de análisis se describe el sistema usando tres distintos tipos de objetos: objetos ínterfaz, objetos entidad y objetos control.

Se usan también subsistemas para agrupar estos objetos en unidades manejables. E n el modelo de requerimientos tenemos que especificar que lugar toma en el sistema. El modelo de análisis apunta a crear una buena pfataforma para el diseño del sistema y formard también las bases del diseño.

El trabajo para desarmtlar et modelo de análisis supone realmente distribuir el comportamiento especificado en las descripciones de los use cases entre los objetos y el modeto de análisis. Un objeto puede ser común a varios use cases distintos. Así, se debe establecer explícitamente qué objeto es responsable de cada comportamiento en el use case.

Objetos Interfaz

9

Toda la funcionalidad especificada en las descripciones use case que son dependientes directamente del entorno del sistema se colocan en objetos interfaz. Es por medio de estos objetos que los actores se comunican con el sistema. La tarea de un objeto interfaz es traducir las acciones del actor al sistema en eventos del sistema, y traducir esos eventos det sistema en los que el actor está interesado y que le son presentados. Los objetos interfaz tienen, en otras palabras, comunicación bidireccional entre el sistema y sus usuarios.

Los objetos inteffaz son bastante simples de identificar. Se tienen al menos tres estrategias. Los objetos son ctaramente identificados de las descfipciones de interfaz del sistema acompañando el modelo de reqtterimientos, o se puede empezar desde l o s actores, o se pueden leer las descripciones use case y extraer la funcionatidad que es un interfaz específica. Cada actor concreto necesita su propia interfaz para sus acciones en el sistema.

Es evidente, que los objetos interfaz no son totatrnente independientes de otros, pero ellos deben conocerlos para ser capaces de resolver ciertas tareas. Esto es resuelto con la introducción de asociaciortes conocidas entre tos objetos. Una asociación conoctda es una asociación estática entre instancias, y significa que un instancia sabe de la existencia de otra instancia. Esto no da al objeto la oportunidad de intercambiar información con el otro objeto; entonces aquí es necesaria una asociación dinámica.

Un objeto puede asociarse con varias otras instancias de ta misma clase. Por lo tanto, también s e r h descritas cuantas instancias pueden ser incorporadas por la asociación conocida. Esto se hace asignando una cardinalidad a cada asociación. Esta cardinatidad chce cuantas instancias pueden ser asociadas. Algunos ejemplos de cardinalidad son [l],[O..N].

Un tipo especial de asociación conocida es la Asociación consiste-de, la cual es usada para expresar que m objeto está compuesto de otros objetos. Como una estructura donde un objeto unitario tiene asociaciones con partes parkipantes es llamada algunas veces una Agregación. Esto es común en objetos interfaz. En un sistema de ventanas, por ejemplo, se quiere expresar que una ventana puede consistir de botones, menús y barras scroll.

Esto es con frecuencia llamado jerarquía de componentes o una jerarquía de particiones. Teniendo identificados los objetos interfaz, será fscil modificar una interfaz en el sistema. Pronto llegará a ser obvio que existen dos tipos distintos de interfaz para modelar: interfaces a otros sistemas e interfaces a usuarios.

Para objetos interfaz que se comunican con otros sistemas, la comunicación es descrita usualmente en téminos de protocolos de comunicación. Estos objetos interfaz pueden ser de un tipo que traduzca a un protocolo estandarizado o pueden ser de un tipo que solo mande estímulos producidos internamente sin algunas conversiones comptejas. Esto constituye otra ventaja: Si el protocolo es cambiado, estos cambios serán locales a este objeto interfaz.

Los objetos interfaz deben ejemplificar la señal de entrada o desencadenarse cuando pasan ciertos valores, desde la parte intema del sistema; hay sólo comunicacidn discreta vía estímulo. Los objetos interfaz deben entonces traducir de información continua a información discreta.

El otro tipo de objetos interfaz son los usuarios. Hoy en dia, existen las interfaces de usuario gráficas (GUS) entre el sistema y el usuario. Cada objeto interfaz puede se complejo para modelar; pero pueden ser modelados como estructuras completas de los objetos interfaz.

Llegó a ser evidente que los objetos interfaz son adaptados para presentación, pero ellos tambi6n pueden ser utilizados para manejar información y tener comportamiento. La cantidad de información y comportamiento que serían adjudicados a un objeto interfaz deben ser decidida dependiendo del caso. En un extremo, el objeto interfaz s6lo manda el estímulo que recibe de un actor a otros objetos en el sistema sin participar éI mismo activamente en el curso de los eventos. En el otro caso extremo, el comportamiento del objeto interfaz es muy complejo, y la

1 o

información compleja es atada al objeto interfaz, y puede funcionar casi independientemente de otros objetos.

Así, para identificar qué parte del flujo en un use case sería localizado en objetos interfaz; se debe enfocar las interacciones entre los actores y los use cases. Esto significa que se visualizaría por unidades:

0 Qué información se presenta al actor ó se necesita de él. 0 La funcionalidad que está cambiando si el comportamiento del actor está cambiando. 0 Dónde está dependiendo un curso de un tipo de interfaz.

Se puede diferenciar entre varias estrategias distintas de como localizar la funcionalidad

I) Control Dominante de la Computadora ó Control Empotrado es et caso donde se pone la funcionalidad interna que controla el sistema, esto es, en los objetos control y los objetos entidad. Aqui los objetos interfaz no tienen mucha funcionalidad.

2) Control Dominante de Diitlogo es et caso donde se pone mucho control de la funcionalidad en tos objetos interfaz y, estos objetos modelan mucho de la funcionalidad del sistema. En este caso no se tienen muchos objetos control en el modelo.

3) Control Mezclado pone el contrat en ambos lados permitiendo la invocación de diálogo desde el lado cornputacional y viceversa. Esto ofrece más flexibilidad, pero requiere mas disciptina de tos programadores para mantener la independencia del diátogo.

4) Control Balanceado es el caso donde se pone el control separado de ambos el diálogo y la computación. El componente del control gtobal, que tipicamente es un objeto control, gobierna la secuencia entre invocaciones de dialogo y funciones computacionales.

Objetos Entidad

Para modelar la información que el sistema manejará por un largo tiempo se usan Objetos Entidad. Típicamente tal información sobrevive al use case, por lo tanto, la información siempre será guardada si el use case ha sido comptetado. Además de que ta información es manejada, también locatizamos el comportamiento que pertenece naturalmente a esta información al objeto entidad.

Los objetos entidad son identificados de los use cases, de la misma manera que los objetos interfaz. Muchos objetos entidad son encontrados de manera rápida y son muy obvios. Estos objetos entidad ‘obvios’ son con frecuencia identificados en el dominio del problema del modelo de objetos. Aunque otros pueden ser difíciles de encontrar. Las entidades usualmente corresponden a algtin concepto de la vida real, fuefa del sistema, aunque este no siempre es el caso. Es muy fdcil modelar a varios objetos entidad, en el caso m que se requiera mas informaci6n de la que es llamada en reatidad. Lo más difícil es modelar solo el objeto entidad que actualmente es necesario.

Para manejar información, tos objetos usan atributos. A cada objeto es posible vincularlo con varios atributos. Cada atributo tiene un tipo, el cual puede ser de un tipo de datos primitivo, como un entero o una cadena, pero también puede ser un tipo de datos compuesto que es más complejo y que está definido especialmente. Los atributos pueden ser usados en todos los tipos de objetos para describir la información que estsi atmacenada. Los atributos de un objeto entidad desarrollados como los use cases deben ser analizados.

No siempre es fácil decidir si una pieza de información será modetada como un objeto entidad o como un atributo. Para ser capaces de decidir lo anterior, se debe tomar en cuenta cómo será utilizada la información.

La información que es manejada en forma separada será modelada como un objeto entidad, mientras que la información que está fuertemente unida a alguna otra información y nunca es usada por sí sota, será modetada en un atributo de un objeto entidad. E n otras palabras, es decisiva la foma en cómo manejan los use cases la información. Cierta infomtackjn puede llegar a ser un objeto entidad en un sistema, mientras que sería un atributo en otro sistema.

La única manera para manipular un objeto entidad es vía las operaciones. Por lo tanto, las operaciones identificadas deben ser suficientes para todos aquellos que desean usar el objeto entidad. La descripción detallada de los use cases tiene un significado muy vatioso para encontrar las operaciones deseadas. La técnica utitiza principalmente diagramas de interacción. El caso normal no es identificar operaciones en el modelo de análisis, ya que con frecuencia cambian en el diseno. Et caso normal ,es por lo tanto posponer la identificación hasta la construcción.

Las operaciones pueden ser más o menos complejas. Un caso extremo, es que un objeto entidad conste soto de operaciones de lectura y escritura, y el otro caso extremo es tener cursos completos de eventos incluidos en las operaciones. Como siempre, la mejor manera es una forma intermedta mtre estos dos extremos. Las mismas reglas básicas se aplican al objeto entidad c m o a ot~os -os, esto es, todo (comportamiento e informac~n) que es conectado naturalmente con el objeto entidad sería colocado en él.

Con frecuencia una manera apropiada de decidir donde será colocado el comportamiento, es modelar irriciatmente todo sin usar objetos control, esto es, usar sólo objetos interfaz y objetos entidad.

En efecto, podemos construir todos los sistemas con estos dos tipos de objetos. Sin embargo, cuando un modelo ha sido desamltado, se notar& que hay ciertos comportamientos que no son naturalmente cobcados, desde una vista sopofte, en *tos entidad o en objetos interfaz. La siguiente es una vista de operaciones típicas que deben ser ofrecidas por un objeto entidad:

O Búsqueda y almacenamiento de información. 0 Cursos que deben ser cambiados si el obpto entidad es cambiado. O Creación y eliminación de un objeto entidad.

Una operación sobre un objeto entidad puede significar que et objeto entidad procede a otro objeto entidad y pregunta por información acerca de algo. Esto se conoce como Asociación de Comunicación. Una asociación de comunicación modela la comunicación entre dos objetos. A través de estas asociaciones, un objeto manda y recibe estimulos. La asociación comienza desde el objeto que esth realizando la manipulación (es decir manda el estímuto inicial), y es dirigido al objeto en donde la manipulaciór? será colocada. Ya que es una asociación instanciada, es sólida; y como es dinámica, no se nombrará la asociación.

Objetos Control

Se ha dividido el flujo del use case en objetos interfaz y objetos entidad. En atgunos casos todos los flujos han sido puestos sobre objetos de estos dos tipos. En este caso, tos objetos control no se necesitan para ese use case. Sin embargo, en los use cases más comptejos, a menudo se queda e1 comportamiento que no es naturalmente puesto en cualquiera de estos dos tipos de objetos. Tal comportamiento es puesto en Objetos Control.

12

La razón de que tal comportamiento es difícil de colocar en cualquiera de los otros tipos de objetos es que este es un comportamiento que realmente no pertenece a la interfaz del sistema, ni pertenece a fa forma en que se maneja la información. Una posibilidad es extender el comportamiento, de cualquier forma, sobre estos tipos de objeto, como es sugefido por algunos métodos, pero esta s o l u c t ~ no es ideal desde una perspectiva de cambio. tht cambio en tat compoftctmiento (funeionalidad con frecuencia) podría entonces afectar varios objetos y de este modo son dificiles (costoso) de incorporar.

Los objetos control típicamente trabajan como pegamento u amortiguador para unir a los objetos sobrantes, así que ellos forman un use case. Ellos son típicamente los más efímems de todos los tipos de objetos y, usualmente sólo et úttimo persiste en la realización de un use case. Así que, es dificil descubrir un balance para deteminar la colocación en objetos entidad, objetos control u objetos interfaz.

Los objetos control son normalmente encontrados directamente del use case. En un giro preliminar se asignar4 un objeto control para cada use case concreto y abstracto. Cada use case normalmente involucra objetos interfaz y objetos entidad. Este compoftarniento que queda después de que los objetos interfaz y objetos entidad han obtenido sus partes serán puestos en los objetos control.

Los tipos típicos de funcionalidad puestos en los objetos control son de comportamiento relación-tmsacción, o secuencias de control específicas para uno o varios use cases, o funcionalidad para aislar los objetos entidad de los objetos interfaz. Los objetos control son de esta forma los linicos que unen cursos de eventos así que, llevarán la comunicación con otros objetos.

La descripción de un objeto control se encuentra indirectamente de los use cases por verificar ya que el use case corre sobre otros tipos de objetos. En los lugares donde el objeto control necesita ser involucrado, es presentado el rol que el objeto control tomará y que involucra.

Los usos entre los use cases con frecuencia están mapeados en asociaciones de comunicación entre los objetos correspondientes. Si los use cases tienen una asociación extendida, esta asociación normalmente puede ser transferida directamente en m a asociación extendida entre objetos.

Trabajando con /os objetos de an&isis

Cuando se trabaja con el desarrotlo del modelo de análisis, normalmente se está trabajando con un use case a un tiempo determinado. Así , para un use case especifico, se identifican objetos interfaz, objetos entidad y objetos control antes de continuar con el siguiente use case.

Esto significa que cuando un conjunto de objetos ya existe, estos pueden ser modificados para probar también el nuevo use case. La meta es formar una estructura tan estable como sea posible, reusando tantos objetos como sea permisible.

Es mejor describir el rol de cada objeto y el comportamiento de las responsabilidades que se ocupan de los otros objetos.

Cuando los objetos han sido identificados y descritos, se puede expresar ta manera en que los objetos se ofrecen el use case; no tan folrrnatmemte como especificar qué estimuto será enviado entre los objetos, pero si en una forma más prosaica. tnicialmente, con frecuencia, creamos una vista use case de los objetos mostrados tat y como serán usados en et use case. Se puede describir también el use case en términos de esos objetos para mostrar como proveen el use case.

13

Se ha visto aquí que el modelo de análisis no será un reflejo de cómo luce el dominio del problema.

Subsisfernas

Cuando tos objetos de análisis han sido identificados, et sistema contendrá un gran número de objetos, estos objetos necesitan ser colocados en grupos. Esto puede hacerse en uno o varios niveles dependiendo det tamaño d e l sistema. Tales grupos de objetos son llamados subsistemas. Asi el sistema consiste de un número de subsislemas, que a su vez contienen subsistemas. At finat de ta jerarquía están los objetos de anátisis. Así los subsisternas son un manera de estructurar el sistema para mayor desarrollo y mantenimiento.

La tarea de los subsistemas es empacar a l o s objetos y por tanto ta complejidad se reduce. Los subsistemas tamMn trabajan como unidades administradoras en ta organización, por ejemplo, al desarrollo, mercadeo, ventas, y entrega.

El nivel mas bajo de un sistema puede ser visto como unidades que cambian, y son llamadas servicios empaquetados. Estas serían vistas como atómicas; si ef diente tas quiere las tendrá completas, en otro caso no tendrá nada. Cuando el sistema está sufriendo urra cambio menor, este cambio no concierne mas que a cada subsistema, o a los objetos contenidos en ese sistema.

La divisitm en subsistemas también será basada en la fmcionatidad det sistema. Todos los objetos que tengan una fuerte unión funcional mutua serán colocados en el mismo susbsistema.

Para identificar los objetos con una fuerte unión mutua, se puede empezar por un objeto y estudiar su entorno. Otro criterio para la división es que debería haber una pequeña comunicación entre los diferentes subsistemas tanto como sea posible.

Después que tos subistemas opcionales han sido identificados, y con frecuencia permanecen esos objetos que son centrates at sistema tienen que ser siempre entregados. Para distribuirlos entre los diferentes subsistemas, se necesita mirar la funcionalidad del sistema.

Existen varios criterios similares que son utilizados para decidir si dos objetos son fuertemente relacionados de manera funcional. Sigue una lista de algunos de ellos:

Serán los cambios de un objeto principal los cambios de otro objeto? Se comunicarán con el mismo actor?

o Ambos son dependientes de un tercer objeto, como un objeto interfaz o un objeto entidad? 0 Un objeto realizará varias operaciones en otro?

El propósito es tener una fuerte unión funcional con un subsistema y una unión debil entre subsisternas. Un buen comienzo es empezar por colocar el objeto control en un subsistema, y posteriormente colocar una unión fuerte de objetos entidad y objetos interfaz en el mismo subsistema.

Cuando la división dentro de los subsistemas está hecha, en algunos casos tambi6n puede ser deseable modificar los objetos de análisis. Este puede ser et caso, por ejemplo, cuando un objeto entidad tiene comportamiento separado que está reteeionado funcionalrnmte a un subsistema. Si este comportamiento es extraído, puede ser fácil colocar el objeto entidad en un subsistema.

La división de subsistemas en proyec€os pequeños se hace normalmente al final del análisis, cuando la arquitectura está clara. En proyectos mas grandes, sin embargo, con frecuencia debe

14

ser realizado anticipadamente, en muchos casos, antes que et mocieto de anátisis haya sido desarrollado. Para grandes proyectos se tienen otros criterios para la divisibn en subsistemas:

o Diferentes grupos de desarrolladores ttemn chferertte gmdo de competencia o recursos, y puede ser deseable distribuir per corisiguieftte el trabajo dftt desamlio (¡os grupos también pueden estar geogrzkficantente separados) O En un entorno distribuido, un subsistema puede ser deseado como un nodo lógico

1.2.4 Diseño del Sistema

El diseño es un proceso el cual determina de manera efectiva, eficiente y costeable una impiementación para llevar a cabo }as funciones y el almacenamiento de datos definidos en el análisis del dominio.

Objetivos

Durante el diseño, se seleccionan las computaduras apropiadas, fuentes, servicios de software, software de sistema, unidades de software y estrategias de almacenamiento de datos requeridos para el desarrollo de un sistema.

Avances

El diseiio iniciado en el análisis es la parte central del modelo de diseño. Este añade los siguiente:

0 Descripciones de la Arquitectura, las cuales capturan la mayoría de las decisiones del diseño tates como la elección de procesadores, manejadores de bases de datos, sistemas operativos, lenguajes, entre otras cosas 0 Descripciones de Versiones Ejecutabtes, las cuales definen los puntos de contenido de las versiones ejecutabtes que sucesivamente se implementarán, enfodndose a ta prueba de diseiio y requerimientos 0 Diagramas de Categorías de Clases, aquí el modelo particiona el sistema en grupos de clases y objetos 0 Diagramas de Diseños de Clases, los cuales muestran las abstracciones de la implementación física, detallando los tipos de datos y estructuras, además del mapeo de las abstracciones lógicas hacia las abstracciones físicas 0 Diseño de Diagramas Objeto-Escenario, el cual muestra las operaciones lógicas detalladas que lleva a cabo una funcibn, incluyendo el uso de objetos fisicos 0 Nuevas especificaciones que sopadan esos diagramas 0 Compensaci6n de Especificaciones de Clases, muestran todas las operaciones y las espe&i-ficachries con algoritmos complejos, las implantacibn de relaciones y la tipificacibn de atributos

Pasos

Los siguientes pasos son ejecutados durante e¡ diseño:

Determinar la Arquitectura iniciai, inciuye la torna de decisiones sabre las fuentes de irnplaprtacidn de alto nivel y sus servicios, las categorías de clases que serfin utilizadas, y las versiones ejecutables que seran ejecutadas 0 Plan para Versiones Ejecuiabies, ei cuai incluye ia definición de ¡as versiones ejecutabies 0 Desarrollo de versiones ejecutables, inctuye el desarrollo de clases, detaiie de las operaciones y decisiones sobre acceso publico o privado a t o s objetos 0 Refinación del diseño, incluye una documentación de los que se ha obtenido de las versiones ejecutables y la modificacion det diseño para conocer cualquier requerimiento de ejecución

Ai igual que el anbtisis, el diseño es un proceso interactivo que se implementa. Durante el diseiío, se puede esperar regresar al análisis cuando se descubren ambigüedades u omisiones en el modeto de anátisis. También será necesario iterar a traves de los pasos de diseño varias veces, tantas como nuevas versiones se realicen u se integren partes del sistema, o se añadan versiones ejecutables para construir un sistema más compieto.

Participantes

EI disefio es una ciencia que requiere Ingenieros que tengan conocimientos de aspectos técnicos de desarrollo de software, diseiio y programación orientada a objetos. Deben estar familiarizados con todos los servicios y con la programación y ambientes operacionaies.

Los clientes y los expertos de¡ dominio no SOIT los principales participantes en e¡ diseño, pero deben ser capaces de proveer tos detalles finates en et dominio, que se necesita durante ie diseño lógico, para probar y utitizar versiones ejecutables, para realizar cualquier trato que sea necesario con tos requerimientos contra la ejecucibn, así también para ayudar en el regreso de iteraciones a través del análisis que seguramente ocurrirá.

1.2.5 Construcci6n

El proceso de construcción continúa hasta que el código es comptetado y tas unidades incluidas han sido revisadas. La construcción consiste de Biseiio e Implantacion.

Hay tres razones principales para tener una fase de construccion:

1) El modelo de anatisis no es suficientemente formal. Con el tin de cambiar el c6digo fuente, se deben refinar los objetos: ¿qué operaciones deberian ser ofrecidas?, exactamente jcbmo deberia ser la comunicaci6n entre los diferentes objetos?, ¿qué estímulos son enviados?

2) Et sistema actual debe sef adoptado pof la impiemef-itaciun del &sfno. En el anhtisis se asume un mundo ideal para el sistema Esto sifpnifia que se debe tramformar inieiaimente e¡ r n ~ ~ W o de anidisis de- el espacio del an&& a un espacio COR todavia mas dimensiones. Por ejemplo, se deben considerar los requerimientos de realimackjn, requwimientos de tiet-np real y concurrencia, software de sistema, les propiedades det tenguaje de programaeidn, el sistema administrador de bases de datos we BS usado.

3) Queremos validar los resu!tadcs de! amiliss. Como el sistema e s t i creciendo y formalir-, se verA c6mo el modelo de an5Esis y el modelo de requerimientos describen el sistema.

Los cambios en la arquitectura del sistema para el mejoramiento del rendimiento será pospuesto aunque el sistema est6 siendo construido.

Qu6 es lo que se realiza en la fase de construccjbn?

La actividad de construcción produce dos modelos, et Modeio de Diseño y ei Modeio de impiementación. El modelo de diseño es un mejor refinamiento y formalización que el modelo de anatisis, donde tas consecuencias del entorno de imptementación han sido tomadas en cuenta. €t modeto de imptementación es la imptementación actual (codigoj del sistema. Para desarrollar el modelo de diseiío se realizan tres pasos principales:

I) ldenfificar el entorno de implemenfacibn. Este paso incluye identificar e investigar qu6 consecuencias tendrá en el diseilo et entorno de implementación. Aquí todas las decisiones de implementación estratégicas deben ser realizadas. Este trabajo apunta a dibujar conciusiones de cómo estas circunstancias seriari tnanejadas en ei sistema. Este paso puede (y debe) ser hecho de forma parateta con et trabajo de anidisis y estar listo cuando et disefío aduaf comience.

2) Incorporar éstas eonciusiones y desarrollar una primera apmximaei6t? para un nmfeio de diseilo. Aquí se usa el modelo de análisis eor~?o una base y, traduce los objetos de análisis en objetos de diseiio en et modelo de diseiio que adapta el entorno de implementación actuat. Desde una perspectiva de proyecto, éste podria ser incorporado directamente en el modelo de análisis, pero para mantener los propósitos y el entendimiento esto no es recomendable.

3) Describir c6mo los objefos inferacfkm en cada use case específico. Aquí el modela de diserío está formalizado para describir todo envío de estímulos entre los objetas y también definir qué harA cada operación a cada objeto. El modelo use case será de gran ayuda durante este trabajo y ayudar& a especificar cada flujo específico en el sistema de forma detallada. Este paso provee los objetos interfaz.

N Modeb de Diseño

El modelo de diseño será compuesto de bloques los cuales son los objetos de diseño. Estos conformarán la estructura actual del modeto de diseño y muestran cómo está diseñado el sistema. Estos bloques serán implementados más tarde en el código fuente.

Los bloques abstraefin la implementación actuat. La implementación de los bloques debe ser una clase especifica en el código fuente, esto es, un btoque es implementado por una clase. Sin embargo, con frecuencia un bloque es imptementado para varias ctases distintas. Los bloques son por lo tanto una manera de abstraer ei c&igo. El ntvei módulo del lenguaje de programacidn se denota por el término genérico m6dulo objeto.

El primer intento del modelo de diseño puede ser hecho mecanicamente basado en el modelo de análisis. La transformación está hecha de antemano, por to que tnictatmente cada objeto de análisis llega a ser un bloque. Esta regta be tramfomaeien significa que se obtiene un claro mapeo (traceability) en los modelos.

Como cada objeto de análisis es mapeado a un btoque, tos cambios introducidos al modelo de análisis serán locales en et modelo de diseño y ,así tambidn en el código fuente. S e puede notar que el mapeo es individual. Et mapeo es una propiedad demasiado importante en el desarrollo del sistema.

Aquí se tiene la gran ventaja del mapeo; se puede encontrar fácilmente la manera en fa cual el sistema haya sido sujeto a cambios mayores. Es también importante tener una gran localidad funcional (es decir, una gran cohesión) para conocer qué cambios ejercerán influencia sobre grandes partes del sistema.

El primer intento del modelo de diseño, es simptemente asignar el mismo modelo al modelo de anátisis. Para diferenciar entre estos dos modelos, se usará otra notación y se dibujarán como rectángulos en lugar de símbolos.

La semántica det modeto de diseño es algo diferente a ta del modelo de análisis. El modelo de análisis es desarrollado en términos lógicos y sálo es una figura conceptual del sistema que será construido.

La semánticas de los bloques reflejarían la semántica de los objetos existentes en el sistema actual, e igualmente, tas asociaciones entre {os objetos reflejm’an también como los objetos en el sistema son relacionados realmente.

El modelo de diseiio permite reducir la complejidad del sistema. Los bloques son actualmente un mecanismo de abstracción para el código fuente, esto significa que es más fácil construir un sistema correcto que eluda errores debidos a la complejidad.

El Entorno de Implementacidn

Para adaptar et modelo de diseño ai entorno actual de imptementación, primero se deben identificar las restricciones técnicas actuales bajo tas cuates sera construido el sistema. Esta identificación puede (em realidad debe) ser hecha eon anteriofidad, ideatmnte antes de que el modelo de artidisis sea desarrollado, ya que afecta que tan lejos está el modelo de análisis de ser refinado.

Trabajando con la Consfruccidn

La mayoria de veces, el diseno debe adaptarse en el ambiente real en el cual el sistema trabajará. Todas tas corrdiciones para la impternentación surgen de atgún lugar en la fase de análisis la cual se Ham6 ambiente de implementación.

El ambiente de imptementación también incluye requerimientos que pueden ser delineados en la especificacih de fequerimierttos en la f o m de ejecutar requerimientos y en tas fuentes existentes. Así tmtsih l e s requerimientos que el sistema puede usar de otros sistemas son también incluidos en el ambiente de implementación.

Productos Existentes

Un requerimiento común de¡ ambiente de imptementación es que el sistema debe utilizar productos existentes. Un caso puede ser que et producto existente es et mismo sistema pero en una versión anterior o el otro caso es cuando se construye otra (un nuevo) sistema que solo hace uso del pwdudo existente . Para construir con componentes muy diferentes tat solución se utilizarán componentes que son usados cornu poderosas unidades que son combinadas dentro de los objetos. El utilizar un producto existente es diferente; aquí, primeramente se hace un análisis del producto y se adapta el diseno a él.

18

Se debe realizar una comparación cuando se quiere utilizar un producto que ya existe y no forzar la adaptación del diseño a éI o realizar una comparación cuando no se utiliza el producto existente y se decide desarrollar una implementación que tenga la misma funcionalidad que el producto existente.

Un problema común, es cuando se quiere desarrotlar un sistema que no ha sido diseñado de acuerdo al metodo de orientación a objetos y que esto imptica grandes adaptaciones ai sistema existente. Este problema es complicado y requiere mucha reingenieria.

Uno de los criterios más importantes cuando se decide si se debe utilizar un sistema etaborado anteriormente o desarmltar un nuevo sistema, es considerar los costos de prueba. Otra decisión importante es saber qué tan bien se conocemos el productos existente y cuántos recursos son necesarios para conocerlo a fondo. De otra manera puede tomar mucho tiempo, especiatmente si la documentación es pobre, antes de que se haya aprendido cómo utilizar este producto.

Temas Adicionales

Se han descrito las fases de análisis y construcción. Esta presentación ha sido una vista para mostrar las partes principales de cómo se reatiza este proceso. Adicionalmente a las simplificaciones que se han hecho, se pueden mencionar las siguientes:

.r Las reglas de documentación han sido totatmente ignoradas. En situaciones reates se requieren algunas reglas. En proyectos reates se utilizan documentos de instrucciones para especificar esas reglas. Existen diferentes documentos de instrucciones para diferentes tipos de actividades.

La discusión sólo refleja el método, tos temas retativos a procesos son omitidos. En un desarmtlo reaf, por supuesto que existen muchas mas interacciones entre las diferentes partes. 0 Otras actividades toman lugar dentro de estas diferentes fases, como la coordinación de configuración y revisioms. Estos temas son extremadamente importantes en desarrollos reales.

1.2.6 Especialización de la Base de Datos

Desde que el usuario de la Base de Datos no se preocupa par c h e se almacena ia información utiliza un administrador de bases de datos (DBMS: Data Base Management System) que se encarga de esto. Et prugramador de aplicacbrres scito quiere una vista túgica de la base de datos y no tomar parte en tas decisiones de ctimo se reatiza et almacenamiento fisico. Esta es una propiedad importante de un DBMS. Otras características que un DBMS provee son: Concurrencia, Recuperación ante fallas y Facilidad de consultas.

La especiatización de una base de datos sigmfica que un producto DBMS está integrado al desarrollo de un sistema. Algo que es evidente es que un DBMS puede ser utilizado en un desarrotlo, así como en ta especificación de requerimientos det sistema. Si esos requerimientos no existen, se necesita descubrirlos mediante el modelo de requerimientos.

Típicamente las propiedades que indican la necesidad de tener un DBMS son:

* Información que necesita ser persistente

19

* Más de un aplicación compartiendo datos * Estructuras de información con gran número de estancias * Una búsqueda compleja en la estructura de ta infomacibn * Generación avanzada de reportes de la información almacenada * Manejo de transacciones de usuario * Una lógica necesaria para la reiniciación del sistema

Así mismo, los requerimientos y modelos de aniitisis deben ser estudiados para decidir cuáles objetos deben ser persistentes. Desde que un objeto entidad maneja información que sobrevive a los use cases, el objeto entidad es uno de tos mayores candidatos para el atmacenarniento persistente. En algunas aplicaciones también se necesita almacenar otra clase de objetos, como objetos que mf~fteja~ configuraciones de hteFfaz. Aún st la infwmación no sobrevive a diferentes ejecuciones, puede necesitar de un dmaeenamiento secundario. Este es un caso típico en el que et número de instancias es muy grande comparado con el espacio de memoria principttt. La forma para Fesolver esto, es utilizar et sistema de archivos o usar un DEfMS, sin embargo, la integraci6n principal del trabap es realizada en el proceso de construcc%n, ahí se decide cómo el DBMS debe ser incorporado al modelo de diseno y al modelo de implementación.

Un DBMS debe de conjuntar un número de topicos tates como: Jerarquía, Redes, Modelo relacional y además bases de datos orientadas a objetos. €t tipo dominante de aplicaciones de la industria de hoy en día es el modelo relacional.

DBMS Relacional

En una Base de Datos Relacional la informacih es almacenada en tablas. tos tipos de datos utilizados en tas tablas son: Caracteres, Enteros y tipos Primitivos. Existen problemas para el almacenamiento de objetos. Primeramente sólo los datos pueden ser almacenados y no su comportamiento, a continuación sólo datos primitivos pueden ser almacenados y no estructuras complejas.

Cuando la programación es conectada a un DBMS. Surgen vanos problemas. El primer problema es que todo et sistema y toda la información es atmacenada en objetos. Ademas se requiere transformar ta estructura de informacibn de objetos a una estructura de tabla orientada. Este pFoMema atgumas veces es llamado como pf&tema de impedancia. Tal problema ocurre cuando et pfogr?ma t h e un conjunto de tipos Mktyendo a q t t e t t o s creados por et usuario. Todos estos tipos deben ser convertidos a t o s datos mas primitivos del Manejador de Bases de Datos Relacionales (RDBMS).

El problema de impedancia surge de otro problema, cuando se crea un fuerte acoptamiento entre la aplicación y el DBMS. Para hacer que et diseño se afecte por el DBMS, pequehas partes del sistema deben conocer la interfaz del DBMS tanto como sea posible.

Un tercer problema es cómo expresar la Herencia en una base de datos. Desde que todos los objetos son persistentes el comportamiento de persistencia se hereda tambibn. Así mismo, existen similitudes entre las estructuras de datos y la habilidad para ser persistente.

Otros problemas incluyen el cómo almacenar las operaciones, tas vistas de transacciones, asegurar las bases de datos durante transacciones que duran largo tiempo, y las bases de datos distribuidas. Los problemas de integridad entre la memoria principal y la base de datos deben ser soportados.

A continuación se presentan algunos puntos para dar solución a los problemas mencionados con anterioridad.

20

Objetos dentro de las Tablas

El primer punto a realizarse es decidir cuáles clases y cuáles variables de la clase deben ser almacenadas en la base de datos. Cada una de estas ctases posteriormente será representada por un tabta (o más de una) en ta base de datos. Una clase es mapeada hacia las tablas de la siguiente manera:

Asignar una tabta para la clase Cada atributo primitivo se convertira en una columna en la tabla. Si el atributo es complejo debemos añadir una tabla para cada atributo o descomponer ei atributo en varias cotumnas de la tabla de la clase La columna de la llave primaria debe se el tínico identificador de la instancia llamado identificador, por medio del cual la instaneia es reconocida de manera Bnica Cada instancia de la clase se representarb ahora por un rengldn en esta tabta Cada asociacibn de agregacidn con cardinatidad mayor a uno se convertir& en una nueva tabla. Esta se conectará a las tablas que representan a los objetos que serán asociados. Las llaves primarias de estas tablas pueden ser utilizadas para esta tabla de agregación.

Los objetos que pueden ser persistentes deben ser mapeados de las tablas a la base de datos. Si las clases se heredan de otra, existen dos maneras principales de resolver esto:

1) Los atributos heredados son copiados a todas las tablas que representan tas clases

2) La ctase abstracta esta en una taMa de su propiedad para las cuales las clases descendientes, ninguna tabla puede representar un clase abstracta

descendientes hacen referencia

DBMS orientado a Objetos

La idea de un DBMS orientado a objetos (ODBMS) es almacenar los objetos como tales, y por lo tanto enlazar todas las bases de datos. De esta manera no se ejecutan joins lentos para accesar a un objeto en espeeifico. Debido at almacmamiento de tos objetos como instancias, es posible explicar las semánticas de esos objetos de una mejor manera que m t o s sistemas relacionales. Esto implica que un ODBMS es muy utitizado en apticacimes donde los objetos complejos deben ser persistentes. La mayoría de t o s ODBMS comerciales no utilizan un lenguaje de manipulación de datos en específico para almacenar y recibir información.

Así mismo, el probtema de impedancia es eliminado comptetamente. Esto también significa que el disefto de la base de datos es integrado durante el análisis y diseño de la aplicación. Los criterios existentes para un ODBMS son los siguientes:

a) Objetos complejos. Deben soportar la noción de objetos comptejos b) Objetos identidad. Cada objeto debe tener una identidad independiente de sus

c) Encapsutamiento. Debe soportar encapsulamiento y comportamiento en los objetos d) Tipos o clases. Debe soportar un mecanismo estructurado en ambos caws en la

e) Jerarquias. Debe soportar la noción o el concepto de herencia 9 Unidn retardada. Debe soportar la uni6n retardada g) Completo. El lenguaje de manipulacidn debe ser capaz de expresar cualquier funci6n

valores internos.

forma de tipos o clases.

computable

21

h) Extensibilidad. Debe ser posible agregar nuevos tipos

Así mismo, los mayores beneficios de usar un ODBMS incluyen:

1) Los objetos como tates pueden ser atmacenados en una base de datos 2) No se necesita conversión para el tipo de sistema de DBMS, el usuario define

clases que son usadas como tipos en el DBMS 3) El lenguaje del DBMS puede ser integrado con lenguaje de programación

orientado a objetos. El lenguaje puede ser incluso exactamente et mismo que el usado en la aplicación lo cual no obliga al programador a tener dos representaciones de sus objetos.

1.3 Lenguaje de Modelo Unificado (UML)

1.3.1 Generalidades

El UML (Unified Model Language: Lenguaje de modelo unificado) es un método de tercera generación de análisis y diseño orientado a objetos desarrollado por Grady Booch y Jim Rumbaugh.

Modelo, Lenguaje e Informaci6n no interpretada

El propósito de un modelo es representar la semántica, los detattes físicos, y la visuatización de un análisis, diseño, o implementación. En este Metamodelo se inctoyen conceptos que generalmente son utilizados en muchos problemas y muchos lenguajes. Por to tanto, muchos de los conceptos det UML son genéricos pero atgunos son induidos para permitir expresar programas en un lenguaje de alto nivel. Los conceptos dependientes del tenguaje no serán significativamente n m f i o s en todos los lenguajes y podrían no ser requeridos donde no sean utilizados.

Algunos de tos aspectos del lenguaje más intensivos de un modelo, como la sintáxis de tipos, operaciones, expresiones, etc., están basados lingüísticamente y tuvieron poco significado al tratar de integrarlos en el Metamodelo.

Clases de elementos

Elemento es un nombre genérico para cualquier clase de elemento que se encuentre dentro del modelo. Cualquier elemento puede tener un conjunto de Propiedades, indexada cada una por su nombre. El conjunto de propiedades es sencillo. Los valores de las propiedades representan un mecanismo de extensión generico para aiiadir semhntica al Metamdeb. Los elementos pueden ser divididos en : Elementos sujeto y Elementos vista. Los Elementos sujeto añaden semántica e información fisica al modelo; eltos proveen el ‘Contenido”. Los Etementos vista proveen una visualización de la información contendida en diagramas así como formularios, reportes, formatos de intercambio, etc.

Elementos Lbgicos

22

Un Elemento Lógico es un nombre genérico para toda semántica que modela clases a cualquier profundidad. Esto incluye clases, estados, use case, etc. Un Elemento Lógico depende de otros elementos lógicos.

La asociación Dependencia está propuesta para representar todo tipo de dependencias entre elementos, incluyendo dependencias estructurales (tales como: Subctases, Atributos de clases, Asociaciones), dependencias de procedimiento (tales como: Un método que tenga argumentos o variables bcales de un tipo, instanciar objetos de una ctase, o recuperar o desechar instancias de clases excepción), o dependencias de modelo (tates corno: un elemento, c m 0 un tipo cadena conteniendo et nombre de un tipo el cual debe ser actualizado si el nombre del tipo ha sido cambiado).

Una Restricción es una relación semántica arbitraria entre elementos lógicos. Esto representa alguna semántica que el Metamodelo no puede proveer explícitamente.

Resfricciones, Notas y Propiedades

Existe m a cierta simititud entre Restricciones, Notas y Propiedades. Las Natas son comentarios de texto colocados en los diagramas, por lo tanto, son Elementos vista. Una Restricción es texto con atguna semántica implicada (pero no especificada) que va en Etementos sujeto, pero no en una vista particular. Una Propiedad es un nombre añadido a cuatquier clase de etemento, para toda ctase de propósitos tales como: generación de código, formate0 de íconos, extensiones de usuarios, etc.

Elementos Principales y Categorías

Una categoría es la unidad organizacional de elementos lógicos. Una Categoría “admite“ elementos modeto, cada elemento debe pertenecer a exactamente un categoría. Las Categorías contienen etememtos Pflncipales. Un Elemento Principal es cualquier etemento tógico que pueda ser directamente “admitido” por una categoría, esto es, esos etementos tógicos no son parte inherente de algún otro elemento. Los elementos Prirrcipales incluyen clases y otro tipo de declaraciones, asociaciones y restricciones.

Composiciones

Una clase define un contexto conceptual en el cual instancias de otras clases y asociaciones pueden ser usadas. Una clase define una relación de agregación conceptual e implícita a sus comporrentes, t o s cuates incluyen atributos, objetos, tigas. Las definiciones de clases y las asociaciones deben estar dentro de una clase si aparecen sólo en el contexto dado.

Una clase cuyas partes son atributos simples se llama Composición. Las componentes de una clase compuesta son distintas instancias de varias ctases y asociaciones. Cada instancia es un objeto en el contexto de una instancia de la clase cerrada. Cada objeto en una clase puede tener su propio nombre local en la composición y asociaciones “ah doc” con otros objetos internos.

Tipos

Los Tipos tienen una gran cuidado en tos lenguajes de programación pero son muy dependientes del lenguaje. El modelo pretende ser capaz de inctuir los tipos de lenguajes de programación en el modelo para que los usuarios puedan declararlos y usarlos.

23

Un ClassDecl es la declaración de un ctase, el tipo prevalente de la declaración bajo el paradigma de orientación a objetos. Note que algunas dases, como las instancias templeteadas de C++ no son ClassDects, porque ellos no introducen un nuevo nombre sencillo, pero construyen un nombre de la declaración existente como “expresiones nombre”; ellos tampoco declaran estructura adicional.

Tipo de Clases

Existen tres tipos básicos de clases: SimpleClass, una clase que declara una nuevo nombre y un nueva estruetura ta cual puede ser utitizada como et tipo de un variable o un parámetro; Templateclass, una clase que declara un nuevo nombre y un estructura la cual puede ser instanciada para producir una InstantiatedChss que puede ser usada como el tipo de una variable o como un parámetro.

Componentes de las Clases

Una clase es et concepto mejor conocido de la orientación a objetos que mapea todo lo orientado a objetos a muchos otros lenguajes. Una utilidad es una clase falsa que encapsula atributos y operaciones que no son parte de un clase, mmo variables gtobales y procedimientos. Colocar estos elementos en las utilidades ayuda a organizarlos.

La declaración de un clase incluye una lista de atributos y una l i s t a de operaciones. Todos los miembros tienen nombres (definidos con el alcance de ta clase) y alcance, el cual es un alcance de instancia (un valor por instancia) o un alcance de clase( un valor por clase).

Una propiedad de diseiío de un atributo u operación es su visibilidad, esto es, quien puede verlo: cualquier ctase (púiwim), subclases(protegido) ó solo métodos directos de la propia clase(privada). Esto es et “acceso tógico” usado para la generación de código. Los atnbutos tienen tipos y las operaciones tienen listas de pari%metms y resuttados. Las operaciones tienen especificaciones no interpretadas de las cuales las condiciones pre y post son un ejemplo.

Las propiedades de diseño para los atributos incluyen acceso que puede tener el sujeto de una clase externa (teer y/o escribir) con su visibilidad; la clase siempre tiene acceso a lectura/escritura de sí misma.

Las propiedades del lenguaje: un atributo tiene un vator inicial no interpretado necesario particularmente para los atributos alcance-ctase; para los atributos alcance-instancia, este valor puede ser usado para generar constructores.

Una operación tiene un cuerpo, el cual es obviamente texto dependiente del lenguaje.

Las clases deben ser asociadas con un conjunto de responsabilidades.

Relaciones entre Clases

Las relaciones están definidas en las clases, tas cuales incluyen: clases simples, templeteadas, clases instanciadas y utilidades. Los dos tipos de relaciones son: Generalización y Asociación.

Una Generalización es la relación entre una superclase y sus subclases. Una clase puede participar en más de un generalización como una superctase; ta generalización imptícita tiene el mismo alcance que la superctase aunque la información de sus subclases puede ser distribuida en muchas categorías.

24

Una clase puede participar en muchas generalizaciones como una subclase; esto es Herencia múltiple y las generalizaciones de la superclase son ordenadas para cualquier subclase.

Una Asociación es una relación entre clases que implica un conjunto de conexiones entre instancias de las ctases. Una Asociación tiene un nombre y puede estar marcada como derivada. Mucha de la informaci6n de una asociación está en sus roles. Una Asociación puede tener dos o más roles. Una asociación con dos roles es un Asociación Binaria que resulta ser el tipo más común.

Un Rol es simplemente el fin de un asociación cuando se junta a una clase. Una asociación puede tener rotes múttipies con la misma clase; cada urn es distinta. Los roles tienen muchas propiedades posibles, atgunas de ellas son genéricas y la mayoria de ellas son específicas del lenguaje.

Las propiedades del diseño de asociaciones incluyen navegabilidad , la cual indica que la asociaciún puede ser recorrida desde el rol dado hasta tas otras clases; esto es utilizado para generación de código de apuntadores y métodos de acceso.

interfaces

Una lnterfaz es una manera de subcolocar el acceso a una unidad organizacional para asignar nombres a vanos subconjuntos de items. Entre otras cosas, una interfaz refiere el concepto de un protocolo.

Una Unidad Exportable es una categoría ó un subsistema. Una unidad puede tener muchas interfaces, cada una con un nombre cuyo alcance es la unidad. Una inteffaz describe un conjunto de items exportables, los cuales son clases, operaciones y otras cosas.

Diagramas objeto

Los diagramas objeto contienen ejemplos de estructuras instanciadas, dinámicas o estáticas. Un diagrama objeto es la correlación de una diagrama de ctase; muestra un instancia de una configuraci6n particular de objetos, tigas, y valores. Estan cuantificados en “snapshots” (el término escenario es usado cuando ellos contienen información dinámica, como mensajes). El comportamiento sobre tiempo o el comportamiento condicional puede ser mostrado cum0 un serie de “snapshots”. Un diagrama mensaje objeto muestra el flujo de mensajes con un diagrama objeto sobre tiempo; esto muestra el comportamiento de un sistema distribuido de objetos concurrentes o el flujo de procedimiento de controt con un sistema de objetos secuenciales. Los diagramas de mensaje objeto están cuantificados en escenarios.

Un escenario es un “snapshot“ con la adición de mensajes . Un mensaje representa una llamada a procedimiento o el flujo asíncrono de control desde un emisor.

Un mensaje puede ser de varios tipos, incluyendo asincronos (una sota fuma de evento entre objetos concurrentes) y llamada (un procedimiento síncrono llamado por et emisor del receptor, con un regreso implícito obedeciendo las regtas anidadas de pmcedimiento usuat). Un mensaje tiene un nombre (el nombre de la operación o evento), una lista de argumentos(1os argumentos del procedimiento o evento), y resultados opcionales no interpretados.

Un Diagrama de Trazo de Mensajes muestra tos detalles completos de un escenario como flujo de mensajes sobre tiempo. Un Diagrama de Trazo de Mensajes y un Diagrama Mensaje Objeto son isomórficos, aunque en un Diagrama de Trazo de Mensajes las activaciones

25

individuales (regiones de control ) se manifiestan visualmente mientras que son implícitas en el diagrama de mensaje objeto.

Las activaciones del procedimiento actual son modeladas como objetos Activación. Cada activación representa una llamada particutar de un procedimiento particular en un contexto particular; esto es un viejo concepto en la ciencia de la computación. Cada mensaje es asociado con un objeto activación,; cada activación llama (en orden) cero o más métodos.

Modelo de Estados

Los conceptos fundamentales son Estados y Eventos. Los Estados estan definidos en el modelo de estado; tos Eventos deberían ser definidos por un modelo de clase, aunque aún son eventos, y no clases fundamentalmente.

Los Estados pueden tener nombres opcionales. Los Estados inicial y final son tratados como casos especiates de estados ordinarios, aunque eltos tienen semántica restringida y deberían ser considerados como falsos. Los Estados deberían ser anidados.

Ciertos Estados “falsos” juegan roles formales. Estin indicados por la propiedad claseestado que es algo así como Normal. Un Estado inicial indica el estado de inicio por omisión para una transición en el perímetro circundante; debe tener una transición sin etiquetar a un estado normal. En el nivel extemo indica el estado de inicio por omisión para un objeto creado recientemente; et estado inicial debe tener varias transiciones, cada una etiquetada por un mensaje de creaciitn. Un Estado Final indica que ta ejecuckjn dei perímetro circundante termina o (en un nivel externo) el objeto se termina a sí mismo.

Un Evento tiene un nombre (cuyo alcance es el diagrama de estado) y una lista de parámetros. Los eventos son añadidos a las transiciones. Las Transiciones deberian tener también expresiones de condición, efectos y marcas de tiempo. Una expresión de condición es un expresión no interpretada en el lenguaje o pseudocódigo; es evatuado cuando el evento ocurre y [a transición se dispara sólo si es verdadero. Un Efecto es una AcciónlActividad o un Enviar- Claúsuta. Una Acción/Actividad es una expresión no interpretada que es ejecutada cuando la transición se dispara; debe ser expresada em términos de expresiones del objeto y del evento disparado. Una acción Enviar-Claúsuta es un tipo especiat de interacción: designa mandar un evento a un &stirto (una expresión no interpretada designa urn conjunto de objetos destino) y una lista de valores para los parámetros del evento.

Una transición también debe de tener una Marca de Tiempo que asigne un nombre al tiempo en el que la transición se dispara o (en caso de un sistema distribuido) es recibido por el objeto. Las marcas de tiempo pueden ser usadas en restricciones de tiempo en la máquina de estado.

1.3.2 Diagramas

Un Diagrama es una proyección sobre los elementos de un modelo; los mismos elementos pueden aparecer en múltiptes diagramas. Un diagrama dado puede presentar algunos - pero no necesariamente todos - de los detalles de cualquier elemento particular.

Los diagramas son los primeros artefactos que tos desarrotladores usan cuando manipulan modelos. Sin embargo, alguna información modetada es más conveniente manipularla usando tablas o texto, por to tanto una herramienta para edición de modetos podrían necesitar soportar figuras y un tipo de sernrjntica plana, la cual provee formas y notación textual para complementar las figuras.

26

Los autores definen el formato externo de los diagramas. En UML existen varios diagramas que son centrales:

0 Diagrama de clase 0 Diagrama Use Case 0 Diagrama de Trazo de MensaJes 0 Diagrama de Estados

Se definirán sus características a continuación.

Diagrama de Clase

El Diagrama de Ctase es el corazón del UML. Esta vista muestra ta estructura estática lógica de un sistema: sus componentes y sus retaciones de cada uno. En su forma más fundamental, muestra los elementos componiendo el estado de un sistema, es decir, esas elementos que deben ser recordados de momento a momento.

Los diagramas de clase muestran descripciones de posibtes sistemas y los diagramas objeto muestran instancias particutares de sistemas y su comportamiento. Los diagramas de clase contienen clases y tos dtagramas objeto contienen objetos, pero es posible mezciar clases y objetos para varios propósitos, por lo tanto la separación no es rígida.

Clases

Una Clase es dibujada como una caja rectangular sólida c m tres compartimientos, con el nombre de la dase en el compartimiento de arriba, una tista de attibutos (con tipos opcionales y valores inieiales) en et compartimiento de en medics, y una lista de operaciones (con una tista de argumentos opcionales y tipos de regreso en el comportamiento de abajo).

Afribufos y Operaciones

El compartimento de atributos contiene una lista de atributos. Su orden es significativo y puede ser usado por el generador de código, pero las herramientas pueden proveer fiftrus que despliegan listas de atributos parciales o completas (y operaciones).

El compartimiento de operaciones contiene una tista de operaciones con tas mismas consideraciones ordenadas como atributos. La componentes operación son cadenas que dependen del lenguaje.

Asociaciones

Las Asociaciones representan relaciones estructurales entre objetos de diferentes clases, información que debe ser preservada para atguna duración y no simptes retaciones de dependencia. Las instancias individuales de una asoeiación son llamadas Ligas; cada una es una tupla de referencias a objeto.

La Agregación es una forma especial de asociación mn la connotación de la relación “todo- partes”. trrdica que et tiempo de vida de las partes son &pendientes del tiempo de vida del todo. Esto no indica un tipo particular de implementación o una dirección de navegación.

27

Herencia

Es la relación taxonbmica entre una superclase y sus subclases. Con frecuencia es tlamada Generalización o Especialización dependiendo si es de tas subclases a ta superclase o desde la superclase a las subclases. Normalmente ta subclases representan las diferentes alternativas. La GeneralizaciCln es con frecuencia llamada la “ r e k i i or”. Esto es en efecto, el uso dominante de ta Herencia. Sin embargo, a&.tt?af veces m a dase pttede ser especializada en varias y diferentes dimensiortes simulttineamente; UR objeto concreto debe participar en todas las dimensiones y por lo tanto, representar un producto caftesiano de las diferentes dimensiones. Esto es llamado una “Generalizaci6n and”.

Cafegorias

Los modelos grandes requieren una organización interna, una categoría es un subconjunto del propio modeto. A cada Categoría le pertenece alguna de las ctases, asociaciones y generalizaciones del modelo así como porciones de l a s vigtas de otfo modelo y el cddigo actual. Las categofias sm puramente organizackmtes; ettas m tienen l6gica semántica, aunque pueden ser OrQanbzados mediante líneas semhticas. Las categofías timen UR impacto de alcance para definir et m b r e be un espacio. Urta categoría es dibujada como una caja rectangular con doble contorno.

Diagrama de Traza de Mensajes

Un Escenario muestra una serie particular de mteracciones entre objetos en una sola ejecución de un sistema; describe una sofa historia sin condicionalidad. Los escenarios ilustran interacciones que son irrherentes en el comportamiento fundamentat de los objetos asociados pero cuya forma no es aparente en su comportamiento aislado.

Los escerrarios pueden ser mostrados en un Diagrama de Trazo de Mensajes que muestra las interacciones entre un conjunto de objetos en orden temporat, lo cuat es bueno para entender las consecuencias det tiempo. Un dialQg0 de texto puede acompañar o reemplazar a cada diagrama.

Un diagrama de trazo de mensajes es dibujado como sigue: tos objetos (no Clases ) en una transaccibn son chbujados como líneas verhcales sótidas; sus nombres son mostrados en la parte de arriba. La linea comienza cuando et objeto es creado y termina cuando el objeto es destruido. Un evento o tffl mensaje enviado se repfe!w& como una flecha hertzontal etiquetada desde la linea det gtte manda hasta la tinea det objeto que recibe. El t b p o procede verticalmente, por to tanto las secuencias de tiempo del etfento se pueden ver fkilmente. Un objeto puede mandaf eventos simuttdneos a otros objetos; la recepción simultdnea de eventos no es signkfiicattva y puede s e r etudida. Para indicarle 8 los eventos que requieren tiempo para entregar, la linea del evento puede ser inclinada hacia abajo para que los tiempos de emisión y recepción sean distintos.

Normalmente en un pmcedimiento escenario, soto las llamadas son mostradas, los regresos son implícitos, sin embargo, tanto las llamados como 10s regresos pueden ser mostrados, lo cual puede ser útil si existe bastante recursión.

Diagramas de Est&

28

El Diagrama de Estado describe la evolución temporal de un objeto de una clase dada en respuesta a las interacciones de otros objetos dentro o fuera det sistema. Cada clase puede tener un Diagrama de Estado para describir su comportamiento dhámieo, aunque no todas las clases tienen compottamiento difthieo interesante (muchos tienen exactamente UR estado con la misma respuesta siempre). Cada diagrama de estado es asociado con una clase o con un diagrama de estado de alto nivel.

Los diagramas de estado son especificaciones formales del comportamiento de una clase. Los escenarios son ejemplos de la ejecución de un sistema. Ellos pueden envolver a varios objetos jugando varios roles. Desde que son instancias de compoftamiento, ellos itustran, pero finalmente no pueden definir el comportamiento; estos finalmente pueden ser derivados del conjunto completo de diagramas de estado. Un escenario es unit instancia de un Use Case, el cual puede ser pensado como una “rebanada” del comportamiento del sistema a traves de los diagramas de estado de clases múltiples.

Un Diagrama de Estado es una gráfica dirigida de estados (nodos) conectados por transiciones (arcos dirigidos). Un diagrama de estado describe la vida de objetos de una clase dada. Describe todas tas posibles maneras en las cuales los objetos responden a eventos de otros objetos. Normalmente los diagramas de estado deberian ser usados también por objetos que reciben eventos externos de actores que están fuera del sistema, tares objetos son usualmente “controladores“, es decir, objetos que negocian para mantener el sistema y controlar otros objetos.

Los diagramas de estado también pueden ser utilizados para mostrar la vida de objetos que parecen secuencias de operaciones que toman fundamentalmente los objetos en diferentes estados. Ettos tamM5n pueden ser utilizados atjn para mostrar l o s flujos imkrnos de control en la implemeRtaei&t de una aplicacibn, en ese easo, tos eventos eorfesponben it tlamadas a procedimiento (mensajes). Durante el análisis este nivel de detalle debería de ser eludido.

Eventos

Los Eventos son el concepto más fundarnentat en et modelo dinámico; los estados pueden ser considerados un concepto derivado. Un Evento es una ocurrencia a un punto en el tiempo; un estado es un periodo de tiempo durante el cual un objeto está esperando para que ocurra una acci6n. B&srcamente un evento es atómico, es decir, no se puede interrumpir, en el nivel dado de abstracción. Un objeto es un forma de transmisión asíncrona de información de un objeto a otro y puede tener parámetms con nombres y tipos. Muchos eventos no tienen parámetms asociados. Si no hay parámetros, la lista de parámetros puede ser omitida.

Existen dos formas de flujo de información (es decir Calf y Return), no es necesario proveer notación para ellas, porque no son fundamentales.

La transmisión síncrona es un caso especiat de transmisión asincrona y debería ser modelada como tal; en tos sistemas distribuidos no se puede contar el comportamiento síncrono de todos modos.

La especificación completa de un evento puede inctuir opcionatmente: nombre, tista de parámetms, objetos emisor y receptor, descripción de evento significativo, mecanismo de implementación, y tiempo de entrega de evento.

Aunque los eventos son mostrados como ctases en et diagrama, tienen especial semántica y deberían ser etiquetados con el estereotipo “Evento“. Los atrrbutos en el diagrama de clase son los parámetros del evento. Sin embargo, es mejor pensar en las clases como la implernentación

29

de los eventos y tratar a los eventos como una entidad de semántica distinta. Un subevento hereda los parámetros de sus antecesores y los añade a sus propios parámetros.

Estados

Cada Estado representa una periódo de tiempo durante el cual está esperando a que ocurra una acción. Un estado es dibujado como una caja redonda conteniendo el nombre del estado. Una caja de estado time dos seceiones adiebnab, una seccfún que contiem una tista de las variables estado y la otra sección que contiene una lista de las operaciones disparadas.

Una variable de estado es un atributo que es valido mientras el objeto está en el estado (o en subestados anidados), y no tiene sentido para otro.

Las variables de estado pueden ser accesadas y modificadas por operaciones eon el estado, incluyendo operaciones de entrada y saiida. Las variabfes de estado son atributos del objeto descrito por el diagrama de estados.

Subesfados

Un subestado hereda las propiedades de su superestado: variables de estado y transiciones (internas y externas). Más precisamente tas transiciones que saten son heredadas. Si un evento es recibido por un objeto en un subestado dado, todas las transiciones sobre todos los estados cercanos son potencialmente apticables. Estados Compuestos

Un estado compuesto es como un objeto compuesto: una vista de alto nivel sobre un modelo que puede ser expandido en un detafte de alto nivet. En un nivel alto un estado compuesto es un soto estado, con una o más transiciones competas y abandonadas. En un nivet expandido de detatte un estado compuesto contiene varios estados de bajo nivel respondiendo a transiciones de bajo nivel. Los eventos de bajo nivel no son visibtes en un nivel alto de abstracción. Un estado compuesto t i e n e un subestado inicial pof omisitin. Un estado compuesto puede "regresap tm wento en m estado terminal. Esto sgnifica que ta ejfxuci6~ de la secuencia principal al estado tmiwl es un equivalente detallado de recibir el evento de alto nivel en el diagrama de estado de alto nivel.

La concurrencia se presenta por la agregación: un objeto composición contiene varias partes, cada una de las cuales tiene su propio estado. El estado del objeto compuesto en conjunto es el producto cartesiano de t o s est-a$os individuales. Los autores proveen una Rotación explícita para la eoncuffencia con un estado sin usar la agregación de objetos. Los subestados concurrentes son mostrados pw ta paftkiitn de un estado en regiones con limas frustradas. Cada regitin es un estado concurrente. Cuando et estado encerrado está compteto, kay un trato para cada subestado. Una transici6n des& un subestado concurrente a un estado externo al superestado encerrado, termina alguno de los subestados en una saiida forzada. Las objetos concurrentes pueden interactuar explícitamente para mandar eventos.

Transiciones

Una Transición es una respuesta a un evento externo recibido por un objeto el cual esta en un cierto estado. Una transición puede invocar una operación y puede causar que et objeto cambie a otro estado. Una “transición externa” lleva a un nuevo estado y puede invocar una operación. Una “transielh intetna” iftvoca una operación sin causar UR cambio de estado. Las tramkimnes ttevan bes$e el estado actuat de UR ebjeto que es etegibte pafa ser desencadenado por un evento recibido por el objeto. El gattito pafa un evento incluye et nombre de un evento y una condiei6n de guardia opeionat. Et evento puede tener paráwros, tos euales deben ser t o s mismos pafa todas las ocurrendas det mimo nombre de evento. Los valores de los parámetros de UR evento están disponibles para las operaciones desencadenadas por el evento.

Una condición de guardia es una expresión booleana en términos de los parámetros del evento desencadenado, variables de estado y funciones de control de objetos. Si el evento murre y et vatw de ta expresión es verdadera, entomes la transición ocurre, en otro caso, la transición no ocurre. Et mismo nombre de evento puede ser usado por más de una transición desde el mismo estado, pero deben de tener diferentes condiciones de guardia.

Los eventos pueden ser ordenados en una jerarquía de clases. Un evento desencadena algunas transiciones que dependen de alguno de sus antecesores en la jerarquía. Los eventos que no desencadenan alguna transición en un estado simplemente son ignorados.

En principio las operaciones desencadenadas por transiciones son instantáneas. Si una transición no etiquetada time una condición de guardia, y tuego es desencademda cuando la condición ftega a ser verdadera; en la práctica necesita ser examinada soto despues que un evento ocurre desde que atgo provoque un cambio. Un estado puede tener una sola tramición no etiquetada sin m condición de guardia; esfa transición es tomada autorntiticamente cuando la actividad interna del estado es completada. Estas son ttamdas “transiciones lambda” y no son necesarias, pero permiten a los diagramas de estado ser factorizados en piezas simples que son fáciles de entender.

Durante el diseiio la información adicional deben especificarse conceptos tales como el protocolo (llamada a procedimiento, evento WS, mensaje interprocesos, señal de hardware), el canal de transporte, el tiempo de entrega y respuesta de un evento, etc.

Operaciones

Las operaciones en los objetos controladores son invocadas por las transiciones. S e les llama “acciones”; deben ser instantáneas, es decir, que no se puedan interrumpir. Pueden ser implementadas como métudos en el objeto controlador. Como métodos, tienerr acceso a los parámetros det evento desencadenado así como las variabtes de estado y otros atributos del objeto control; pueden invocar otras operaciones extendidas del objeto controlador.

Para permitir la modularización de estados, permitimos las operaciones de entrada y salida. Una “operacicin entrada” es una operación que automáticamente se reafiza cuando et estado está entrando por atguna tmsición. Una “operación satida” es una operación que es automdticamente realirada cuando el estado sale por atguna transicibn. Si una transición entra a un estado arridadu entonces todas la operaciones entrada son iniciatizadas con et estado más externo; la reversa es verdad cuando deja un estado anidado.

Actividades

Una Actividad es una operación continua con un estado que toma tiempo comptetar. Desde que tiene duración no puede ser añadido a una transición (interna o externa) pero puede ser

31

interrumpida por un evento que causa un transiciirn de estado. Alguna actividades continúan siempre y cuando terminen espontáneamente.

Si una actividad termina por sí misma, entonces una transición (lambda) no etiquetada por un estado es tomada.

Mandar Eventos

Los objetos pueden mandar eventos a otros objetos. En general, un evento puede ser dirigido a algún conjunto de objetos conocido por el objeto emisor. Mandar un evento a un soto objeto fijo (el caso mas usuatf y emitir at sistema compteto puede ser considerado como un caso especial de mandar un evento a un conjunto.

Mandar un evento es una acción que puede ser reatizada por un objeto, pero nos provee una sintaxis especial para éI porque afecta mucho el flujo de control.

Creaci4n de Objetos

Crear un nuevo objeto de una clase dada puede ser pensado como un caso especial de mandar un evento a la propia clase. Los argumentos del evento son usados para imtanciar el objeto. Cuando el nuevo objeto es creado, comienza en un estado inicial m et cual recibe el evento cfeacidn como su primer evento. Esta es ta manera como los objetos creadores pasan la información a sus creaciones.

Una clase puede tener múttiples eventos de nacimiento pusibte, aunque esto hace cosas más complicadas. El estacto inicial tendría transiciones múttrples con diferentes etiquetas de evento. El creador especificaría que evento usar.

Destrucción de objetos

Cuando un objeto alcanza un estado terminal de máximo nivel, cesa de existir (si alcanza un estado terminal en un estado anidado, entonces el estado anidado cesa de retenerlo). Como parte de la transición a un estado terminat, puede mandar un evento a otro objeto. Por conveniencia, una acción y un evento enviados en una expresión pueden ser adjuntos directamente a un estado terminal.

7.4 Definiciones Generales sobre el Diseño de Bases de Datos

Los datos son vatores numericos, alfabéticos, alfanum&ricos, etc. sin significado que al estar relacionados se convierten en información y por lo tanto adquieren significado.

Una Base de Datos es un depósito de información organizada y persistente.

Los sistemas de bases de datos cumplen con los siguientes requerimientos:

Manejo de grandes cantidades de información 0 Cuidan la seguridad de la infonnacicín almacenada en la base de datos, tanto contra las caídas del sistema como contra intentos de acceso no autorizado

32

0 Si se comparten datos, se deben evitar resultados anómalos

Manejador de Bases de Datos (DBMS)

Es un m6duio de programa que constituye ia interfaz entre los datos de bajo nivel aimacenados en la base de datos y los programas de apiicaciones y ias consultas hechas ai sistema. Es responsabie de:

0 Interacción con el manejador de archivos, el cual traduce las diferentes proposiciones en DML (Data Manupulation Language) a comandos del sistema de archivos de bajo nivel 0 lmplanfación de la integridad de la información (satisfacción de ciertos tipos de limitantes de rangos de valores en ta información) 0 Puesta en práctica de la seauridad de la información - Respaldo y recuperación, consiste en detectar fallas y restaurarlas en !S Base de Datos 0 Control de concurrencia, controla la interacción entre usuarios concurrentes

Diseffo üe una Base de Datos

El disefio de una Base de Datos se auxilia de m Modelo de Datos, el cual es un grupo de herramientas conceptuales para describir los datos, sus relaciones , su SemhtiCa, y sus limitantes.

Existen tres modelos principales de datos:

0 Modelo Relacional. Los datos y tas relaciones entre tos datos se representan por una serie de tablas, cada una de las cuales tiene una serie de columna con nombre Único 0 Modeto de Red. Los datos se representan por medio de conjuntos de registros y las relaciones entre los datos se representan como ligas.

o Modelo Jerárquico. Los datos o registros están organizados como un conjunto de áholes.

De los modelos anteriormente definidos el más utilizado es el Modelo Relacional.

Modelo Relacional

ü n iviocieio Reiacionai consta de ¡as siguientes componentes:

0 Relaciones: Subconjunto del producto cartesiano de un conjunto de dominios (DI, DZ,. . , Dn). Una relación es equivalente a una tabla. 0 Dominio: Conjunto de valores vhiidos de los atributos 0 1 upia: Rengión de una tabla 0 Cardinalidad: Numero de tuplas de una relación (número de renglones) 0 Grado: Número de columnas de una relación

-

Propiedades de las relaciones

33

0 No existen tupias repetidas o Las tuplas no estdn ordenadas 0 Los atributos no están ordenados 0 lodos los valores de ¡os atributos son at6micos (cada atributo tiene un s6io vaioi)

-

Una reiaci6n este formada de:

a) Cabecera, definida en base a los atributos b) Cuerpo, definido en base a las tuplas

Nombre Reiacirjn [Atl:Dl, AtZ:D2, ..., Atn:Dnj

At¡: Atributo Di: Dominio

_. !,pos tie Reiaciones

I ) Relaciones Base: Son todas aquellas tablas que son resultados de convertir el modelo entidad relación a relacional. Una entidad produce una tabla 2) Vista: S e construye mediante relaciones bases. Funcionan para consultas de información. La vista contiene información de una o varias tablas y no genera espacio ocupado en disco 3) Relaciones Instantáneas (Snapshots): Son como una vista, sólo que la información está dupticada físicamente para las consuttas, se utilizan en bases de datos distribuidas y se tienen que refrescar continuamente. 4) Consuttas: Mediante ellas se puede tener acceso a ta base de datos 5) Resultados intermedios: Son el resultado de consultas anidadas

Llaves

a) Primaria: Es el minimo de atributos que identifican de manera única una tupla. Sirven para relacionar dos o mzis tabfas bj Candidata: Para elegir una llave primaria se tienen inicialmente las candidatas que cumplen con tos criterios de unicidad (no hay tuplas repetidas) y minimalidad (tienen el mínimo de atributos identificadores de manera hicit) c) Foránea: Son los atributos que están como llaves primarias en otra relación y se heredan a una entidad generalmente asociativa. Una llave foránea también puede formar parte de la llave primaria

Algebra Relaciona1

Es un conjunto de operaciones sobre las retaciones. Cada operación toma un o más relaciones como operandos y produce otra operación como su resultado.

Operaciones Relacionales

El operador de proyección produce un subconjunto vertical de una relación dada. Es decir, el subconjunto obtenido ai seieccionar los atributos especificados, en Un orden especificado de izquierda a derecha y eiiminando despues las tupias aupiicadas en los airibuios seieccionados.

34

Restricción

Esta operación se realiza cuando se requieren sólo ciertos renglones de la tabla.

1 .S. 1 Rational Rose 4.0

Es una herramienta CASE (ingenieria de Software Asistida por Computadora), que permite visualizar gp&ficamente a traves de diagramas, elementos de¡ modelo de orientacibn a objetos, asi como generar c6digo en un lenguaje orientado a objetos.

La intert'az graiiea de usuario de Rose permite ver, crear, modificar y maniputar ¡as componentes del modelo de orientacit3n a objetos. Esto se bgra a traves de los diagramas de : Estado, Secuencia, lnteracci6n , Clases y Objetos.

Mediante Rose sera posibie lograr una mayor visualizaci6n de todas las partes que integran la apiicacibn, así como errlender e¡ funcionamiento de cada una de ellas, mediante los diagramas mencionados.

1.5.2 Delphi 1.0

Es una herramienta de desarrollo de software que utiliza el lenguaje de programación orientado a objetos "Object Pascal".

Permite dcsarrottar apticaciones basadas en GUI (Interfaces Gráficas de Usuario), las cuales actualmente tienen un gran auge en los productos de software.

Mediante Detptti ta aplicacion que desarrollaremos requerirA un menor tiempo de desarrollo por el empleo de ta reusabitidad de componentes ; así también trabajaremos efectivamente en un ambiente de programación orientado a objetos debido a que Delphi fue desarrollado para tal propósito.

La elección de esta herramienta se debió a tas características del equipo con el que se cuenta, así como la potencialidad que ofrece.

2. Descripcidn del problema.

P. 7 Descripcidn del problema.

E¡ eje central del diterente conjunto de actividades que realiza una casa de cambios de divisas es la compraventa de las mismas. 1s que se desea es crear un sistema informatico que permita registrar y controlar dichas operaciones, tomando en cuenta las siguientes consideraciones.

tina compraventa es una operacibn que se pacta entre ulf ctinte y la casa de cambios. s e denomina mrnpra cuando la casa de cambio adquiere divisas extranjeras, y vertta cuando las vende. Et precio al que adquiere o vende divisas extranjeras se conoce como tasa de cambio, y para efectos de simpticidad se considerará como el medio empleado para la compra o la venta a la moneda nacional.

La manera en se establece una compraventa es por medio de un promotor, el cual es un empleado de la casa de cambio. El promotor se contacta con l o s ckntes, ya sea de manera directa o por ielCiiono, y realiza el pacto de ¡as operaciones. En dicho pacto deben fijarse datos como son et que si se trata de una compra o de una venta, la Bivisa que interviene, el monto de la misma, el tipo de cambio, los datos del cliente, y algunos comentarios adicionales. Asimismo, el promotof asigna un nlimero a ta operacibn, cofToeido como nbmro de folio, el cual se comunica al ciiente y es utiifzado como identiitcador de la operacicin. Cabe mencionar que el numero de folio es un identificador temporal, ya que despues de un tiempo los numeros de folio pueden volver a usarse.

E n ocasiDnes cumdo et monto de una compraventa es muy alto el ciiente puede desear obtener una tasa de cambio ligeramente menor a la establecida. En estos casos debe mediar la figura del operador, quien en base a su experiencia y a la información que recibe sobre las variaciones de los valores de las tasas de cambio, puede decidir si se acepta la compraventa o no. Por lo tanto, queda establecido que las compraventas en las que se soiicite ajustes en la tasa de cambio deben ser autorizadas por un operador.

Una vez que la Compraventa ha quedado establecida, el cliente debe realizar un depcisito a la casa de cambio el mismo día en que se establece ia operacibn. En caso de no ser as¡, la compraventa es cancelada al final del dia. La raz6n de hacer esto es que las tasas de cambio de las divisas sufren variaciones continuas, tas cuales pueden resultar en perjuicio de la casa de cambio. Es por eso que se establece como lapso mBxirno de tiempo para cubrir una operación la hora de¡ cese de actividades del mismo dia en que se pacte.

El depósito que realiza el cliente puede consistir en uno o más instrumentos de la divisa que le corresponde, cuyo monto sumado sea el establecido en el pacto de h compraventa. Asimismo, el pago consecuente consistirá tambiCin en uno o m8s instrumentos, pero pertenecientes a la otra divisa, en et monto acordado. Todos los instrumentos asociados at dep6sito o al pago se conocen como movimientos de la operación, y representan entradas o salidas de divisas a la casa de cambios.

Existe algo asociado a los diferentes tipos de instrumentos en los que pueden estar los diversos tipos de divisas manejadas por la casa de cambias. Ese algo se denomina posición, y representa el monto de una divisa acumulado en instrumentos de un mismo tipo en un instante dado. Esta informacibn es de vitai importancia para la casa de cambio, ya que es un indicador de lo que dispone en cada momento. Debido a la importancia que tiene, es importante actualizar

36

la posición de cada instrumento a medida que se registren o se alteren movimientos a favor o en contra de ¡a casa de cambios.

Una característica importante en el sistema es que, inmediatamente después de registrar una nueva compraventa, deben registrarse dos movimientos asociados a la misma, uno por cada divisa que interviene, en efectivo y por ei monto estipulado. Este registro debe ser automtttico, y debe hacerse alin cuando no se haya reatizado dep6sito ni pago alguno. Aunque est0 pudiera parecer extraño, la razón para hacerlo es ta necesidad de contar, en todo momento, con una idea lo más aproximada posible del estado del capital de la casa de cambio. Dada la baja incidencia de problemas para concluir satisfactoriamente las compras y ventas de divisas, al momento de pactar una compraventa se considera que el intercambio se realizará casi de manera segura. Por lo tanto, se registra de una vez los movimientos a favor y en contra pero en el instrumento que más variabilidad tiene: el efectivo. Sin embargo, es importante distinguir de alguna forma estos movimientos "virtuales" de los movimientos reales.

Para et registm de movimientos, cuando un ctiente desee reatizar un depósito debera especificar el número de folio de la compraventa. El personal de la casa de cambio solicitará al sistema intormaci6n de la misma, y registrara el depbstto. Si el monto del depbsito no concuerda con to establecido, no ser6 aceptado. Lo mismo debe suceder en el caso del pago al cliente. Como dato adicional, quién se encarga de recibir los depósitos de los clientes y realizar los pagos, registrando y controlando los movimientos asociados, es la sección de Tesorería de la casa de cambio. En otras palabras, los promotores únicamente pactan las compraventas con los clientes, ajustando el tipo de cambio. Tesoreria es la que reatiza los cobros y libera los pagos, ajustándose a lo pactado por el promotor.

Cuando e¡ monto de los movimientos de una compraventa en contra y a favor de ia casa de cambio son equivalentes, se dice que la operacion esta "cuamda". En caso contrario, se dice que esk3 "descuadrada". Por motivos de seguridad para tos casos de caída del sistema, es necesario controlar este indicador del estado de las operaciones, actualizándolo cada vez que se registren movimientos a la operacibn.

Es posible que, en caso de error, un promotor desee modificar los datos de una compraventa que haya Fegistrado de manera incorrecta. Sin embargo, por motivos de seguridad no debe permitirse modificar datos reievantes, como son el monto de ia operacibn, et tipo de cambio, el indicador de si es compra o venta, datos sobre et promotor responsable y la divisa extranjera. En caso de que atguno de estos datos desee modificarse, ta compraventa debe cancelarse y registrarse de nuevo. Cuando esto ocurra, /a compraventa cancelada no debe poder manipularse (es decir, no puede modificarse sus datos, cuadrarta, descuadrarta, asociarle movimientos o volverse a cancelar). Sin embargo, su registro no debe ser eliminado. Esto es para poder hacer revisiones posteriores de las operaciones canceladas.

La canceiacibn de una compraventa tiene repercusiones importantes en el estado del sistema. En primer fugar, todos tos movimientos asociaetos a la operaeidn deben ser eliminados, lo cual implica restaurar las posiciones de los instrumentos involucrados en los movimientos al estado que guardaban antes de registrar la compraventa. Asimismo, como se mencionó anteriormente las compraventas canceladas no pueden ser manipuladas.

Es posible que existan clientes que tengan un registm permanente en la casa de cambio dada la frecuencia de las operaciones que establecen con ella. Estos clientes pueden contar con una ctave propia la cual puede utilizarse para tdentificarios y asociarios con operaciones de compraventa. De esta manera podrían obtenerse datos sobre las operaciones que realizan estos clientes de manera periódica.

37

3. Modelo de requerimientos.

3.1 Modelo de Use case.

A partir de la descripcidn dei probiema, obtuvimos una lista de las actividades más importantes que se deben considerar. Dichas actividades son:

O Control de compras y ventas del día O Kegistfo de nueva compravefrta O Actualización o modificación de compraventa registrada O Cancetacidn de compraventa O Control de movimientos de compraventa o Registro de movimientos de una compraventa o Modiflcacidn de movimientos registrados O Eliminación de movimientos registrados

A continuacidn se expondran tos Use cases a explictindolos brevemente.

tsociados a cada u Ina de estas actividades,

Use case 1 : Control de compras y ventas del día i . Mostrar una iista de las compraventas cuya fecha de registro sea la fecha actual. Dicha lista debera indtear los numeros de folio de las compraventas, un indicador de si son compras o si son ventas, y un indicador del estado en que se encuentran las operaciones (cuadradas, descuadradas o canceladas).

2. Use case de Registro de nueva compraventa

3. Use case de Actualización o Modificación de compraventa registrada

4. Use case de Cancelacibn de compraventa

5. Actualizar la lista de compraventas del día.

Descripcidn del Use case: Este Use case simplemente engloba los Use cases de tas operaciones principales de manipulación de compraventas (altas, bajas y modificaciones). Dichos Use cases serAn dados a continuación.

Use case 2: Registro de nueva compraventa 1,Captura de datos de compraventa (datos del promotor que pacta la operación, del cliente, de la divisa que interviene, del monto de la divisa, el tipo de cambio, asignación de un número de folio, datos sobre el operador - si es necesario -, y comentarios adicionales).

2. Validación de datos capturados.

38

3. Registro de la compraventa con indicador de que está "descuadrada".

4. Registro de dos movimientos, uno a favor y otro en contra. Si se trata de una venta, el movimiento a favor será en moneda nacional en efectivo, y el movimiento en contra será en la divisa extranjera, también en efectivo. Si se trata de una compra sucederá lo contrario. En ambos casos el monto de los dos movimientos deberá ser equivalente al monto en moneda nacional establecido en la compraventa.

5. Cambiar el indicador del estado de la compraventa a "cuadrado"

Descripciún dei Use case:

En la sección de descripción del problema se hace alusión claramente a la necesidad de registrar las compraventas que los promotores pacten con los clientes. Existe un conjunto de datos necesarios para especificar una compraventa, como sun datos del promotor (para saber quién la pact@, datos del cliente (para saber con quién se pactó), si se trata de una compra o de una venta, el monto de la operación, y naturatmente el tipo de cambio. Adicionatmente, el cliente pudiera espectfiaF Pfefemcias sobre la manefa en que quiefe que se le pague, por lo que se incluye la captura de comentarios aaiicionales.

El punto número 3 del Use Case indica el registro de los datos capturados con un indicador de que la compraventa está "descuadrada". La descripción del problema indica que:

"Cuando et monto de tos movimientos de m a compraventa en contra y a favor de la casa de cambio son equivalentes, se dice que la operatibn e& "cuadrada". En caso cuntrario, se dice que esta "descuadrada: Por motivos de seguridad para tos casos de caida det sistema, es necesario controlar este indicador del estadu de las operaciones, acfualizdndolo cada vez que se registren movimientos a la operaci6n. "

Es obvio que sí no se h m hecho registros de movimientos, la operación deberá registrarse como descuadrada.

El punto número 4 se concluye a partir de el siguiente fragmento de la descripción del problema:

"Una cafacferistica importante en el sistema es que, inmediatamente &spt& de registrar una nueva compraventa, deben registrarse dos movimientos asociados a \a misma, uno por cada divisa que MeMm, en efectivo y por el monto eshjlulado. Este ri?g"o debe ser automatice, y debe hacerse a h cuando no se haya realizado dep6siro ni pago alguno. Aunque esto pudiera parecer extrafiq la r a d n para hacerlo es b necesidad de confar, en todo momento, con una idea b mas aproximada posible del esfado d e l capitatcfe la casa de cambio. Dacia la baja incidencia de probtemas para conctuir satisfaciofiamente las compras y ventas de divisas, al momento de pa&r m compraventa se considera que el htercambio se redizar4 casi de m a m a segura. Por lo tanto, se fegtstra de una tt&z los m t h h t o s a favor y en contra pero en el instrumento que mas variabilidad tiene: el efectivo. I'

Finalmente, el punto número 5 se obtiene de las mismas consideraciones que para el punto número 3.

Use case 3: Actualización o modification de compraveeta registrada l . Selección de la compraventa a modificar o actualizar

2. Validar que no haya sido cancelada

39

3. Capturar los datos modificados (datos del cliente y comentarios)

4. Actualizar el registro de la compraventa.

5. Use case de control de movimientos.

Use case 4: CancelacZn de compraventa. l. Selección de la compraventa a cancelar.

2. Cambiar el indicador del estado de la compraventa a cancelado.

3. Eliminar cada movimiento asociado a la compraventa, actualizando la posición del instrumento correspondiente.

Descripción de Use cases: Tanto et Ose case de Actualización o modificacion de compraventa registrada como el Use case de Cancelación de compraventa se obtuvieron de los siguientes dos párrafos de la descripción del problema:

"Es posible que, en caso de error, un promotor desee modificar los datos de una compraventa que haya regtstmdo de manera incorreda. Sin embargo, por motivos de seguridad no debe permitjrse modificar datos relevantes, como son el monto de la operacibn, el tipo de cambio, el indicador de si es cumpra o venta, datos sobre el promotor responsabte y la divisa extranjera. En caso de que alguno de estos datos desee modificarse, la compraventa debe cancelarse y registrarse de nuevo. Cuando esto ocurra, ta compraventa cancelada no debe poder manipularse (es decir, no puede modificarse sus datos, cuadrarla, descuadrada, asm'arie movjmienfos o volverse a cancelar). Sin embargo, su registro no debe ser eliminado. Esto es para poder hacer revisiones posteriores de las operaciones canceladas.

La cancelaci4n de una compraventa tiene repercusiones importantes en el estado del sistema. En primer Iugac todos tos movimientos asociados a la operacibn deben ser eliminados, lo cual implica restaurar las posiciones de los instrumentos involucrados en tos movimientos al estado que guardaban antes de registrar la compraventa. Asimismo, como se mencionb antenomente las compraventas canceladas no pueden ser manipuladas. "

El primer párrafo espeeifica que, por motivos de seguridad, no se pueden modificar datos como el monto de la operación, el tipo de cambio, el promotor, el indicador de compra o venta y la divisa extranjera. Eso implica que los únteus datos que se pueden modificar son los comentarios sobre la operación y los datos del cliente. Asimismo, indica que una compraventa cancelada no debe poder manipularse. Esto se indica en el punto número 2 del Use case de Actualización o modificación de compraventas registradas.

El punto número 3 del Use case de cancelación de compraventas fue obtenido directamente del segundo parrafo.

Como última consideración, el Use case de Actuatización o modificación de compraventas registradas hace uso, en su punto número 5, det Use case de control de movimientos, el cual se describira mas adelante. La razón para hacer esto es que se considera que una compraventa se actualiza cada vez que se actualizan los registros de los movimientos asociactos a la misma, ademas de que la mayoría de las veces los únicos datos que son se permite modificar de una

40

compraventa ya registrada (los datos sobre el cliente y los comentarios adicionales), se van a querer modificar al momento del registro del depósito det cliente (movimientos a favor de ta casa de cambio) y del registro del pago consecuente (movimientos en contra).

Use case 5: Control de movimientos de compraventa. l . Cambiar el indicador del estado de la compraventa a "descuadrado".

2. Use case de Registro de movimientos de compraventa

3. Use case de Modificación de movimientos de compraventa

4. Use case de eliminación de movimientos de compraventa.

5. Sumar el monto de los movimientos a favor y el monto de los movimientos en contra. Si ambos montos son equivaientes ai monto registrado en moneda nacionat para la compraventa, cambiar et indtcador del estado de la misma a "cuadrado", y finalizar ta operación. Si no cuadran, permitir la manipulación de los movimientos en contra y a favor hasta que sus montos sean equivalentes.

nescripcicin del Use case: Este Use case es directamente dependiente del Use Case de Actualización y modificacion de compraventas registradas. El objetivo de este Use Case es conjuntar las operaciones de manipulacth de tos mov-mtentos de compraventa (las altas, bajas y modificaciones en los registros de movimientos asociados a una compraventa). La razón para esto es lograr el punto número 5 del Use case: validar que los montos de los movimientos en contra y a favor concuerden con et estabtecido en la compraventa. Esta necesidad se hace patente a partir del siguiente fragmento de la descripcibn del problema:

"Para el registro de movimientos, cuando un cliente desee realizar un deposito deber6 especificar el número de folio de la compmventa. El personal de ta casa de cambio solicitara al sistema informacibn de la misma, y registrara e/ d~p6sito. Si el munto del depbsito no concuerda con lo establecido, no ser& aceptado. Lo mismo debe suceder en el caso del pago al cliente. "

En el dado caso de que una vez que el personat de ta casa de cambio haya registrado todos los movimientos retacionados con et depósito det ctiente, y resulte que no coincidan con el monto establecdo en la compraventa, se beberá informar at ckentt?, borrar los movimientos registrados asociados ai de@sito, y restaurar ei movimiento que se registra automáticamente cada vez que se registra una nueva compraventa.

Finalmente, si los montos de tos movimientos a favor y en contra son correctos, el indicador del estado de la compraventa cambia a "cuadrado". Esto es acorde a lo especificado en la descripción del problema.

Use case 6: Registro de movimientos de compraventa. 1. Especificar si el movimiento es a favor o en contra.

2. Seleccionar et instrumento en que se encuentre la divisa correspondiente (si se trata de una compra, si e¡ movimiento es a favor la divisa d e l instrumento serél la divisa extraqera, y si es en contra sera la moneda nacional. En caso áe que se trate de una venta ocurri~?~ lo contrario)

41

3. Capturar el monto del movimiento.

4. Registrar el movimiento, actualizando la posición del instrumento asociado.

Use case 7: Modificación de movimiento de compraventa. 1. Seleccionar el movimiento.

2. Capturar el nuevo monto.

3. Registrar la actuatización, afectando la posición del instrumento asociado (restando el monto anterior de la posición y sumando el monto actuatizado, si se trata de un movimiento a favor; o sumando et monto anterior y restando e¡ monto actuaiizado, se trata de un movimiento en contra).

Use case 8: Eliminación de movimiento de compraventa. 1. Seleccionar el movimiento.

2. Afectar la posicion del instrumento asociado al movimiento.

3. Borrar el registro del movimiento.

Descripción de Use Cases: Estos tres Use Cases son directamente dependientes del Use Case de Control de movimientos de compraventa. Describen básicamente las operaciones de manipulación de movimientos de compraventa: altas, bajas y modificaciones. Los tres hacen hincapié en la actualización de la posición de los instrumentos con que estén relacionados los movimientos:

"Existe algo asociado a los diil?rentes tipos de insfromentos en los que pueden estar los diversos tipos de divisas manejadas por la casa de cambios. Ese a/go se denomina posicibn, y representa el monto de una divisa acumulado en instrumentos de un mismo tipo en on instante dado. Esta infomacibn es de vital importancia para la casa de cambia, ya que es on indicador de lo que dispone en cada momento. Debido a la importancia Q U ~ tiene, es importante aefuafizar la posicidn de cada instrumento a medidif que se registren o se aiteren movimientos a favor o en contra de la casa de cambios. "

En el Use case de modificacibn de movimiento de compraventa se considera que lo Único que se puede mocfiificar es el monto de un movimiento. Esto se considera así porque los datos que caracterizan a un movimiento son su monto, el que sea en contra o a favor y et instrumento en que este la dtvisa. El que sea en contra o a favor esta directamente retacionado con el instrumento en que fue hecho el movimiento (y por lo tanto con ta divisa). Por to tanto, este dato no es rnodifkatrte. Modificar el instrumento det movimiento imptica dos acciones: ajustar la posicih del instrumento antiguo como si el movimiento no se hubwa realizado, y actuakzar la

dar baja el Mvimimife coil e¡ insirurneiliü erFhe0, y :t?tJ¡SiFéiV¡O de riuevü el movirnkfltü seCecciOnando el instrumento correcio. For ic, tanio, ei hito dato q ~ e se puede rtldiiicar. e s el monto de un movimiento, ajustando naturalmente la posición del instrumento.

pOSiCi6Fl de¡ flUt%O iffSiFurtientO COmO Si Sf3 adab¿3FEi & t~iSirEi1' €!i ril~Viliiki1iü. ES RIGS Seifd¡¡¡ü

42

3.2 Modelo de interfaz.

En esta sección identificaremos a las intwaces para la interacción det usuario con el sistema más importantes, y explicaremos algunas de sus características. Asimismo, mostraremos la forma en que se relacionan unas con otras.

Con la ayuda de los Use cases de la sección anterior, y la descripción del problema, intentaremos obtener indicios sobre las interfaces de usuario recién mencionadas. Regresando a la sección anterior, podemos apreciar que los Use cases manejados fueron:

- Control de cwnpfas y ventas del dia - Registro de nueva compraventa - Actuatiación o modificacibn de compraventa registrada - Cancelación de compraventa - Control de movimientos de compraventa - Registro de movimientos de una compraventa - Modificación de movimientos registrados - Eliminación de movimientos registrados

Utilizaremos estos Use cases como punto de partida para establecer las interfaces de usuario del sistema.

Interfaz para el Control de compras y ventas del día.

Ya que el control de compras y ventas del día es la actividad a partir de la cual se desprende el resto de las actividades, su interfaz deberá servir para otro tanto. En primer lugar, esta interfaz deberá mostrar al usuario una lista de todas las compraventas pactadas en el día, mostrando sus números de fotio, un indicador de si son compras o ventas, y un indicador det estado en que se encuentran (cuadradas, descuadradas o canceladas). La manera más apropiada de presentar la información sería ordenando la lista por el número de folio. Adicionalmente, ta interfaz debe permitir la selección de elementos de la lista, y opciones para poder modificarlos, cancelarlos o llevar a cabo el registro de nuevos. Una vez reatizada la actividad asociada a cualquiera de dichas opciones, la lista deberá ser actualizada.

Interfaz para el Registro de nueva compraventa.

Esta interfaz es simple, y su función es permitir al usuario capturar la información de una nueva compraventa que se pacte, dándole opciones para aceptar el registro o cancelarlo.

lnterfaz para la Actualización o modificacih de compraventa registrada.

Como su nombre to indica, debe proporcionar el medio para la modífícaci6n de los datos de una compraventa. Dado que se ha planteado que la interfaz de control de compras y ventas del día permita la selección de tas compraventas a partir de una tista de ettas, la tabor de la interfaz actual consistirá en mostrar tos datos registrados de ta compraventa seteccionada, y permitir su modificaci6n, presentando opciones para su aceptacibn o rechazo. Adicionalmente, dado que la actualización de una compraventa plantea el registro, modificación y eliminación de sus

43

movimientos asociados, esta interfaz servirá como puente hacia una interfaz que trate con dichas cuestiones.

Interfaz para la Cancelación de compraventa.

Debido a que la cancetación de una compraventa implica una simple seleccidn de ta misma, y dicha selección se lleva a cabo mediante la interfaz de control de compras y ventas del día, se considera innecesario tener una interfaz para la cancelación de una compraventa. Por to tanto, la cancetación de una compraventa se establece como una opción más de la interfaz de control de compras y ventas deí dia.

Interfaz para el Control de movimientos de compraventa.

Esta interfaz está directamente relacionada con ta lnterfaz de actuatiración o modificación de compraventas registradas. De hecho, aprovecha el hecho de que para una modificación o actualización primero se debe seleccionar una compraventa, utilizándola como base para presentar una lista de tos movimientos que tenga asociados. Asimismo, debe brindar opciones para el registro de mevos movimientos, y para ta modificación o eliminación de tos ya existentes. De manera simitar a ta interfaz de control de compras y ventas del día, la lista de movimientos debe actualizarse después de cada manipulación. Adicionalmente, debe presentar una opción para finalizar las manipulaciones y regresar et confrol a la interfaz de control de compras y ventas del día, presentando mensajes de error (e impidiendo regresar a la interfaz mencionada) cuando el monto de los movimientos a favor o el de los movimientos en contra difiera del señalado en el registro de la compraventa.

Interfaz para el Registro de movimientos de una compraventa.

Es otra interfaz netamente de captura. Su uso se limita a ía recepcidn de información de movimientos de compraventa. Esta interfaz puede presentar una lista de los instrumentos registrados para la divisa correspondiente, dependiendo de los datos del registro de la compraventa y de to que se especifique sobre si et movimiento será a favor o en contra. Esta interfaz debera contar con opciones para la aceptación o el rechazo del registro de la información capturada.

Interfaz para la Modificación de movimientos registrados.

Una vez más se aprovecha la selección que se hace en una interfaz de control. Esta interfaz debe mostrar algunos datos sobre el movimiento a modificar, pero sfdo debe permitir ta captura de uno de ellos: el monto del movimiento. Como siempre, debe presentar opciones para aceptar la modificación o rechazarla.

44

Interfaz para la Eliminación de movimientos registrados.

Las consideraciones para esta interfaz son simitares a las de ta interfaz para ta eliminación de compraventas registradas: no es necesaria. La eliminación de movimientos registrados se establece como una opción de la interfaz de control de movimientos de compraventa.

Conclusiones sobre las interfaces.

A partir de los comentarios y consideraciones anteriores, se deduce que la estructura de las interfaces gira en torno a dos de ellas: la interfaz de control de compras y ventas del día, y la interfaz de contmt de movimientos de compraventa. Cada una cuenta c m m tista de los elementos con los que está relacionada, y establece opciones para su manipulación, la cual se lleva a cabo por medio de otras interfaces de usuario. En ambas, ta cancelacih o etiminación de elementos se establece como opciones de la misma interfaz, y no como una asociación con una interfaz adicional. En to que respecta a las demas interfaces, las opciones de aceptación o rechazo de la información capturada son establecidas como características comunes a todas ellas. Finalmente, ta interfaz de control de movimientos registrados presenta caracteristicas que deben ser revisadas con más detalle en la fase de diseño del sistema.

Las interfaces de usuario y sus inierrelaciones se muestran en el diagrama 3.2.1

Interfaz de registro de nueva compraventa

compraventa

compraventa

lnterfaz de ad. o mod. de compraventa registrada lnterfaz de modificacidn

de movimientos registrados

Diagrama 3.2.1. Interfaces del sistema y relaciones entre las mismas.

45

3.3 Diagrama de clases.

Para modetar la información que el sistema manejará a to targo del tiempo utilizamos objetos entidad. Típicamente esta información sobrevive los Use cases, por lo que debe mantenerse incluso si los Use cases han sido completados. Haciendo una ~v i s i bn de los Use cases de la sección 3.1 y de la descripción del problema, encontramos las entidades del sistema que utilizamos curno punto de partida para generar nuestro diagrama de clases (diagrama 3.3.1). Dichas entidades son:

Cliente, Un cliente es cualquier persona o empresa que tiene vínculos comerciales con la casa de cambios. En lo que a respecta al sistema, un cliente es una persona con la que se realiza o se ha realizado compras o ventas de divisas. Los atributos de esta entidad son:

IdCTE .- valor numérico que se usa para identificar al cliente.

NomCTE .- nombre del cliente.

Compraventa Una compraventa es la operacibn de intercambio de divisas que se pacta entre un cliente y un proveedor. Esta entidad hereda parte de süs atributos de ¡a entidad Operacih, y natüraiitlenie esiará reiacionaaa con un Cliente, un Prwnoiar, un Operador y una divisa extranjera. Sus airibuios son:

DiViStL Esiabiece una moneda, ya sea nacionai o exiranjera. Sus airibuios son:

h1nernDiV .- es un mnemónico para ei manejo ae ¡a divisa.

EniraSaieMovOp .- indicador de si e¡ movimienio es a favor o en contra de ¡a casa de cambios

Operucihcin. üna operación es una actividad de inversión, de transferencia o de compravenia. For ianio, se estsblzzz como base paw Uiiü sspezislizacldn, de la eiial forma paite la Comprsvents. ÜÜS

eiritjuiüs son:

FecnOper .- fecha en que se pacia ia operación.

SiaiGper .- indicador deí esiado en que se encuenire ia operación. Para una compravenia se ütiliza pam reprssentar si se enc~entra cuadrsda, bescmdrade o cancelads.

ivionioOper .- monto de ia operación.

FechPos .- fecha de la posicih

TotCpa .- monio acumuiado en entradas reaiizadas en ei insirumenio asociado.

idPrüm .- vaiür nüfitj.ricü üsacio per2 icieniiiicer ai prürnüiür.

PiomProm .- nombre de¡ promotor.

iaiCTE .- vaior numérico para ideniiiicar a ia caiegoría de ciienies.

I TI ..I

""

FechOper HoraOper

I

.l

..." ~

IdTtnstrum

..I

.

..I

Diagrama 3.3.1. Diagrama de Clases Entidad del Sistema de Control de Compraventas

4. Modeío de an%iisis.

Los ciiagramas de ccriaboraci3n desarrüiiadüs para el si5tei-M sijn si 4.1, 4.2, 4.3, 4.4 y 4.5. E¡

muestran ias reiaciones exisienies enire ;a interfaz de coniroi de compras y venias aei día y ias interfaces de registro y aciuaiización o modificación de compraventas. Dichas reiaciones se describen en ¡a sección 3.2. fambien se muestra una reiación entre ¡a interfaz de controi de compras y ventas der dia con un objeto de control denominado lista de compraventas del ala. La función ae este úiiimo será coniroiar ei acceso de ia interfaz ai conjunto de las Compraventas registradas a io iargo ciei áía, y aciuaiizar dicho conjunto después de cada manipuiación de ia interfaz.

p,+~íe," de eiios eol~7espon& ai 6 s case coriil?"i be eo,frpt-as y veriigs &i dia. En &i se

Ei diagrama 4.3 corresponde ai iise case de aduattzación o modificación de compravenia registrada, pero 38 eir:iende para iiietüir i i l Ese casi3 de CGnirGl be moiiiiiiieiitos de compraveiita. De manera sitmiis e¡ diagrama 4.4, ~ii i iza m o t j e ~ cie contra! cienminadü iisia de müVimieriios

eoIifrsiar 8(yesu de ia ir1te,zfa2 u'e eoiltt7üi de rtioY~i~iienfos de eorTlpf;aven~a ai eoi,jlli,is de dichos rnovimienios. i a s reiaciones exisienies enire ias interfaces iarnbién se describen en ia seccidii 3.2.

Fiilairiieníe, ius diagrafrfa3 4.2, 4.4 y 4.5, coriespori~ienies a ius üse cdyes de legisilo de ilueva compravenia, regisiro de rnovimienio ae compravenia y áe rnoáiiicación de compravenia se consideran io suficientemente expíiciios como para expiicarios en deiaiie.

5íi

(1 Lista de compraventas del dia

Compraventa

lnterfaz de registro de nueva Compraventa

lnterfaz de contro de movimientos de compraventa

lntttfaz de act. o mod. de compraventa registrada

Diagrama 4.1. Diagrama de colaboraci6n para el control de compras y ventas del dia

n Prom PrornaMr

Operador

Compraventa

laMt

Operador

Compraventa

Diagrama 4.2. Diagrama de colaboraci6n para el registro de una nueva compraventa

51

Movimiento

Sta de movimientos

lnterfaz de registro de movimientos de compraventa

lnterfaz de modificacihn de movimientos registrados

de Eompraventa registrada

Diagrama 4.3. Diagrama de colaboracidn para la actualizacih de una compraventa

Diagrama 4.4. Diagrama de colaboración para el registro de un movimiento de una compraventa

52

5. Modelo de diseiro.

En esta fase de desarrollo desarrollaremos, para cada Use case especificado en la sección 3.1, lo que se conoce como diagramas de secuencia. Los diagramas de secuencia se denominan diagramas de interacción en los trabajos de Jacobson, o diagramas de trazo de mensajes en la notacidn UML (ver seccidn 1.3).

Los diagramas de secuencia describen como cada Use case es desarrollado por objetos que se comunican entre sí. Los diagramas muestran como los objetos participantes realizan el Use case a través de sus interacciones. La interaccidn tiene lugar cuando los bloques mandan estimulos unos a otros. Cuando dibujamos los diagramas de interacción, podemos definir los estímulos incluyendo los parámetros enviados. El propósito principal del diseño de los Use cases es por tanto definir los protocolos entre las clases.

Cuando disefiamos en base a un Use case, comenzamos identificando los objetos que intervienen en él. Esto se hizo con ta ayuda de los diagramas de colaboración desarrollados en el modelo de análisis. Asimismo, fueron adoptadas algunas convenciones, como utilizar el prefijo "db" antes del nombre de los mensajes que involucren una interaccibn directa con una base de datos física, o encerrar entre los símbolos "e" y 5 " mensajes que intentan resumir conjuntos de acciones en cierto modo triviales, cuya ausencia no resta descriptibilidad.

Los diagramas de secuencia desarrollados fueron seis, y se explican brevemente a continuación.

Registro de una nueva compraventa (diagrama 5.11. En el diagrama se puede apreciar que la interfaz de control de compras y ventas del día envia un mensaje a la interfaz de registro de nueva compraventa para que se active y asuma el control. Dado que esta interfaz recibirá información del usuario relacionada con promotores, operadores, divisas, etc., deber4 verificar su validez recuperando su estado persistente guardado en las bases de datos que tengan asociadas. Dicha información se envía a la entidad compraventa para darle valor a sus atributos, y se le indica mediante otro mensaje que registre su estado. Esto origina que se creen dos movimientos de compraventa, uno por la divisa extranjera, y otro por la moneda nacional, con indicadores de entradahalida encontrados (pues uno representad una entrada a la casa de cambio y el otro una salida, o viceversa dependiendo de que se trate de una compra o de una venta). La compraventa envía mensajes a estos movimientos recien creados para que guarden su estado, y coloca su indicador de estado a "cuadrado", registrando dicho cambio.

Actualización o Modificación de compraventa registrada (diagrama 5.2). Cuando se intenta modificar una compraventa primero debe seleccionarse. El diagrama muestra que la interfaz de compras y ventas del día se encarga de seleccionar una compraventa de la lista de compraventas, y la envía como parámetro de un mensaje que activa la interfaz de act. o modificación de compraventas registradas. Esta se encarga de desptegar los datos de ta compraventa seleccionada, recibe la infomacibn modificada por parte del usuario, la asigna a la compraventa, y le envía un mensaje para que registre su nuevo estado. Posteriormente, la interfaz de act. o modificación de compraventas registradas transfiere el control a la lnterfaz de Control de movimientos de compraventa, la cual se encargará de controlar la manipulación de los movimientos asociados a la compraventa actual. Finalmente, el control regresa a la interfaz de control de compras y ventas del día, la cual envía un mensaje a la lista de compraventas para que se actualice.

54

Cancelacion de compraventa (diagrama 5.3). Para la cancelaci6n de una compraventa se sigue un procedimiento similar al de ta modificación, pero en vez de activar una interfaz auxiliar, la interfaz de control de compras y ventas del día se encarga directamente de la cancetaciirn. Una vez que se ha seleccionado una compraventa de la lista de compraventas, se envfa una mensaje a ta compraventa en cuestidn para que cancele su registro. Una vez realizado esto la compraventa construye una lista de todos los movimientos que tenga asociados, enviándoles mensajes para que eliminen sus registros. Como cada movimiento está asociado a un instrumento, y cada instrumento está asociado a la posición del día, cada vez que se elimina un movimiento debe restablecerse la posición del instrumento que tiene asociado al estado que guardaba antes de registrar el movimiento. Para ello el movimiento envía un mensaje al instrumento en ese sentido, cuyos parámetros indican que la posición se debe afectar por un monto igual al del movimiento, pero en dirección contraria a la especificada en el movimiento (si el movimiento era de entrada, la posicibn se afecta como si se hubiera realizado un movimiento equivalente de salida, y viceversa).

Registro de movimiento de compraventa (diagrama 5.4). Este diagrama de secuencia podría considerarse una extensión del diagrama 5.2. La interfaz de act. o modificaci6n de compraventa registrada activa ta interfaz de control de movimientos de compraventa, y esta activa a su vet la interfaz de registro de movimiento de compraventa. Como el control se transfiere a esta ú¡tima, dependiendo tanto de los atributos de la compraventa que se le envía como parámetro del mensaje de activacibn, como de la especificación del usuario del sentido del movimiento (de entrada o salida), crea una lista de instrumentos asociados a la divisa correspondiente y permite que se seleccione uno de ellos. Posteriormente, crea el nuevo movimiento y le asigna el instrumento y el monto especificado por el usuario, indicándole después que guarde su estado. Finalmente, la lista de instrumentos es destruida, y el control regresa a la interfaz de control de movimientos.

Modificación de un movimiento de compraventa (diagrama 5.5). El diagrama muestra lo que ocurre al cambiar el monto de un movimiento seleccionado: este envla mensajes al instrumento asociado al movimiento, primero para que afecte su posicidn en el mismo sentido que ocurriría si el movimiento fuera enminado, y luego para que la afecte como si el movimiento se registrar por primera vez, pero con el nuevo monto. Después de llevar a cabo estas operaciones, el registro del movimiento se actualiza.

Eliminaci6n de movimiento registrado (diagrama 5.6). Este diagrama de secuencia es muy simpte: se setecciona el movimiento desde la interfaz de control de movimientos registrados, la interfaz le envfa un mensaje para que elimine su registro, y el movimiento le envla un mensaje al instrumento con el que estd asociado para que restablezca su posición. Finalmente la interfaz de control de movimientos manda un mensaje a la lista de movimientos para que se actualice.

Control de movimientos de compraventa (diagrama 5.7). El objetivo de este diagrama es mostrar to que ocurre cada vez que el control se transfiere a la interfaz de control de movimientos de compraventa. Lo primero que sucede es que carga una lista de los movimientos que esten asociados a la compraventa que se le envía como pardmetro para su activación (ver diagrama 5.2). Después, el indicador del estado de la compraventa es descuadrado. Esto se hace por motivos de seguridad, ya que en caso de que el sistema se caiga

55

en medio de un conjunio de mariipuiaciones en los movimienios de ia compraventa, e¡ indicador de estado indicaría que la compraver3ta esta “ciadrada”, lo cm: pcirfi?’a SSÍ i r ~ W o . Por io tanto, sdlo bespu&s de verificar los montos de los movimientos da enirada y de salida sa restabiecerh e¡ indicador de¡ estado de ¡a compraventa a “cuadvado”.

El diagraina rnuestrz, a ̂ riiarrera de ejemplo, la aL~~zciSii cle tas interÍaces de regidtm y de ~~odificacibrr de mcVimientos. La mobificacibfi, la eHrninacibn y ai registro de nuevos movimientos piiedeii ~biizafse cuttiitas veces se quiera, aduaiizaiido ¡a lista de t-ftovitmientos después de cada manipulación. Cuando el usuario finalice las manipulaciones de ¡os movimientos, indicara a ¡a interfaz de controi de compraventas que desea finaiizar. En ese momento ¡a interiaz enviara mensajes a ¡a iista de movimientos para obtener Tos montos acumulados de los movimientos de entrada y de saiida, y ¡os cotejara con e¡ monto estabiecido en la compraventa. Si coinciden, la interfaz enviarh un mensaje a ta compraventa para que coioque su indicador de estado a ”cuadrado”, y e¡ controi regresará a ¡a inieriaz de ad. o rnodificacion de compraventas registradas.

lnterfaz de control de lnterfaz de Registro compras y ventas del de nueva

dla Compraventa DivisaExt unPromotor

Activar c____I_F

dbRecuperar 1_1___3c

dbRecuperar .).

unoperador uncliente unacompraventa Movimiento 1

dbRecuperar * dbRecuprar

.).

Crear * AslgnaDivisaExt

c. Asignacliente

AslgnaPromotor

Asignaoperador

* * *

signar datos restantes

dbGuardar

Movimiento 2

Crear(DivisaExt, unacompraventa, EntralSale, unaCompraVentr.MontoOper) _______1c(

dbGuardar

Crear(,DivisaNacional, unaCzpraVenta, SaldEntra, unaCompraVenta.MontoMN0per)

c*

dbGuardar

dbCuadrar

Diagrama 5.1. Diagrama de secuencia para el registro de una nueva compraventa

lnterfaz de Control de compras y ventas del

día

Interfaz de Act, o lnterfaz de Control de Lista de Mod. de compraventa Movimientos de Compraventa-seleccionada

Compraventas registrada compraventa

Seleccionarcompraventa ~

w Activar(Compraventa-seleccionada)

r I

I <asignar datos modificados, 5 dbActualizar

r Activar(Compraventa-seleccionada)

1 w ,

Diagrama 5.2. Diagrama de secuencia para Actualizaci6n o Modificpci6n de compraventa registrada

lnterfaz de Control de compras y ventas del Lista de Lista de movimientos

d la Compraventas Compraventa-seleccionada de compraventa Movimiento i-bsimo unlnstrumento

SeleccionarCompraventa )r

dbCancelar * Crear(Compraventa-seleccionada)

L:

EliminarElementos h

Actualizar 1

dbEliminar b

AfectarPosici6n(Monto, Entra/Sale)”--+,,

Destruir

Diagrama 5.3. Diagrama de secuencia para cancelaci6n de compraventa

A

A I I

4

i .

lnterfaz de Control de movimientos de

compraventa

Interfa2 de Modlficacibn de

movimientos registrados Lista de movimientos

SeleccionarMovimiento

Movimiento-seleccionado Instrumento Posicibn

Actlvar(Movimiento-seleccipnado) k

Actualizar -D

CarnbiarMonto(Nuevorn0nto) b Afe~tarPosici6n(MontoViejo,

EntralSale) Afect@r(MontoViejo,

EntrdSale) __________)

dbActualizar 7

AfectarPosici6n(NuevoMonto, SaleEntra)

b Afactar(NuevoMonto, SalelEntra)

CI

dbActualizar

2 dbActualizar

Diagrama 5.5. Diagrama de secuencia para la modificaci6n de un movimiento de compraventa

I

1

62

1

A

&

Ir

L e m D 3

o, U

63

6. Modelo de programación.

La plataforma que se eligió para la implementación del sistema fue Bortand Delphi versión 1 .O, la cual es un desarrollador de aplicaciones en ambiente Microsoft Windows. Las motivaciones principales para ta utilización de esta plataforma fueron: ta facilidad para ta generación de interfaces de usuario, las herramientas para manejo de bases de datos (SQL, dBASE IV, Paradox), y et hecho de que utilizara como tenguaje fuente Object Pascal, el cual presenta es similar lenguaje Pascal común, pero adiciona elementos para el manejo de clases y objetos.

Dado que Detphi permite manejar bases de datas de diversos tipos, la elección recayó sobre bases de datos estilo Paradox. La razón para esto es que Bortand Detphi adiciona una herramienta conocida como Database Desktop, la cual permite la generación y manipulación de bases de datos de Paradox y dBASE IV.

A continuaci6r-r expondremos brevemente tos m6ctuIos que constituyeron et sistema, así como las relaciones existentes entre los mismos. Dichas relaciones se pueden apreciar de manera más clam en el diagrama 7.1. Cabe seiialar que la plataforma seleccionada proporciona una diversidad de tmddulus para uso en el desarrolto de apticaciones, algunos de los mates fueron utilizados en el desarrollo del sistema. Sin embargo, no haremos mención de ellos, concentrándonos en los módulos que fueron desarrollados.

Descripción de los módulos.

Nombre del módulo: SISCCV.PAS

Significado: Sistema de Control de Compraventas

Descripción: Módulo principal del sistema. Utiliza los servicios del módulo CTRLCV.PAS.

Nombre del módulo: CTRLCV.PAS

Significado: Control de Compraventas

Descripción: Contiene el código de especificación e impiementación de la interfaz de control de compras y ventas del día. Utitiza tos servicios de los módulos CLASES.PAS, ALTACV.PAS y M0DCV.PAS para registrar nuevas compraventas o modificartas. También contiene et código necesario para coordinar tas actividades relacionadas a la cancetación de compraventas. Adicionatmente controla la actualización continua de la información de la lista de compraventas.

Nombre del módulo: ALTACV.PAS

Significado: Alta de Compraventas

Descripción: Especificación e impiementación de la interfaz de registro de nuevas compraventas. Está relacionado con el módulo CLASESPAS para la utilización de las clases Compraventa,

64

Operación, Promotor, Operador, Divisa, Cliente, Tcliente, MovOp, Instrumento y Posición. Contiene el c6dgo que coordina el conjunto de acciones involucradas a la captura, validación y registro de información de compraventas.

Nombre del módulo: MODCV.PAS

Significado: Modificación de Compraventas

Descripción: Especificación e implementación de la interfaz de actuatización o modificación de compraventas registradas. Está relacionado con el múdulo CtASES.PAS para la utilización de tas clases del sistema. Contiene et código necesario para el desptiegue, captura y actualización de información de compraventas. Adicionalmente se enlaza con el módulo CTRLMOV.PAS para ttevar a cabo la manipulación de movimientos asociados a una compraventa.

Nombre del módulo: CTRLMOV.PAS

Significado: Control de movimientos de compraventa

Descripción: Especificación e implementación de la interfaz de control de movimientos de compraventa. Está relacionado con el módulo CLASES.PAS para ta utitización de tas clases del sistema. Contiene ta implementación de las rutinas que permiten ta manipulación de los movimientos de compraventa, manteniendo enlaces con los m6dutos ALTAMOV.PAS y MODMOV.PAS que contienerr tas especificaciones de tas interfaces de registro y modificación de movimientos. Aclicionatmente contiene tas rutinas para controlar y actualizar una lista de movimientos de compraventa.

Nombre del módulo: ALTAMOV.PAS

Significado: Alta de movimientos de compraventa

Descripción: Especificaacibn e implementación de la interfaz de registro de movimientos de Compraventa. Está retacionadu con el módulo CtASES.PAS para la utilización de l a s clases d e l sistema. Contiene et cirdigo que coordina el conjunto de acciones involucradas a la captura, validación y registro de nuevos movimientos.

Nombre del módulo: MODMOV.PAS

Significado: Modificación de movimientos de compraventa

Descripción: Especificación e implementación de la interfaz de modificación movimientos registrados. Está relacionado con el mbdulo CtASES.PAS para fa utifización de las clases del sistema. Contiene el código necesario para et desptiegue, captura y actuatizaciim de información de movimientos. Este módulo es utitimdo por el módulo MODMOV.PAS para llevar a cabo la actualización de compraventas.

Nombre del módulo: C U S E S . P A S

65

Significado: Clases del sistema

Descripción: Declaración e implementación de las clases Promotor, Operador, Operación, Compraventa, Tcliente, Ctiente, Instrumento, MovUp y Posición. Este móduto es utitizadu por todos tos demás módulos del sistema, exceptuando al mcidulo principal SISCCV.PAS.

66

ALTACV.PAS ALTAMOV.PAS

_""

SISCCV.PAS _____)

, : Programa ! j ,principal j i I

I I

i Declaraci6n I 1 de las clases j 1 del sistema i e- u 1

!

CWSES.PAS

' 7 "

I

M6dulo de control !&de movimientos

1

i CTRLMOV.PAS i

MODCV.PAS

Diagrama 6.1. Diagrama de mddulos del Sistema de Control de Compraventas de divisas

7. Conclusiones.

Parte de la problemática encontrada durante el desarrollo del presente proyecto estuvo constituida por las pequeñas diferencias existentes entre las diversas metodologías de análisis y diseño orientado a objetos que fueron comiberadas. Si bien cuentan con muchos puntos en común, y el Lenguaje de Modelo Unificado fue creado con el objeto de establecer una notación universal fácitmente transportable a las metodotogías de análisis y diseño orientado a objetos de uso más extendido, et no ajustarse a una metodotogía fija, y la faba de conocimientos al inicio del desarrollo, desembocaron en una confusión que hizo más lento el proceso de aprendizaje.

Asimismo, cabe señalar que el hecho de que el plan cfe estudios de la licenciatura en Computación, vigente a ta fecha, permita que tos alumnos cursen las materias Proyecto de Investigación I y Proyecto de Investigación It sin haber cursado previamente las materias de Análisis y Diseim de sistemas de Computaciúrr e llrtmducciún at Diseíío de Bases de Datos, repercute negativamente en el desarrollo de proyectos asociados a estas disciptinas. Por lo tanto, se recomienda establecer como requisito para proyectos afines el haber cursado dichas materias previamente.

Finalmente, es pertinente mencionar que ta probtemática más fuerte que se tuvo que enfrentar fue la falta de fuentes de información sobre la aplicación sobre la que estuvo centrada el proyecto.

Anexo: Glosario de términos det área del problema.

Cliente. Un cliente es cualquier persona o empresa que tiene vínculos comerciales con la casa de cambios. Dicho vínculos comerciales son las operaciones.

Compraventa Contrato bilateral consensual por el que una parte (vendedor) se obtga a transmitir una cosa o derecho a otra (comprador) a cambio de que esta se obligue a pagarle una cantidad de dinero llamada precio.

Divisa Moneda extranjera en efectivo y deudas activas del extranjero; también letras, cheques, pagarés y brdenes de pago extendidas en moneda extranjera, en la actmtidab sobre todo pagos y transferencias telegráficas a plazas bancarias extranjeras.

Instrumemto. Los instrumentos son formas de divisas; por ejemplo efectivo, cheques, cheques de viajero, transferencias electr6nicas, metales preciosos, etc..

Movimiento. Un movimiento es una entrada o salida de divisas a la casa de cambio.

Operadur. Un operador es una persona responsabte de un grupo de promotores y cuya función es analizar el movimiento del mercado de divisas y autorizar los ajustes en los tipos de cambio de una compraventa pactadas entre un cliente y un promotor.

Operación. Una operactbn es una actividad de inversibn, de transferencia o de compraventa de o hacia la casa de cambio.

Posicirin. Una posici6n es el monto de una divisa acumulado en instrumentos de un mismo tipo en un instante dado. Por ejempto, si el 26 de sept. de 1997 a las 1230 p.m. tenernos f45 ,OOO dótares americanos acumulados en cheques de viajero, decimos que la posición de la divisa dólar americano en instrumento cheque de viajero a las 1230 p.m. del 26 de sept. de 1997 es igual a 145,000.

Posición iniciul. Es la posición de un instrumento at iniciar el dia. La posición inicial de un instrumento es igual a la posición del instrumento al final del día anterior.

Posición @al. Es la posición de un instrumento al momento del cierre de las operaciones.

promotor. En el ámbito de la casa de cambio, un promotor es la persona que se encarga de pactar operaciones de compraventa con los clientes, ya sea en directo o vía telefónica.

Sta&,$ de compraventa El status de u r n compraventa es un indicador de si está cuadrada (es decir, si el monto acumutado de tos instrumentos que entran a la casa de cambios es igual al monto de los instrumentos que salen, ambos en moneda nacional), o si esta descuadrada. Tambikn puede indicar si la compraventa fue cancelada.

Tipo de cambio. Es el precio al que se vende o se compra una divisa. Generalmente se maneja en moneda nacional.

Bibliografía.

Grady Booch Andlisis y Diseno Orientado a Objetos con Aplicaciones Editorial Addison-Wesley I Día2 de Santos

James Rumbaugh y Grady Booch Unifed Method Notation Summary Version 0.8 Rational Software Corporation

James Rumbaugh y Grady Booch Unified Method Mefamodel Guide Version O. 8 Rational Software Corporation

James Rumbaugh, Grady Booch e lvar Jacobson The UnifM Mode\ Lmguage for Object-Oriented Development: Documentation Set Version O. 9 Addendum Rational Software Corporation

lvar Jacobson, M. Christerson, P. Jonsson y G. Overgaard Object C3fknted Soffware fngineering Addison-Wesley Publishing Company

Henry F. Korth y Abraham Silberschatz Fundamentos de Bases de datos Editorial Mc Graw Hill

Miguel Katrib Mora frugramacidn orientada a objetos en C++ INFOSYS, Mexico

Luis Joyanes Aguilar ProgramacicSn en Turbo Pascal Versiones 5.5, 6. O y 7. O Editorial Mc Graw Hill

Delphi User's Guide Borland International Inc.

71