domingo, 21 de abril de 2013

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 bordes 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 bordes 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  sola 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 bordes 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ían 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 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. 

La vista o presentación de la información corresponde a las bordes que se le presentan al usuario para el manejo dela información, donde por lo general pueden existir múltiples vistas sobre un mismo modelo. Típicamente la información representa el dominio del problema y es almacenada en una base de datos. Por otro lado el control corresponde a la manipulación de la información a través de sus diversas presentaciones. Y aunque existe cierta dependencia entre estas tres dimensiones se considera que la manera de presentar la información es independiente dela propia información y de cómo esta se controla. Sin embargo, cada una de ellas probablemente experimente cambios a lo largo de la vida del sistema, donde el control es el más propenso a ser modificado, seguido de la vista y finalmente el modelo. En el modelo de análisis descrito aquí utilizaremos como base la arquitectura


MVC
Para capturar estos tres aspectos de la funcionalidad, como se muestra en la Figura 7.3. Es importante notar la correspondencia con las tres dimensiones utilizadas durante el modelo de requisitos. La razón de ser de las tres dimensiones del modelo de requisitos realmente se deriva para lograr una rastreabilidad con la arquitectura que se desarrollará en el modelo de análisis.



3.2. Identificacion de Clases Segun 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  (“entity” en inglés) 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 (“boundary” en inglés) 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 (“control” en inglés) 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 devolver 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. 



  









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. Sin embargo, cada uno de ellos tiene cierta inclinación hacia una de estas dos dimensiones.



3.3. Clases

QUÉ ES UNA CLASE?



En la programación orientada a objetos, 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 que las 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.

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. Por definición, todos los objetos que existen dentro de una clase heredan sus atributos y las operaciones disponibles para la manipulación de los atributos;


*Una Superclase es una colección de clases.
*Subclase es una instancia de una clase.






MÉTODOS EN LAS CLASES
  •      Los métodos son el equivalente a las funciones en programación estructurada. Se diferencian de ellos en que es posible acceder a las variables de la clase de forma implícita.
  •       Cuando se desea realizar una acción sobre un objeto, se dice que se le manda un mensaje invocando a un método que realizará la acción. 

   IDENTIFICACIÓN DE CLASES
       La identificación de clases del dominio del problema se obtiene principalmente de algún documento textual que describa el sistema. Aunque pudiéramos tomar como punto de partida los documentos desarrollados para el modelo de casos de uso, a menudo la descripción original del problema es suficiente. Se comienza este proceso mediante la identificación de las clases candidatas, explícitas o implícitas, a las que se refiera la descripción del problema.





3.4. Diagramas de Secuencias



Objetivo


•El objetivo del modelo de análisis 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 dimensión de la arquitectura.


Dimensión de la arquitectura
•Unidimensional: un solo grupo de objetos para manejar la funcionalidad y la interacción externa.
•Dos dimensiones: un grupo de objetos para manejar la funcionalidad y otros para las interacciones externas
•Tres dimensiones: la mas utilizada en los sistemas de información à Modelo-Vista-Control (MVC).



DIAGRAMA DE SECUENCIAS





DIAGRAMA DE SECUENCIA CON EVENTOS



CARACTERÍSTICAS
*Los objetos se comunican mediante interfaces, para poder invocar a un operación.
*En los Casos de Uso se modelan las características del sistema y se desarrollan escenarios.
*El diagrama de secuencias proporciona un camino a partir de los escenarios para describir las operaciones en una forma más detallada.


PROCEDIMIENTO
*El usuario crea una orden.
*El usuario trata de poner ítems en la orden.
*Se checa disponibilidad de cada ítem en el inventario.
*Si el producto está disponible, se libera  la orden.
*Fin.

EJEMPLOS  DE DIAGRAMA DE SECUENCIAS






3.5. Diccionario de Clases segun Modulos

En este apartado se muestra algunos de los aspectos bàsicos de lo que son diccionarios de clases segun modulos.









InterfaceUsuario• Interface Usuario – Clase Borde. Toda la interacción con el usuario se hace por medio de la borde de usuario.

Principal
• Pantalla Principal - Clase Borde. Pantalla principal (P-1).

• Manejador Principal - Clase Control. El manejador principal es el encargado de desplegar la pantalla principal de interacción con el usuario, y luego delegar las diferentes funciones a los manejadores especializados apropiados.

