UNIDAD 3
3.1 Arquitectura de Clases
El modelo de análisis tiene como objetivo generar
una arquitectura de objetos que sirva como base para el diseño posterior del
sistema. Como se discutió en la introducción del libro, dependiendo del tipo
de aplicación existen diversas arquitecturas que se pueden utilizar, siendo
de nuestro interés aquellas arquitecturas especialmente diseñadas para el
manejo de los sistemas de información, las cuales involucran ricas interfaces
de usuario y accesos a base de datos como aspectos fundamentales de la
arquitectura.
En término de las propias arquitecturas, éstas se
distinguen según la organización de la funcionalidad que ofrecen los objetos
dentro de ellas o la dimensión de los objetos. Esta
dimensión corresponde a los diferentes tipos de funcionalidad que manejan los
objetos dentro la arquitectura. Por ejemplo, en el caso de funcionalidad para
el manejo de interfaces y base de datos, si existen tipos distintos de objetos
para el manejo de cada una de estas por separado, entonces se considera que
la arquitectura es de dos dimensiones. Por el contrario, si todos
los objetos manejan de manera indistinta los dos tipos de funcionalidades,
entonces se considera que la arquitectura es de una sóla
dimensión.
Si aplicamos el concepto de dimensión a los
métodos estructurados, podemos ver que estos consisten de dos dimensiones,
correspondientes a funciones y datos. Las funciones representan un eje de
comportamiento que no guarda información, mientras que los datos se ubican en
un eje de información que no contiene comportamiento. En general, ejes de
funcionalidad pueden corresponder a distintos tipos de funcionalidades, como
se ve al contrastar funciones y datos versus manejo de interfaces y bases de
datos. Sin embargo, la pregunta más importante que uno se hace respecto al
número y tipo de dimensiones es: ¿Si se diseña un sistema con múltiples
dimensiones, se obtendría un sistema más robusto y sensible a modificaciones?
Ante todo esta pregunta se relaciona con el concepto de modularidad, siendo
muy aceptado que cuanto mayor sea la modularidad de un sistema mayor es su
robustez y extensibilidad. La respuesta particular a la pregunta tiene que
ver con qué tan independiente sea un eje de funcionalidad del otro, ya que en
el caso de los métodos estructurados, usualmente se debe modificar las
funciones cada vez que se modifica la estructura de información, lo cual no
es algo deseable. Si logramos ejes de funcionalidad ortogonales, el efecto de
cambios en una dimensión no debe afectar a las otras dimensiones. Y aunque
estas dimensiones no son del todo ortogonales, si son lo suficientemente
independientes se puede limitar el efecto de posibles cambios. En relación al
número de dimensiones, esto depende de la funcionalidad que la arquitectura
debe manejar, algo que a su vez depende del tipo de aplicación que se está
desarrollando.
En el caso de los sistemas de
información, uno de las tipos de arquitecturas más importantes es la
arquitectua MVC – Modelo, Vista, Control (Model, View,
Control) popularizada por los ambientes de desarrollo de Smalltalk.
Esta arquitectura se basa en tres dimensiones principales: Modelo
(información), Vista (presentación) y Control (comportamiento)
|
3.2 Identificación de clases según estereotipos
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. Para ello se deben identificar primero las clases borde, las clases entidad y finalmente las de Control.
En general, los cambios más
comunes a un sistema son los de funcionalidad y bordes. Los cambios de las
interfaces deben afectar solo a los objetos borde.
Los cambios a la funcionalidad
son más difíciles de administrar, ya que ésta puede abarcar todos los tipos de
objetos.
Considerando que habría interacción entre los diferentes tipos de objetos, existiría cierto traslape en la funcionalidad que los objetos ofrecen. como se menciono 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. sin embargo, cada uno de ellos tiene cierta inclinación hacia una de estas dos dimensiones.
3.3 clases
Una clase es una construcción que se utiliza
como un modelo (o plantilla) para crear objetos de ese tipo. El modelo describe el
estado y el comportamiento que todos los objetos de la clase comparten. Un
objeto de una determinada clase se denomina una instancia de la clase. La clase que contiene (y
se utilizó para crear) esa instancia se puede considerar como del tipo de ese
objeto. Por ejemplo, una instancia del objeto de la clase "Persona"
sería del tipo "Persona".
Una clase por lo general representa un sustantivo,
como una persona, lugar o (posiblemente bastante abstracta) cosa - es el modelo
de un concepto dentro de un programa de computadora. Fundamentalmente,
encapsula el estado y el comportamiento del concepto que representa. Encapsula
el estado a través de marcadores de datos llamados atributos (o variable miembro o variables de
instancia), y encapsula el comportamiento a través de secciones de código
reutilizables llamados métodos.
Más técnicamente, una clase es un conjunto
coherente que consiste en un tipo particular de metadatos. Una clase tiene una
interfaz y una estructura. La interfaz describe cómo interactuar con la clase y
sus instancias con métodos, mientras que la estructura describe cómo los datos
se dividen en atributos dentro de una instancia. Una clase también puede tener
una representación (metaobjeto) en tiempo de ejecución, que proporciona apoyo
en tiempo de ejecución para la manipulación de los metadatos relacionados con
la clase. En el diseño orientado a objetos, una clase es el tipo más específico
de un objeto en relación con una capa específica.
Los lenguajes de programación que soportan clases
difieren sutilmente en su soporte para diversas características relacionadas
con clases. La mayoría soportan diversas formas de herencia. Muchos lenguajes también
soportan características para proporcionar encapsulación, como especificadores
de acceso.
3.4 Diagramas de secuencias
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 "sequence diagram", "event-trace
diagrams", "event scenarios" o "timing diagrams"
Un diagrama
de secuencia 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
3.5 Diccionario de clases según módulos
·
Como última etapa del modelo de análisis, se
actualiza el diccionario de clases organizada según módulos, para incluir todas
las clases identificadas durante el modelo de análisis.
·
Las clases se separan en diferentes módulos con el
fin de lograr una mejor organización y correspondencia entre clases y
casos de uso.
·
Aquellas clases que participan en varios casos de
uso se pueden asignar a módulos adicionales
MODULOS O
PAQUETES PRINCIPALES
InterfaceUsuario
Principal
Registros
Servicios
InterfaceUsuario
Modulo
compuesto por una clase utilizada para el manejo general de las interfaces de
usuario:
InterfaceUsuario:
Clase Borde. Toda la interacción con el usuario se hace por medio del borde
deusuario.
Principal
Está compuesto
por clases comunes a la funcionalidad general del sistema:
PantallaPrincipal-
Clase Borde
ManejadorPrincipal-
Clase Control
Registro
El modulo
registro se divide en los siguientes módulos:
Usuario: PantallaCrearRegistroUsuario,
PantallaObtenerRegUsuario, RegistroUsuario yManejadorRegistroUsuario.
Tarjeta: PantallaCrearRegTarjeta,
PantallaObtenerRegTarjeta, RegistroTarjeta y ManejadorRegistroTarjeta.
InterfaceBD: Está
compuesto por la clase encargada de interactuar con la base de datos. InterfaceBaseDatosRegistro.Donde
BD corresponde a la base de datos.
Servicios
Se divide en
los siguientes módulos (MODULOS ADICIONALES):
DOMINIO: Vuelo,
reservación, horario, aerolínea, aeropuerto, tarifa, asiento, pasajero, avión y
viajeroFrecuente.
INTERFACEBD: incluye
una clase para el acceso a la base de datos.InterfaceBaseDatosReserva.
CONSULTAS: PantallasConsultas,
ManejajadorConsultas.
HORARIOS: PantallaConsultaHorarios,
PantallaResultadoHorarios yManejadorConsultaHorarios.
TARIFAS: PantallaConsultaTarifas,
PantallaResultadoTarifas yManejadorConsultaTarifas.
ESTADO: PantallaConsultaEstado, PantallaResultadoEstado
yManejadorConsultaEstado
PAGOS: PantallaPagarRegTarjeta,
PantallaReembolsarRegTarjeta y ManejadorPagos.
3.6. Herramientas CASE para el análisis
Las
herramientas CASE (Computer Aided Software Engineering,Ingeniería de Software
Asistida por Computadora) son diversas aplicaciones informáticas destinadas a
aumentar la productividad en el desarrollo de software reduciendo el costo de
las mismas en términos de tiempo y de dinero. Estas herramientas pueden ayudar
en los aspectos del ciclo de vida de desarrollo del software en tareas como:
·
El proceso de realizar un diseño del proyecto,
·
cálculo de costos,
·
Implementación de parte del código automáticamente
con el diseño dado,
·
Compilación automática,
·
Documentación o detección de errores entre otras.
OBJETIVOS
·
Mejorar
la productividad en el desarrollo y mantenimiento del software.
·
Aumentar
la calidad del software.
·
Reducir
el tiempo y costo de desarrollo y mantenimiento de los sistemas informáticos.
·
Mejorar
la planificación de un proyecto
·
Aumentar
la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda
de soluciones para los requisitos.
·
Automatizar
el desarrollo del software, la documentación, la generación de código, las
pruebas de errores y la gestión del proyecto.
·
Ayuda
a la reutilización del software, portabilidad y estandarización de la documentación
·
Gestión
global en todas las fases de desarrollo de software con una misma herramienta.
·
Facilitar
el uso de las distintas metodologías propias de la ingeniería del software.
