3.1 – Arquitectura de clases
El objetivo del modelo de analisis es
crear una arquitectura de objetos que sirva como base para el diseño del
sistema.
Dependiendo del tipo de aplicación
existen varias arquitecturas. Ellas se distinguen según la organización de los objetos de
acuerdo a su funcionalidad. Esto es llamado dimension de arquitectura.
Dimension de la arquitectura
·
Unidimensional: un solo grupo de objetos para manejar la funcionalidad y
la interacción externa.
·
Bidimensional: un grupo de objetos para manejar la funcionalidad y otros
para las interacciones externas.
·
Tridimensional: La más usada en los sistemas de información que siendo
el Modelo-Vista-Control.
Arquitectura Modelo-Vista-Control
Es un patrón de arquitectura de
software que separa los datos de una
aplicación, la interfaz del usuario y la lógica de negocio en tres componentes
distintos. El modelo es el sistema de gestión de base de datos y la lógica de
negocio y el controlador es el responsable de recibir los eventos de entrada
desde la vista.
Modelo --> información
Vista --> presentación con el usuario
Control à comportamiento
3.2 - Identificación de clases según estereotipos
El tipo de funcionalidad o “la razón de ser” de un
objeto dentro de una arquitectura se le conoce como su estereotipo. Para los
sistemas de información la arquitectura del sistema según nuestro modelo de
análisis se basa en tres estereotipos básicos de objetos:
·
El
estereotipo entidad, para objetos que guarden información sobre el estado
interno del sistema, a corto y largo plazo, correspondiente al dominio del
problema. Todo comportamiento naturalmente acoplado con esta información
también se incluye en los objeto entidad. Un ejemplo de un objeto entidad es un
registro de usuario con sus datos y comportamiento asociados.
·
El
estereotipo interface o borde, para objetos que implementen la presentación o
vista correspondiente a las bordes del sistema hacia el mundo externo, para
todo tipo de actores, no sólo usuarios humanos. Un ejemplo de un objeto borde
es la funcionalidad de interface de usuario para insertar o modificar
información sobre el registro de usuario.
El estereotipo control, para objetos que implementen el
comportamiento o control especificando cuando y como el sistema cambia de
estado, correspondiente a los casos de uso. Los objetos control modelan
funcionalidad que no se liga naturalmente con ningún otro tipo de objeto, como
el comportamiento que opera en varios objetos entidad a la vez, por ejemplo,
hacer alguna computación y luego de volver el resultado a un objeto borde. Un
ejemplo típico de objeto control es analizar el uso del sistema por parte de
algún usuario registrado y presentar tal información posteriormente. Este
comportamiento no le pertenece a ningún objeto entidad u objeto borde
específico. Nótese que no hay ninguna restricción a los diferentes estereotipos
que puedan utilizarse, no solamente las tres anteriores. La notación de UML
para un estereotipo se muestra en la Figura:
Diagrama de clase para los tres estereotipo. Considerando
que habrá interacción entre los diferentes tipos de objetos, existirá cierto
traslape en la funcionalidad que los objetos ofrecen. Como se mencionó
anteriormente, este traslape deberá minimizarse para asegurar una buena
extensibilidad, donde típicamente, cada tipo de objeto captura por lo menos dos
de las tres dimensiones.
ENTIDAD: Se utilizan
objetos entidad para modelar la información que el sistema debe manejar a corto
y largo plazo. La información a corto plazo existe durante la ejecución de un
caso de uso, mientras que la información a largo plazo trasciende los caso de
uso, por lo que es necesario guardarla en alguna base de datos o archivos.
Durante la identificación de objeto entidad, se
encontrara que objetos que objetos similares aparecen en varios casos de uso.
Clases entidad:
Validar Usuario: Este casi de uso requiere validar
información exclusivamente guardada en el registro de usuario, lo que se
hace en la clase entidad Registro-Usuario, utiliza también por el caso de uso
Registro-Usuario.
Ofrecer Servicios: Este caso de uso administra las
opciones de servicio y no requiere de ninguna clase entidad.
Registrar Usuario: Este caso de uso requiere guardar
información exclusivamente acerca del usuario, lo que se hace en la clase
entidad Registro-Usuario.
Registrar Tarjeta: Este caso de uso requiere guardar
información exclusivamente acerca de la tarjeta del usuario lo que hace en la
clase entidad Registro-Tarjeta.
Consultar Información: Este casi de uso requiere de toda
la información relacionada con consultas. Se puede tomar las clases del dominio
del problema y quitar aquellas relacionadas con registros y reservaciones.
Hacer reservación: Este caso de uso requiere de la
información relacionada con reservaciones. Se pueden tomar las clases del
dominio del problema y quitar aquellas relacionadas con registros.
Pagar Reservación: Este caso de uso requiere de la
información relacionada con reservaciones. Dado que es una extensión al caso de
uso Hacer Reservación, no es necesario volver a repetir todas las clases
entidad, sino más bien especificar cualquier clase adicional.
CONTROL
En la mayoría de los casos de uso, existe un
comportamiento que no se puede asignar de forma natural a ninguno de los otros
dos tipos de objetos ya vistos. Una posibilidad es repartir el comportamiento
entre los dos tipos de objetos, pero la solución no es buena si se considera el
aspecto de extensibilidad. Un cambio en el comportamiento podría afectar varios
objetos, dificultando su modificación. Para evitar estos problemas, tal
comportamiento se asigna a objetos control.
Es difícil lograr un buen balance en la distribución del
comportamiento del caso de uso entre los objetos entidad, borde y control. Los
objetos de control normalmente proveen a administración de los demás tipos de
objetos.
Para llevar a
cabo la transición del modelo de requisitos al modelo de análisis se deben
identificar los objetos necesarios para implementar todos los casos de uso. La
arquitectura de objetos debe considerar los tres tipos de estereotipos de
objetos como se discutió anteriormente. Para lograr esto se debe identificar
primero las clases interface, luego las entidad y finalmente las de control. En
general, se desea asignar la funcionalidad más especializada correspondiente a
la “política” de la aplicación a los objetos control, la cual depende y afecta
al resto de los objetos. Por otro lado, los objetos entidad e interface deben
contener funcionalidad más bien local limitando su efecto en los demás objetos.
El trabajo del analista consiste en distribuir lo mejor posible el
comportamiento especificado en el modelo de requisitos en los diferentes tipos
de objetos de la arquitectura de análisis. La asignación de funcionalidad es
bastante difícil en la práctica afectando de gran manera la robustez y
mantenimiento del sistema. Los buenos analistas consideran cambios potenciales
al sistema a la hora de llevar a cabo este proceso.
En general, los
cambios mas comunes a un sistema son los cambios en su funcionalidad e
interfaces. Cambios a las interfaces deben afectar típicamente solo los objetos
interface. Cambios a la funcionalidad son mas difíciles, ya que la funcionalidad
puede abarcar todos los tipos de objetos. Si la funcionalidad esta ligada a la
información existente, tales cambios afectan al objeto entidad representado esa
información, o puede involucrar múltiples objetos incluyendo objetos control.
Típicamente, esta funcionalidad se define en uno o varios casos de uso y se
asigna a uno o varios objetos control.
A continuación
describimos en más detalles el proceso de identificación de los tres tipos de
objetos.
Interface
Toda la
funcionalidad especificada en las descripciones de los casos de uso que depende
directamente de los aspectos externos del sistema se ubica en los objetos de
interfaces. Es a través de estos objetos que se comunican los actores con el
sistema. La tarea de un clase interface es traducir los eventos generados por
un actor en eventos comprendidos por el sistema, y traducir los eventos del
sistema a una presentación comprensible por el actor.
Las clases
interface, en otras palabras, describen comunicación bidireccional entre el
sistema y los actores. Las clases interface son bastante fáciles de
identificar, donde se cuenta con al menos tres estrategias:
- Se pueden identificar en base a los actores.
- Se pueden identificar en base a las descripciones de las interfaces del sistema que acompañan al modelo de requisitos.
- Se pueden identificar en base a las descripciones de los casos de uso y extraer la funcionalidad que es específica a las interfaces.
Comenzaremos
utilizando la primera estrategia correspondiente a de actores. Cada actor
concreto necesita su propia interface para su comunicación con el sistema. En
muchos casos un actor puede necesitar de varios objetos interface. Es evidente
que los objetos interface no son totalmente independientes de cada uno ya que
deben saber de la existencia de los demás para poder resolver ciertas tareas.
Por ejemplo para Reservar un Asiento en un Vuelo el usuario debe
interactuar con las interfaces que a su vez se comunican con las interfaces que
se comunican con la base de datos del sistema de reservaciones.
Una vez
identificado los objetos interfaces, es más fácil modificar posteriormente las
interfaces de un sistema. Al tener todo lo relacionado a una interface en un
objeto, cada cambio a la interface será local a ese objeto. Como los cambios a
las interfaces son muy comunes, es vital que estos sean extensibles.
Existen dos
tipos diferentes de interfaces a modelar, interfaces a otros sistemas e
interfaces a los usuarios humanos.
- En el caso de objetos interface que se comunican con otros sistemas, es muy común que la comunicación se describa mediante protocolos de comunicación. Los objetos interface pueden traducir las salidas del sistema a un protocolo de comunicación estandarizado, o simplemente enviar eventos producidos internamente sin conversiones complejas. Una ventaja de esto, es que si se cambia el protocolo, estos cambios serán locales al objeto interface. Un mayor problema ocurre cuando existen señales continuas del mundo externo, como en los sistemas de medición o control. Entonces los objetos interface deben muestrear la señal de entrada, o interrumpir cuando ciertos valores exceden un valor umbral, ya que internamente en el sistema sólo existe comunicación discreta mediante eventos. Los objetos interface deben entonces traducir la información continua a información discreta. Problemas de cuantificación pueden aparecer y deben ser resueltos.
- En el caso de los objetos interface que se comunican con usuarios humanos, los objetos interface pueden ser complejos para modelar. Existen muchas técnicas diferentes para un buen diseño de interfaces, como el diseño de Interfaces Gráficas de Usuario (GUI - GraphicalUser Interface), Sistemas de Manejo de Ventanas de Usuario (UIMS - User Interface Management Systems) y sistemas de Interface de Programación de Aplicación (API). Es fundamental que el usuario tenga una imagen lógica y coherente del sistema. En las aplicaciones interactivas es común que la interface de usuario sea una parte mayor (hasta 80%) de la aplicación completa.
Aunque cada
tipo de objeto tiene un propósito distinto, es evidente que los objetos
interface tienen como propósito principal las presentaciones. Sin embargo,
también pueden manejar información y tener comportamiento. Cuánta información y
comportamiento debe ligarse a un objeto interface debe decidirse de manera
individual. En un extremo, el objeto interface solo envía el evento que recibe
del actor a otros objetos en el sistema, sin participar activamente en el curso
de eventos. En el otro extremo, el comportamiento del objeto interface es muy
complejo donde la información se integra en el objeto interface y puede
funcionar casi independiente de otros objetos. Generalmente, el potencial para
cambios debe afectar la decisión de qué comportamiento en el caso de uso debe
ligarse a un objeto interface particular. Cualquier cambio en la funcionalidad
directamente ligada a la interface debe ser local al objeto interface, mientras
que otros cambios no deben afectarlo. Esto es algo que debe aprenderse y
aplicarse en todas las actividades del modelado.
Para
identificar qué parte del flujo de un caso de uso debe asignarse a los objetos
interface, se debe analizar las interacciones entre los actores y los casos de
uso. Esto significa buscar aspectos con una o más de las siguientes
características:
- Presentación de información al actor que requiera información de regreso.
- Funcionalidad que cambie si cambia el comportamiento del actor.
- Flujo de acción que dependa de un tipo de interface particular.
3.3
-Clases
Las clases son declaraciones o
abstracciones de objetos, lo que significa, que una clase es la definición de
un objeto. Cuando se programa un objeto y se definen sus características y funcionalidades,
realmente se programa una clase.
Una clase es un contenedor de uno o más datos (variables o propiedades miembro) junto a las operaciones de manipulación de dichos datos (funciones/métodos). Las clases pueden definirse como estructuras (struct), uniones (union) o clases (class) pudiendo existir diferencias entre cada una de las definiciones según el lenguaje. Además las clases son agrupaciones de objetos que describen su comportamiento
Clases
Las clases son lo más simple de Java. Todo en Java forma parte de una clase, es una clase o describe cómo funciona una clase. El conocimiento de las clases es fundamental para poder entender los programas Java.
Todas las acciones de los programas Java se colocan dentro del bloque de una clase o un objeto. Todos los métodos se definen dentro del bloque de la clase, Java no soporta funciones o variables globales. Esto puede despistar a los programadores de C++, que pueden definir métodos fuera del bloque de la clase, pero esta posibilidad es más un intento de no separarse mucho y ser compatible con C, que un buen diseño orientado a objetos. Así pues, el esqueleto de cualquier aplicación Java se basa en la definición de una clase.
Todos los datos básicos, como los enteros, se deben declarar en las clases antes de hacer uso de ellos. En C la unidad fundamental son los ficheros con código fuente, en Java son las clases. De hecho son pocas las sentencias que se pueden colocar fuera del bloque de una clase. La palabra clave import (equivalente al #include) puede colocarse al principio de un fichero, fuera del bloque de la clase. Sin embargo, el compilador reemplazará esa sentencia con el contenido del fichero que se indique, que consistirá, como es de suponer, en más clases
Una clase es un contenedor de uno o más datos (variables o propiedades miembro) junto a las operaciones de manipulación de dichos datos (funciones/métodos). Las clases pueden definirse como estructuras (struct), uniones (union) o clases (class) pudiendo existir diferencias entre cada una de las definiciones según el lenguaje. Además las clases son agrupaciones de objetos que describen su comportamiento
Clases
Las clases son lo más simple de Java. Todo en Java forma parte de una clase, es una clase o describe cómo funciona una clase. El conocimiento de las clases es fundamental para poder entender los programas Java.
Todas las acciones de los programas Java se colocan dentro del bloque de una clase o un objeto. Todos los métodos se definen dentro del bloque de la clase, Java no soporta funciones o variables globales. Esto puede despistar a los programadores de C++, que pueden definir métodos fuera del bloque de la clase, pero esta posibilidad es más un intento de no separarse mucho y ser compatible con C, que un buen diseño orientado a objetos. Así pues, el esqueleto de cualquier aplicación Java se basa en la definición de una clase.
Todos los datos básicos, como los enteros, se deben declarar en las clases antes de hacer uso de ellos. En C la unidad fundamental son los ficheros con código fuente, en Java son las clases. De hecho son pocas las sentencias que se pueden colocar fuera del bloque de una clase. La palabra clave import (equivalente al #include) puede colocarse al principio de un fichero, fuera del bloque de la clase. Sin embargo, el compilador reemplazará esa sentencia con el contenido del fichero que se indique, que consistirá, como es de suponer, en más clases
3.4 - Diagrama de secuencia
El diagrama de secuencia es un tipo de
diagrama usado para modelar interacción entre objetos en un sistema según UML.
En inglés se pueden encontrar como "sequencediagram",
"event-trace diagrams", "eventscenarios" o
"timingdiagrams"
Utilidad
Un diagrama de
utilidad muestra la interacción de un conjunto de objetos en una aplicación a
través del tiempo y se modela para cada caso de uso. Mientras que el diagrama
de casos de uso permite el modelado de una vista business del escenario, el
diagrama de secuencia contiene detalles de implementación del escenario,
incluyendo los objetos y clases que se usan para implementar el escenario y
mensajes intercambiados entre los objetos.
Típicamente se
examina la descripción de un caso de uso para determinar qué objetos son
necesarios para la implementación del escenario. Si se dispone de la
descripción de cada caso de uso como una secuencia de varios pasos, entonces se
puede "caminar sobre" esos pasos para descubrir qué objetos son
necesarios para que se puedan seguir los pasos. Un diagrama de secuencia
muestra los objetos que intervienen en el escenario con líneas discontinuas
verticales, y los mensajes pasados entre los objetos como flechas horizontales.
Tipos
de mensajes
Existen dos tipos
de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se
corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto
que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de
mensajes se representan con flechas con la cabeza llena. Los mensajes
asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro
de la secuencia. Se representan con flechas con la cabeza abierta.
También se
representa la respuesta a un mensaje con una flecha discontinua.
Pueden
ser usados en dos formas
•De instancia:
describe un escenario específico (un escenario es una instancia de la ejecución
de un caso de uso).
•Genérico:
describe la interacción para un caso de uso; Utiliza ramificaciones
("Branches"), condiciones y bucles. Esta para atrás
Estructura
Los mensajes se
dibujan cronológicamente desde la parte superior del diagrama a la parte
inferior; la distribución horizontal de los objetos es arbitraria. Durante el
análisis inicial, el modelador típicamente coloca el nombre 'business' de un
mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre
'business' es reemplazado con el nombre del método que está siendo llamado por
un objeto en el otro. El método llamado, o invocado, pertenece a la definición
de la clase instanciada por el objeto en la recepción final del mensaje
3.5 –Diccionario de clases según módulos.
Un diccionario de clases es un catálogo, un
depósito, de los elementos en un sistema. Como su nombre lo sugiere, estos
elementos se centran alrededor de los datos y la forma en que están
estructurados para satisfacer los requerimientos de los usuarios y las
necesidades de la organización. En un diccionario de datos se encuentra la
lista de todos los elementos que forman parte del flujo de datos en todo el
sistema. Los elementos más importantes son flujos de datos, almacenes de datos
y procesos. El diccionario guarda los detalles y descripciones de todos estos
elementos.
El diccionario se desarrolla durante el análisis de
flujo de datos y auxilia a los analistas que participan en la determinación de
los requerimientos de sistemas.
Importancia del diccionario
Los analistas utilizan los diccionarios de datos
por cinco razones importantes:
1. Para manejar los detalles en sistemas grandes.
2. Para comunicar un significado común para todos
los elementos del sistema.
3. Para documentar las características del sistema.
4. Para facilitar el análisis de los detalles con
la finalidad de evaluar las características y determinar dónde efectuar cambios
en el sistema.
5. Localizar errores y omisiones en el sistema.
Manejo de detalles
Los sistemas grandes tienen enormes volúmenes de
datos que fluyen por ellos en forma de documentos, reportes e incluso pláticas.
De manera similar, se llevan a cabo muchas actividades que utilizan los datos
existentes o que generan nuevos detalles. Recuérdese, como se mencionó en la
historia al inicio de este capítulo, que Lodos los sistemas experimentan
cambios continuos y manejar de manera completa todos los detalles es un
desafió. Con franqueza, es imposible que los analistas recuerden todo. Los que
tratan de hacerlo cometen de manera invariable equivocaciones u olvidan
elementos importantes. Los mejores analistas no intentan recordarlo todo, en
lugar de hacerlo registran toda la información. Algunos lo hacen sobre hojas de
papel y otros quizá sobre tarjetas indexadas. Muchos emplean para tal fin un
procesador de palabras y una computadora personal por supuesto. Los analistas
mejor organizados y más eficaces utilizan diccionarios de datos automatizados
diseñados de manera específica para el análisis y diseño de sistemas.
Comunicación de significados
Los diccionarios de datos proporcionan asistencia
para asegurar significados comunes para los elementos y actividades del
sistema. Si se examina una muestra de diagramas de flujo de datos para el
procesamiento de pedidos, es probable que se tengan pocas dificultades para
comprender qué datos representan a la factura y al cheque. Los dos son términos
comunes en el mundo de los negocios y muchas personas conocen su significado.
Los diccionarios de datos registran detalles adicionales relacionados con el
flujo de datos en el sistema de tal forma que todas las personas participantes
puedan localizar con rapidez la descripción de flujos de datos, almacenes de
datos o procesos.
3.6 –Herramientas CASE para el análisis
Herramientas de alto nivel, U-CASE (Upper CASE - CASE
superior) o front-end, orientadas a la automatización y soporte de las actividades
desarrolladas durante las primeras fases del desarrollo: análisis y diseño.
Herramientas de análisis y diseño. Permiten al desarrollador
crear un modelo del sistema que se va a construir y también la evaluación de la
validez y consistencia de este modelo. Proporcionan un grado de confianza en la
representación del análisis y ayudan a eliminar errores con anticipación. Se
tienen:
- Herramientas de análisis y diseño (Modelamiento).
- Herramientas de creación de prototipos y de simulación.
- Herramientas para el diseño y desarrollo de interfaces. Máquinas de análisis y diseño. (Modelamiento)
ERwin
PLATINUM ERwin es una herramienta de
diseño de base de datos. Brinda productividad en diseño, generación, y
mantenimiento de aplicaciones. Desde un modelo lógico de los requerimientos de
información, hasta el modelo físico perfeccionado para las características
específicas de la base de datos diseñada, ERwin permite visualizar la
estructura, los elementos importantes, y optimizar el diseño de la base de
datos.
Genera automáticamente las tablas y
miles de líneas de storedprocedure y triggers para los principales tipos de
base de datos. ERwin hace fácil el diseño de una base de datos. Los diseñadores
de bases de datos sólo apuntan y pulsan un botón para crear un gráfico del
modelo E-R (Entidadrelación) de todos sus requerimientos de datos y capturar
las reglas de negocio en un modelo lógico, mostrando todas las entidades,
atributos, relaciones, y llaves importantes.
PowerDesigner
PowerDesigner es una suite
de aplicaciones de Powersoft para la construcción, diseño y modelado de datos a
través de diversas aplicaciones. Es la herramienta para el análisis, diseño
inteligente y construcción sólida de una base de datos y un desarrollo
orientado a modelos de datos a nivel físico y conceptual, que dan a los
desarrolladores Cliente/Servidor la más firme base para aplicaciones de alto
rendimiento