Usuario
• Pantalla Crear Reg Usuario - Clase Borde. Pantalla de solicitud de registro de usuario (P-3).
• Pantalla Obtener Reg Usuario - Clase Borde. Pantalla de devolución con información de registro de usuario (P-4).
• RegistroUsuario - Clase Entidad. Para poder utilizar el sistema de reservaciones, el usuario debe estar registrado con el sistema. El registro contiene información acerca del usuario que incluye nombre, dirección, colonia, ciudad, país, código postal, teléfono de casa, teléfono de oficina, fax, email, login y password.
• ManejadorRegistroUsuario - Clase Control. El manejador de registro de usuario se encarga de todo lo relacionado con registro del usuario para poder utilizar el sistema.

Tarjeta
• Pantalla Crear Reg Tarjeta- Clase Borde. Pantalla de solicitud de registro de tarjeta (P-5).
   Diseño : Diccionario de Datos (v 1.0) Weitzenfeld 2
• Pantalla Obtener Reg Tarjeta - Clase Borde . Pantalla de devolución con información de registro de tarjeta (P-6).
• Registro Tarjeta - Clase Entidad. Para poder hacer un pago con una tarjeta de crédito, se debe tener un registro de tarjeta. El registro contiene información acerca de la tarjeta incluye ndo nombre, número, expedidor y vencimiento. LA tarjeta está ligada a un registro de usuario.
• Manejador Registro Tarjeta - Clase Control. El manejador de registro de tarjeta se encarga de todo lo relacionado con registro de la tarjeta del usuario para poder pagar las reservaciones.



Interface BD• Interface Base Datos Registro - Clase Borde. La información de cada usuario se almacena en la base de datos de registro la cual se accesa mediante la borde de la base de datos de registro. Esto permite validar a los distintos usuarios además de guardar información sobre la tarjeta de crédito para pagos en línea.

Dominio
• Datos - 
Clase Entidad. Superclase común para todas las clases entidad del sistema.


Principal
• Pantalla Servicio - Clase Borde. Pantalla de servicios (P-2).
• Manejador Servicio - Clase Control. El manejador de servicios se encarga de enviar las
peticiones particulares de servicios a los manejadores espacializados para consulta, reserva y compra.




"AQUI HAY UN EJEMPLO SOBRE UNA RESERVACIÒN DE VUELO INVOLUCRANDO TODAS LAS CLASES SEGÙN MODULOS"



Dominio
• Vuelo - Clase Entidad. Se denomina por medio de un número. El vuelo tiene como origen un aeropuerto en una ciudad y tiene como destino un aeropuerto de otra ciudad. Un vuelo puede tener múltiples escalas y múltiples vuelos se relacionan por medio de conexiones. El vuelo pertenece a una aerolínea y puede operar varios días a la semana teniendo un horario de salida y otro de llegada.

Reservación - Clase Entidad. Para poder tomar un vuelo es necesario contar con una reservación previa, la cual debe pagarse antes de una fecha límite, que puede ser el propio día del vuelo. Una reservación puede hacerse para múltiples vuelos y múltiples pasajeros. La reservación cuenta con una clave identificando un récord de reservación particular.

• Horario - Clase Entidad. El horario de un vuelo se determina por su hora de salida y hora de llegada durante los días que opera.

• Aerolínea - Clase Entidad. La aerolínea provee servicio de múltiples vuelos entre diferentes ciudades bajo diferentes horarios. La aerolínea se identifica por un nombre.

• Aeropuerto - Clase Entidad. El aeropuerto sirve como origen, destino y escalas de un vuelo. El aeropuerto se encuentra en una ciudad de un país determinado.

• Tarifa - Clase Entidad. Los diferentes vuelos tienen múltiples tarifas para compra de boleto, variando según la clase de boleto, si son de ida o de ida y vuelta, y dependiendo de las diversas restricciones y ofertas existentes.

• Asiento - Clase Entidad. Una reservación de vuelo puede incluir la asignación de asiento, especificada mediante una fila y un número. El número de asientos disponibles en un vuelo particular dependen del tipo de avión que opere ese día.

 Pasajero - Clase Entidad. Para poder hacer una reservación se requiere dar el nombre del pasajero. Varios pasajeros pueden aparecer bajo una sola reservación.

• Avión - Clase Entidad. Un vuelo en una fecha determinada se hace en un tipo de avión particular. El tipo de avión define la cantidad máxima de pasajeros que pueden viajar en ese vuelo para esa fecha.

Viajero Frecuente - Clase Entidad. El pasajero tiene la opción de acumular millas para un vuelo particular si cuenta con una tarjeta de viajero frecuente para la aerolínea correspondiente.

