lunes, 22 de abril de 2013

Unidad 3 "Modelo de Análisis" 3.1 Arquitectura de Clases


Unidad 3 “modelo de análisis”
3.1 Arquitectura de clases
El modelo de análisis tiene como objetivo generar una arquitectura de objetos que sirvan como base para el diseño posterior del sistema.
En términos de las propias arquitecturas, estas se distinguen según la organización de la funcionalidad que nos ofrece los objetos dentro de ellas a la dimensión de los objetos. Esta dimensión corresponde a los diferentes tipos de funcionalidad para el manejo de borde a 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 lo 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 los sistemas de información uno de los tipos de arquitectura más importante es la arquitectura: 
v  Control (comportamiento)
v  Modelo (información)
v  Vista (presentación)
La vista o presentación de la información corresponde a los bordes que se le presentan al usuario pare el manejo de la información, donde por lo general puede 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.
El control corresponde a la manipulación de la información a través de sus diversas presentaciones.



3.2 Identificacion de Clases según Estereotipos


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 estereotipos.
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) para objetos que guarden información sobre el estado interno del sistema, a corto y largo plazo, corresponde al dominio del problema un ejemplo: de un objeto entidad es un registro de usuario con sus datos y comportamientos asociados.
El estereotipo interface o borde: para objetos que implementan la presentación o vista correspondientes a los bordes del sistema hacia el mundo externo para todo tipo de actores, no solo usuarios humanos.
Estereotipo control: para objetos que implementen el comportamiento o control especificando cuando y como el sistema cambia de estado, correspondientes a los casos de usos.
Los objetos control modelan funcionalidad que no se ligan naturalmente con ningún otro tipo de objeto.

3.3. Clases


3.3.- clases
Un diagrama de clases muestra un resumen de un sistema a través de clases y a las relaciones entre dichas clases.
Son los diagramas más comunes en el modelado y programación de sistemas orientados a objetos.
Son estáticos: muestra que elementos interactúan pero no que sucede cuando ellos hacen la interacción.
Los diagramas de clases: son importantes no solo para la visualización, especificación y documentación del modelo estructural, si no también para la construcción de sistemas ejecutables.
Relaciones entre clases: las relaciones entre clases representan asociaciones del mundo del problema. Las relaciones entre dichas clases son conexiones entre dichas clases.
Tipos de relaciones:
Ø  Asociación
Ø  Generalización (herencia)
Ø  Agregación
Ø  Descendencia
Ø  Composición
Características de las relaciones:
Ø  Roles
Ø  Navegabilidad
Ø  Cardinalidad
Relación de dirección unidireccional:
Si la relación es navegable y la cardinalidad de la clase destino es 0..1  entonces: en la clase fuente, se coloca un atributo privado de la clase destino.
Relación de asociación bidireccional:
Esta es navegable en ambos sentidos y la cardinalidad en ambos sentidos es <- se coloca un atributo privado en cada clase que haga referencia a la otra clase.


3.4 Diagramas de Frecuencia


3.4 diagramas de frecuencia
Describe las secuencia de intercambio de mensajes entre roles que implementan el comportamiento del sistema. Muestra el flujo de control a través de dichos objetos.
Un diagrama de secuencia muestra:
Ø  Interacción de un conjunto de objetos en una aplicación a través del tiempo.
Ø  Un conjunto de mensajes, dispuestos en una secuencia temporal
Ø  Cada rol en la secuencia como una línea de vida, es decir una línea vertical.
Un diagrama de secuencia representa una interacción como un gráfico bidimensional.
Ø  La dimensión  vertical: es el eje del tiempo
Ø  La dimensión horizontal: muestra los roles de clasificador que representan objetos individuales en la colaboración.
Tipos de flujos de control:
Los envíos síncronos (flujos de control plano)
Ø  Muestra la progresión al próximo paso de la secuencia.
Ø  Son envíos secuenciales, en los que el emisor está bloqueado y espera que el receptor haya terminado de tratar el mensaje.
Los envíos o flujos de control asíncrono:
Ø  En los que el emisor no está bloqueado y puede continuar su ejecución.
Llamada a procedimiento u otro flujo de control anidado:
Ø  La secuencia anidada completa debe finalizar antes de reanudar la secuencia de nivel externo.
Ø  Se puede emplear en llamadas normales o procedimientos.
Ø  También se puede utilizar como objetos activos concurrentemente cuando uno de ellos envía una señal y espera a que finalicé una secuencia de comportamiento anidado.
Objeto activo:
Es un objeto que contiene a la raíz de una pila de activaciones.
Ø  Como objetos activos tiene su propio hilo de control dirigido por eventos que se ejecutan en paralelo a otros objetos activos.
Ø  Los objetos que son llamados por un objeto activo son objetos pasivos; reciben el control solamente cuando son llamados y los seden cuando retornan.

