UNIDAD 3 MODELO DE ANÁLISIS
Unidad 3
Objetivo de la unidad
Identificar a través de un
modelo de requisitos la arquitectura de clases que participaran en el diseño
del producto.
El
modelo de análisis debe cumplir tres objetivos primarios: 1. Describe
lo que requiere el cliente 2. Establecer una base para la creación de un
diseño de software 3. Definir un conjunto de requisitos que puedan
validarse una vez construido el software.
Reglas
prácticas para el Modelado de Análisis El modelo debe centrarse en los
requisitos visibles dentro del problema o dominio de negocio. Se debe
minimizar el acoplamiento de todo el sistema Se debe tener la seguridad
de que el modelo de análisis proporciona valor a todos los interesados.
El modelo debe mantenerse tan simple como sea posible.
3.1ARQUITECTURA DE CLASES
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 arquitectura.
Dimensión 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.
3.2 Identificación de clases según estereotipos
Clases con
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.
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.
3.4 diagrama de secuencias
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
Un rol de
clasificador:
- Es la descripción de un objeto que desempeña un determinado papel dentro de una interacción, distinto de los otros objetos de la misma clase.
- La primera utilización de los diagramas de secuencia corresponde a la documentación de los casos de uso, se concentra en la descripción de la interacción,
La segunda utilización corresponde a un uso
más informático y permite la representación precisa de
las interacciones entre objetos.
Por lo tanto
puede mostrar:
- Escenario como la historia individual de la transacción que detalla los casos de uso, aclarándolos al nivel de mensajes de los objetos existentes, como también
- El uso de los mensajes de las clases diseñadas en el contexto de una operación.
Cuando está
implementado el comportamiento,
Cada mensaje en un diagrama
de secuencia
Corresponde a:
- Una operación en una clase,
- A un evento disparador, o
- A una transición en una máquina de estados.
3.5 diccionario de clases según módulos
Los diccionarios de datos son el
segundo componente del análisis del flujo de datos. En sí mismos los diagramas
de flujo de datos no describen por completo el objeto de la investigación. El
diccionario de datos proporciona información adicional sobre el sistema. Esta
sección analiza que es un diccionario de datos, por qué se necesita
en el análisis de flujo de datos y como desarrollarlo. Se utilizará el ejemplo
del sistema de contabilidad para describir los
diccionarios de datos.
Un diccionario de datos
es una lista de todos los elementos incluido en el conjunto de los diagramas de
flujo de datos que describen un sistema. Los elementos principales en un
sistema, estudiados en las secciones anteriores, son el flujo de datos, el almacenamiento de datos y los
procesos. El diccionario de datos almacena detalles y descripciones de estos
elementos.
Si los analistas desean
conocer cuántos caracteres hay en un dato, con qué otros nombres se le conocen
en el sistema, o en donde se utilizan dentro del sistema deben ser capaces de
encontrar la respuesta en un diccionario de datos desarrollado apropiadamente.
El diccionario de dato
se desarrolla durante el análisis de flujo de datos y ayuda el analista
involucrado en la determinación de los requerimientos de sistemas. Sin embargo,
como se verá más adelante, también el contenido del diccionario de datos se
utiliza durante el diseño del sistema.
En informática, base de datos acerca
de la terminología que se utilizará en un sistema de información. Para
comprender mejor el significado de un diccionario de datos, puede considerarse
su contenido como "datos acerca de los datos"; es decir,
descripciones de todos los demás objetos (archivos, programas, informes, sinónimos...)
existentes en el sistema. Un diccionario de datos almacena la totalidad de los
diversos esquemas y especificaciones de archivos, así como sus ubicaciones. Si
es completo incluye también información acerca de qué programas utilizan qué
datos, y qué usuarios están interesados en unos u otros informes. Por lo
general, el diccionario de datos está integrado en el sistema de información que describe.
HERRAMIENTAS CASE
INTRODUCCIÓN
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.
No hay comentarios.:
Publicar un comentario