Interface BD

• Interface Base Datos Reserva - Clase Borde. La información del sistema de reservaciones de vuelo se almacena en la base de datos de reservas la cual se accesa mediante la borde de la base de datos de reservas. Esto permite generar consultas, reservas y pago de reservas de manera dinámica.


Principal
• Pantalla Consultas - Clase Borde. Pantalla de presentación de consultas (P-7).


• Manejador Consultas - Clase Control. El manejador de consulta se encarga de enviar las peticiones de consulta particular a los manejadores de consulta especializados.
Horarios• Pantalla Consulta Horarios - Clase Borde. Pantalla de presentación de consulta de horarios (P-8).

Pantalla Resultado Horarios - Clase Borde. Pantalla de devolución de consulta de horarios (P-9).



• Manejador Consulta Horarios - Clase Control. El manejador de consulta de horarios se encarga de controlar las peticiones de consulta de horarios.

• Consulta Horario - Clase Entidad. Recibe toda la información del usuario para la solicitud 
de consulta de horarios.

• Resultado Horario - Clase Entidad. Devuelve el resultado de la información del usuario para la solicitud de consulta de horarios.


Tarifas
• Pantalla Consulta Tarifas - Clase Borde. Pantalla de presentación de consulta de tarifas (P-10).

• Pantalla Resultado Tarifas - Clase Borde. Pantalla de devolución de consulta de tarifas (P-11).



• Manejador Consulta Tarifas - Clase Control. El manejador de consulta de tarifas se encarga de controlar las peticiones de consulta de tarifas.

• Consulta Tarifa - Clase Entidad. Recibe toda la información del usuario para la solicitud de consulta de tarifas.

 Resultado Tarifa - Clase Entidad. Devuelve el resultado de la información del usuario para la solicitud de consulta de tarifas.





Estado• Pantalla Consulta Estado - Clase Borde. Pantalla de presentación de consulta de estado (P-12).

• Pantalla Resultado Estado - Clase Borde. Pantalla de devolución de consulta de estado (P-13).

• Manejador Consulta Estado - Clase Control. El manejador de consulta de estado se encarga de controlar las peticiones de consulta de estado.

• Consulta Estado - Clase Entidad. Recibe toda la información del usuario para la solicitud de consulta de estado.

 Resultado Estado - Clase Entidad. Devuelve el resultado de la información del usuario para la solicitud de consulta de estado.



Reservas• Pantalla Clave Reservas - Clase Borde. Pantalla de solicitud de clave de reservas (P-14).

• Pantalla Crear Reserva Vuelos - Clase Borde. Pantalla de solicitud de reservas (P-15).

• Pantalla Record Reserva Vuelos - Clase Borde. Pantalla de devolución de reservas (P-16).

• Manejador Reservas - Clase Control. El manejador de reserva se encarga de enviar las solicitudes de reserva a la base de datos del sistema de reservaciones Pagos

• Pantalla Pagar Reg Tarjeta- Clase Borde. Pantalla de solicitud de pago de reservas (P-17).

• Pantalla Reembolsar Reg Tarjeta - Clase Borde. Pantalla de solicitud de reembolso de pago (P-18).

• Manejador Pagos - Clase Control. El manejador de compra se encarga de enviar las solicitudes de compra de boleto a la base de datos del sistema de reservaciones.



3.6. Herramientas CASE para el analisis

De acuerdo con Kendall el desarrollo de sistema es asistida por ordenadores es la aplicación de informática, es acelerar el proceso para que han sido desarrolladas. En cambio la herramienta CASE (Computer-Aided Software Engineering) sirve para apoyar una fase del ciclo de vida del sistema.

Cuando se planifica la base de datos permite escoger una herramienta CASE para llevar de forma eficaz y posible las tareas, también suelen incluir.
• Un diccionario para los datos de la aplicación de base de datos.

• Herramientas de diseño para dar apoyo al análisis de datos.

• Herramientas para desarrollar el modelo de datos corporativo, los esquemas conceptual y lógico.

•Herramientas para desarrollar los prototipos de las aplicaciones.

• Con el uso de la herramienta CASE puede mejorar la productividad de aplicaciones de base de datos.


HISTORIA
En la década de los setenta el proyecto ISDOS desarrollo un lenguaje llamado "Problem Statement Language" (PSL) para la solución de un problema informático en un diccionario automatizado. Era un producto de que analizaba los problemas y necesidades.
La primera herramienta era para PC llamada "Excelerator" en 1984, la oferta de herramientas es muy amplia como es el EASYCASE o WINPROJECT.





