INGENIERA DE SOFTWARE

Unidad 2 - Modelo de Anlisis

3.1. Arquitectura de clases

3.2. Identificacin de clases segn Estereotipos.
3.3. Clases
3.4. Diagramas de secuencias
3.5. Diccionario de clases segn Mdulos
3.6. Herramientas CASE para el anlisis

Alejandro Castaos Lpez

INDICE
Arquitectura de clases........................................................................................ 2
Identificacin de Clases segn Estereotipos....................................................... 3
Diagrama de Secuencias..................................................................................... 4
Diccionario de clases segn Mdulos.................................................................. 5
Herramientas CASE para el anlisis.................................................................... 6
Conclusiones....................................................................................................... 7
Referencias......................................................................................................... 8

Modelo de Anlisis.

Arquitectura de clases.
El objetivo del modelo de analisis es crear una arquitectura de objetos que sirva como base
para el diseo del sistema.
Dependiendo del tipo de aplicacin existen varias arquitecturas. Ellas se distinguen segn la
organizacin de los objetos de acuerdo a su funcionalidad. Esto es llamado dimension de
arquitectura.
Dimensin de la arquitectura

externa.

Unidimensional: un solo grupo de objetos para manejar la funcionalidad y la interaccin

Bidimensional: un grupo de objetos para manejar la funcionalidad y otros para las

interacciones externas.

Tridimensional: La ms usada en los sistemas de informacin que siendo el ModeloVista-Control.

Arquitectura Modelo-Vista-Control
Es un patrn de arquitectura de software que separa los datos de una aplicacin, la interfaz
del usuario y la lgica de negocio en tres componentes distintos. El modelo es el sistema de
gestin de base de datos y la lgica de negocio y el controlador es el responsable de recibir los
eventos de entrada desde la vista.
Modelo --> informacin
Vista --> presentacin con el usuario
Control --> comportamiento

Identificacin de Clases segn Estereotipos.

Para llevar a cabo la transicin del modelo de requisitos al modelo de anlisis 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 ms 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 ms difciles de administrar, ya que sta puede abarcar
todos los tipos de objetos.
Bordes
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 borde, pues a travs de
ellos se comunican los actores con el sistema. La tarea de una clase borde es traducir los eventos
generados por un actor en eventos comprendidos por el sistema, y traducir los eventos del sistema
en una presentacin comprensible para el actor.
Las clases borde en otras palabras, describen la comunicacin bidireccional entre el sistema
y los actores.
Las clases borde son bastante fciles de identificar, donde se cuenta con al menos tres
estrategias:
1.

Se pueden identificar con base a los actores.

2.
Se pueden identificar con base en las descripciones de las interfaces del sistema que
acompaan al modelo de requisitos.
3.
Se pueden identificar con base en las descripciones de los casos de uso y extraer la
funcionalidad especfica a los objetos bordes.
Entidad
Se utilizan objetos entidad para modelar la informacin que el sistema debe manejar a corto
y largo plazo. La informacin a corto plazo existe durante la ejecucin de un caso de uso, mientras
que la informacin a largo plazo trasciende los caso de uso, por lo que es necesario guardarla en
alguna base de datos o archivos.
Durante la identificacin de objeto entidad, se encontrara que objetos que objetos similares
aparecen en varios casos de uso.
Control
En la mayora 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 solucin no es buena si se considera el
aspecto de extensibilidad. Un cambio en el comportamiento podra afectar varios objetos,
dificultando su modificacin. Para evitar estos problemas, tal comportamiento se asigna a objetos
control.
Es difcil lograr un buen balance en la distribucin del comportamiento del caso de uso entre
los objetos entidad, borde y control. Los objetos de control normalmente proveen a administracin
de los dems tipos de objetos.

Diagrama de Secuencias.
Un diagrama de secuencia muestra:
Interaccin de un conjunto de objetos en una aplicacin a travs del tiempo.
Un conjunto de mensajes, dispuestos en una secuencia temporal.
Cada rol en la secuencia como una lnea de vida, es decir: una lnea vertical.
Un diagrama de secuencia representa una interaccin como un grfico bidimensional.
La dimensin vertical: es el eje del tiempo
La dimensin horizontal muestra los roles de clasificador que representan objetos
individuales en la colaboracin
Un rol de clasificador:
Es la descripcin de un objeto que desempea un determinado papel dentro de una
interaccin, distinto de los otros objetos de la misma clase.
La primera utilizacin de los diagramas de secuencia corresponde a la documentacin de los
casos de uso, se concentra en la descripcin de la interaccin,
La segunda utilizacin corresponde a un uso ms informtico y permite la representacin
precisa de las interacciones entre objetos.
Por lo tanto puede mostrar:
Escenario como la historia individual de la transaccin que detalla los casos de uso,
aclarndolos al nivel de mensajes de los objetos existentes, como tambin
El uso de los mensajes de las clases diseadas en el contexto de una operacin.
Cuando est implementado el comportamiento,
Cada mensaje en un diagrama de secuencia
Corresponde a:
Una operacin en una clase,
A un evento disparador, o
A una transicin en una mquina de estados.