3.5 Diccionarios segun tipos de Modulos


3.5 diccionario de clases según módulos
Es un listado organizado de todos los datos pertinentes al sistema. Posee definiciones precisas de todos los flujos de datos, elementos y estructura de datos almacenados y entidades, para que tanto el usuario y el analista tengan un conocimiento completo de ellos.
Además se puede usar:
Ø  Validar dfd (que sea completo y preciso)
Ø  Proporciona un punto inicial para el desarrollo de pantallas e informes.
Ø  Determina el contenido de los datos almacenados en los archivos.
Ø  COMO  ULTIMA ETAPA DEL MODELO DE ANALISIS, SE ACTUALIZA EL DICCIONARIO DE CLASES ORGANIZADAS SEGÚN MODULOS, PARA INCLUIR TODAS LAS CLASES IDENTIFICADAS DURANTE EL MODELO DE ANALISIS
Ø  LAS CLASES SE SEPARAN EN DIFERENTES MODULOS CON EL FIN DE LOGRAR UNA MEJOR ORGANIZACIÓN Y CORRESPONDENCIA ENTRE CLASES Y CASOS DE USOS
AQUELLAS CLASES QUE PARTICIPAN EN VARIOS CASOS DE USO SE PUEDEN ASIGNAR A MODULOS ADICIONALES
MODULOS O PAQUETES PRINCIPALES:
  INTERFACE-USUARIO
  PRINCIPAL
  REGISTROS
  SERVICIOS
Interface usuario:
  MODULO COMPUESTO POR UNA CLASE UTILIZANDO PARA EL MANEJO GENERAL DE LAS INTERFACES DE USUARIO
  InterfaceUsuario – Clase Borde. Toda la interacción con el usuario se hace por medio de la borde de usuario.
Principal:
  Esta compuesto por clases comunes ala funcionalidad general del sistema:
  Pantalla Principal - Clase Borde. Pantalla principal (P-1).
  Manejado rPrincipal - 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.


3.6 Herramientas Case


3.6 herramientas case
La tecnología case es la automatización del desarrollo de 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 relació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
ü  Un diccionario
ü  El meta modelo
ü  La carga o descarga de datos
ü  Una comprobación de errores
ü  Un interface de usuario

Estructura general de una herramienta case:
v  Case de alto nivel: es la herramienta que automatiza o apoya a las fases superiores del ciclo de vida del desarrollo del sistema como la planificación de sistemas, el análisis y el diseño de sistemas.
v  Case bajo nivel: es la herramienta que automatiza apoya las fases inferiores del ciclo de vida como el diseño detallado del sistema, la implantación de sistemas y el soporte de sistemas.
v  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 la gestión de proyectos y la estimación.
La primera clasificación case:
Toolkit: es la colección de herramientas que permiten automatizar un conjunto de tareas de las fases del ciclo de vida del sistema informático, planificación estratégica, análisis, diseño y generación de programas.
Workbench: son conjunto de herramientas que dan soporte a la automatización del proceso de desarrollo del sistema informático.
Clasificación teniendo en cuenta el ciclo de vida que automatizan:
Uppr case: requerimiento de desarrollo funcional de planes corporativos.
Middle case: análisis y diseño
Lower case: generación de código e implementación.