TECNOLOGÍA
La tecnología CASE es la automatización del desarrollo software para mejorar la calidad del sistema de información.

•Permitir aplicaciones prácticas de metodologías estructuradas, al ser realizadas con una herramienta consigue agilizar el trabajo.

•Facilitar la realización de prototipos y desarrollo conjunto de aplicaciones.

•Simplificar el mantenimiento de los programas.

•Mejorar y estandarizar la documentación

•Aumentar la portabilidad de las aplicaciones.

•Facilitar la reutilización de componentes software.

•Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la utilización de gráficos.



COMPONENTES DE UNA HERRAMIENTA CASE
Una herramienta case podemos decir que se compone de:

•Un diccionario donde se almacenan los elementos creados por la herramienta, cuya gestión se realiza mediante el apoyo de un sistema de Gestión de base de datos (SGBD).

•El meta modelo, que constituye el marco para la definición de técnicas y metodologías soportadas por la herramienta. No siempre es visible.

•La carga o descarga de datos, permiten cargar el repertorio de la herramienta CASE con datos provenientes de otros sistemas, o generan a partir de la propia herramienta esquemas de base de datos, programas, pueden alimentar otros sistemas. Este elemento proporciona un medio de comunicación con otras herramientas.

•Una comprobación de errores que permiten llevar a cabo un análisis de la exactitud, integridad y consistencia de los esquemas generados por la herramienta.

•Una interfaz de usuario, que constará de editores de texto y herramientas de diseño gráfico que permitan la utilización de un sistema de ventanas, iconos y menús, con la ayuda del ratón, definir los diagramas, matrices.






ESTRUCTURA GENERAL DE UN HERRAMIENTA CASE
La estructura CASE se basa en lo siguiente:

•Un CASE de alto nivel es la herramienta que automatiza o apoya las fases superiores del ciclo de vida del desarrollo de sistemas como la planificación de sistemas, el análisis de sistemas y el diseño de sistemas.

•Un CASE de bajo nivel es la herramienta que automatiza o apoya las fases inferiores del ciclo de vida como el diseño detallado de sistemas, la implantación de sistemas y el soporte de sistemas.

•Un CASE cruzado de ciclo de vida se aplica a las herramientas que apoyan actividades a lo largo de todo el ciclo de vida, se incluyen actividades como la gestión de proyectos y la estimación.



ESTADO ACTUAL
 En las últimas décadas se ha trabajado en el desarrollo de sistemas para encontrar técnicas para incrementar la productividad y calidad en el proceso de elaboración del software, hoy la herramienta CASE (Computer Aided Software Engineering) a remplazado el papel y lápiz por el ordenador para la transformación del desarrollo de software en un proceso automatizado.
La tecnología CASE supone la automatización del desarrollo de software para elevar la productividad y la calidad en el desarrollo de sistemas análogas a lo que suponen las técnicas CAD/CAM en este enfoque permite mejorar la calidad del software.

•La mejora y la estandarización de la documentación.

•Aumentar la portabilidad de las aplicaciones.

•Facilitar la reutilización de componentes de software

•Permitir un desarrollo y un refinamiento de las aplicaciones, mediante la utilización de controles gráficos.



INTEGRACIÓN DE LAS HERRAMIENTAS CASE EN EL FUTURO
 Esta herramienta evoluciona en tres tipos de integración.

1.La integración de datos dispone de herramientas CASE con diferentes estructuras de diccionarios para el intercambio de datos.

2.La integración de presentación confiere a todas las herramientas CASE el mismo aspecto.

3.La integración de herramientas CASE son capaces de invocar a otras CASE de forma automática.






CLASIFICACIÓN DE LAS HERRAMIENTAS CASE
 Las herramientas no tienen una única clasificación y es difícil determinarlo en una clase y pueden ser clasificadas de acuerdo a:

- Las plataformas que soportan.
- Las fases del ciclo de vida del desarrollo de sistemas que cubren.
- La arquitectura de aplicaciones que producen.
- Su funcionalidad.


CITA BIBLIOGRÀFICA:

ELABORÓ: ZEFERINO GUERRERO HERNÀNDEZ
CARRERA: ING EN SISTEMAS COMPUTACIONALES
SEMESTRE Y GRUPO: 4TO. MOD_1
MATERIA: FUNDAMENTOS DE INGENIERÌA DE SOFTWARE
DOCENTE: MC MARÌA GUADALUPE RIVERA GARCÌA