Diccionario de clases segn Mdulos.

Los diccionarios de datos son el segundo componente del anlisis del flujo de datos. En s
mismos los diagramas de flujo de datos no describen por completo el objeto de la investigacin. El

diccionario de datos proporciona informacin adicional sobre el sistema. Esta seccin analiza que
es un diccionario de datos, por qu se necesita en el anlisis 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 cuntos 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 anlisis de flujo de datos y ayuda el analista
involucrado en la determinacin de los requerimientos de sistemas. Sin embargo, como se ver
ms adelante, tambin el contenido del diccionario de datos se utiliza durante el diseo del
sistema.
En informtica, base de datos acerca de la terminologa que se utilizar en un sistema de
informacin. 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 dems objetos
(archivos, programas, informes, sinnimos...) 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 tambin informacin acerca de qu programas utilizan qu
datos, y qu usuarios estn interesados en unos u otros informes. Por lo general, el diccionario de
datos est integrado en el sistema de informacin que describe.

Herramientas CASE para el anlisis.

Introduccin.
De acuerdo con Kendall el desarrollo de sistema es asistida por ordenadores es la aplicacin
de informtica, 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, tambin suelen incluir.

Un diccionario para los datos de la aplicacin de base de datos.

Herramientas de diseo para dar apoyo al anlisis de datos.

Herramientas para desarrollar el modelo de datos corporativo, los esquemas

conceptual y lgico.

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 dcada de los setenta el proyecto ISDOS desarrollo un lenguaje llamado "Problem
Statement Language" (PSL) para la solucin de un problema informtico 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.
Tecnologa.
La tecnologa CASE es la automatizacin del desarrollo software para mejorar la calidad del
sistema de informacin.

Permitir aplicaciones prcticas de metodologas estructuradas, al ser realizadas con

una herramienta consigue agilizar el trabajo.

Facilitar la realizacin de prototipos y desarrollo conjunto de aplicaciones.

Simplificar el mantenimiento de los programas.

Mejorar y estandarizar la documentacin

Aumentar la portabilidad de las aplicaciones.

Facilitar la reutilizacin de componentes software.

Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la

utilizacin de grficos.

Conclusiones.
Hemos examinado los dos significados diferentes de los modelos de anlisis que podemos
encontrar entre los ingenieros software: un modelo que especifica la vista externa del sistema
software, o bien un modelo descriptivo del mundo real que constituye el contexto del sistema
software deseado. Es bastante frecuente confundir estas dos concepciones. La prctica real
corresponde habitualmente al uso del modelo especificativo del sistema, aun cuando las
explicaciones tericas apuntan con frecuencia hacia el modelo descriptivo del entorno. Un peligro

moderado de la confusin es pensar que estamos modelando el mundo real, cuando en realidad
estamos elaborando una especificacin de alto nivel del sistema software. Un peligro mucho ms
serio es construir un sistema que imite sin necesidad la estructura del mundo real.
En cambio, sera legtimo concebir la tarea de anlisis como aqulla en la que se construyen
ambos modelos, estrechamente relacionados y a la vez adecuadamente distinguidos. Si tiene que
utilizar la palabra anlisis en el contexto de la ingeniera del software, escoja el sentido que
prefiera, pero sea consciente de su eleccin y de los posibles malentendidos con su audiencia.
Confiamos en que el despliegue del binomio anlisis-diseo en el espacio tridimensional de
modelado que hemos presentado contribuya a deshacer los frecuentes malentendidos que
obstaculizan el uso de los modelos en la ingeniera del software, y sea til para definir mejor la
transformacin de modelos como un desplazamiento en este espacio.

Referencias.
Ingeniera de Software orientada a objetos con UML, JAVA e Internet. Alfredo Witzenfeld.
Ingeniera de Software. Somerville.
www.wikipedia.com
www.monografas.com
www.google.com
8