UNIDAD III. Modelado de Anlisis.

En el mbito tcnico, la ingeniera de software comienza con una serie de tareas de modelado que conducen a
una especificacin de requisitos y a una representacin completa del diseo del software que se construir. El
modelo de anlisis, que en realidad es una serie de modelos, es la primera representacin tcnica de un
sistema.
Por medio del modelado del anlisis el ingeniero de software se centra primero en el qu, no el cmo. Que
objetos manipula el sistema?, qu funciones debe desempear el sistema?,qu comportamientos muestra el
sistema?, qu interfaces se definen?y que reestricciones se aplican?
El modelo de anlisis debe cumplir tres objetivos primarios:

Describir lo que requiere el cliente.

Establecer una base para la creacin de un diseo de software.
Definir un conjunto de requisitos que puedan validarse una vez construido el software.
Los problemas dignos de atacar demuestran su valor devolviendo un golpe
Piet Hein

Enfoque de Modelado del Anlisis

1. Anlisis Estructurado
Una visin del modelado del anlisis, llamado anlisis estructurado, considera que los datos y el proceso que
transforman los datos son entidades separadas.

Los objetos de datos se modelan en una forma que define sus atributos y relaciones.
Los procesos que manipulan los objetos de los datos, se modelan de tal manera que muestran como
tranforman los datos, mientras los objetos fluyen por el sistema.

2. Anlisis Orientado a Objetos.

Un segundo enfoque del modelado del anlisis, llamado anlisis orientado a objetos, se centra en la
definicion de clases y en la manera en que stas colaboran entre ellas para efectuar los requisitos del
cliente.
Elementos del modelo de Anlisis.

3.1 Arquitectura de clases.

El modelo de anlisis comienza a menudo con el modelador de datos. El ingeniero o analista de software define
todos los objetos de datos que se procesam dentro del sistema y las relaciones entre los objetos de datos que
se procesan dentro del sistema y las relaciones entre los objetos de datos, ademas de otra informacion
pertinente para las relaciones.
Objetos de Datos.
Un objeto de datos es una representacin de casi cualquier informacin compuesta que el software debe
entender. Informacin compuesta se refiere a algo que tiene muchas propiedades o atributos diferentes.
Por lo tanto anchura (un valor individual) no sera un objeto de datos vlido, pero las dimensiones (la
incorporacin de altura, anchura y profundidad) podran definirse como un objeto.
Un objeto de datos puede ser:
Una entidad externa (por ejemplo cualquier cosa que produzca o consuma informacin),
Una cosa (por ejemplo, un reporte o un despliegue),
Un suceso (como una llamada telefnica) o un evento (como una alarma),
Un papel (por ejemplo un vendedor),
Una unidad organizacional (como un departamento de contadura),
Un lugar (como un almacn), o
Una estructura (como un archivo).
Por ejemplo una persona o un auto pueden verse como un objeto de datos en el sentido de que cualquiera de
ellos puede definirse en trminos de un conjunto de atributos. La descripcin del objeto de datos incorpora el
objeto y todos sus atributos.
Un objeto de datos encapsula slo datos: no existe alguna referencia dentro de un objeto de datos a las
operaciones acten sobre los datos. Por lo tanto un objeto de datos se puede representar mediante una tabla,
tal como se muestra en la siguiente figura.

En este caso un auto se define en trminos de marca, modelo, nmero de serie, tipo de carrocera, color y
propietario.
Atributos
Los aributos definen las propiedades de un objeto de datos y toman una de las caractersticas diferentes. Se
pueden utilizar para:
1. nombrar una ocurrencia del objeto de datos.
2. Describir la ocurrencia o

3. Hacer referencia a otra ocurrencia en otra tabla.

Ademas se debe definir uno o ms atributos como un identificador; es decir, el atributo identificador se convierte
en una clave cuando se desea encontrar una ocurrencia del objeto de datos.
Relaciones
Los objetos de datos estn conectados entre s de muchas maneras diferentes. Por ejemplo, dos objetos,
personas y auto, pueden representarse con la simple notacin ilustrada en la siguiente figura:

Se establece una conexin entre persona y auto porque los objetos se relacionan entre s. Pero, cules son
las relaciones? La respuesta se determina entendiendo el papel de las personas (propietarios, en este caso) y
de los autos dentro del contexto del software que se construir. Se puede definir un conjunto de parejas
objeto/relacin que definan las relaciones relevantes.
Por ejemplo:
Una persona posee un auto
Una persona est asegurada para conducir un auto.
Las relaciones descritas anteriormente definen las conexiones relevantes entre persona y auto.
Carinalidad.
Los elementos del modelado de datos -objetos de datos, atributos y relaciones- ofrecen la base para entender
el dominio de informacin de un problema. Sin embargo, tambin es necesario comprender informacin
adicional relacionada con estos elementos bsicos.
Cardinalidad es la especificacin del numero de ocurrencias de un [objeto] que puede relacionarse con el
nmero de ocurrencias de otro [objeto].
Por ejemplo:

un objeto puede relacionarse con otro objeto (una relacion 1:1)

un objeto puede relacionarse con muchos objetos (una relacin 1:N)
un numero de ocurrencias de un objeto puede relacionarse con algn otro numero de ocurrencias de
otro objeto (una relacin M:N)

La cardinalidad tambin define el numero mximo de objetos de objetos que puede participar en la relacin.

3.2 Identificacin de clases segn estereotipos

al observar el interior de una habitacin se ver que existe un conjunto de objetos fsicos que pueden
identificarse, clasificarse y definirse con facilidad (en trminos de atributos y operaciones). Pero cuando se
observa el espacio del problema de una aplicacin de software, quiz las clases (y los objetos) sean ms
difciles de comprender.
Las clases se manifiestan en una de las siguientes formas:

Entidades externas (por ejemplo, otros sistemas, dispositivos, personas) que producen o consumen
informacin que usar un sistema basado en computadora.
Cosas (por ejemplo reportes, despliegues, letras seales) que son parte del dominio de la informacin
para el problema.
Sucesos o eventos (por ejemplo, una transferencia de propiedad o la consecucin de una serie de
movimientos de robot) que ocurren dentro del contexto de la operacin del sistema.
Papeles (por ejemplo, gerente, ingeniero, personal de ventas) que desempean personas que
interactan con el sistema.
Unidades organizacionales (por ejemplo, divisin, grupo, equipo) relevantes para alguna aplicacin.
Sitios (por ejemplo, el piso de manufactura o el puerto de carga) que establecen el contexto del
problema y la funcin global de sistema.
Estructuras (por ejemplo, sensores), vehculos de cuatro ruedas o computadoras que definen una clase
de objetos.

Para ilustrar la forma en que las clases de anlisis pueden definirse durante las primeras etapas del modelado,
se utiliza el ejemplo de Funcin de seguridad Hogar Seguro.
Clase potencial
Propietario
sensor
panel de control
instalacion
sistema (alias sistema de seguridad)
numero,tipo
contrasea maestra
numero telefonico
evento del sensor
alarma audible
servicio de monitoreo

Clasificacin General
Papel o entidad externa
entidad externa
entidad externa
ocurrencia
cosa
no objetos, atributos del sensor
cosa
cosa
ocurrencia
entidad externa
unidad organizacional o entidad externa

Coad y Yourdon sugieren seis caractersticas de seleccin que se deben usar cuando un analista considera
cada clase potencial pra incluirlas en el modelo de anlisis:

1. informacin referida. La clase potencial ser til durante el anlisis slo si la informacin acerca de ella
debe recordarse para que el sistema pueda funcionar.

2. Servicios requeridos. La clase potencial debe tener un conjunto de operaciones identificables que
puedan cambiar el valor de sus atributos de alguna manera.

3. Atributos mltiples. Durante el anlisis de requisitos el enfoque debe estar en la informacin

4.
5.

importante; una clase con un solo atributo puede, de hecho, ser til durante el diseo, pero
probablemente es mejor representarla como un atributo de otra clase durante la actividad de anlisis.
Atributos comunes. Es posible describir un conjunto de atributos para la clase potencial, y estos
atributos pueden aplicarse en todas las instancias de la clase.
Operaciones comunes. Esposible definir un conjunto de operaciones para la clase potencial, y estas
operaciones pueden aaplicarse a todas las instancias de la clase.

6. Requisitos esenciales, las entidades externas aparecen en el espacio del problema, y que producen o
consumen informacin esencial para la operacin de cualquier solucin para el sistema.
Ejemplo:
Clase potencial
Propietario
sensor
panel de control
instalacion
sistema (alias sistema de seguridad)
numero,tipo
contrasea maestra
numero telefonico
evento del sensor
alarma audible
servicio de monitoreo

Clasificacin General
Rechazada; 1 y 2 fallan aunque aplica 6
aceptada:todas aplican
aceptada:todas aplican
rechazada
aceptada:todas aplican
rechazada:falla 3, atributos del sensor
rechazada: falla 3
rechazada: falla 3
aceptada:todas aplican
aceptada: aplican 2,3,4,5,6
Rechazada; 1 y 2 fallan aunque aplica 6

Se debe sealar que:

1. la lista anterior no est completa.
2. Algunas de las clases potenciales rechazadas se convertiran en atributos de sistema
3. la existencia de enunciados diferentes del problema podria ocasionar decisiones distintas de
aceptacin o rechazo (por ejemplo si cada propietario tuviera una contrasea diferente o si se
pudieran identificar por su voz, la clase propietario satisfacera las caractersticas 1 y 2).
Especificacin de atributos
Los atributos describen una clase que ha sido seleccionada para incluirla en el modelo de anlisis. En
esencia los atributos son los que definen la clase, lo cual clarifica que significa la clase en el contesto del
espacio del problema.
Definicion de operaciones
las operaciones definen el comportamiento de un objeto. Aunque existen muchos tipos distintos de operaciones,
estas se pueden dividir , por lo general, en tres grandes categoras:
1. operaciones que manipulan los datos de alguna manera(por ejemplo: agregar,borrar, reformatear,
seleccionar)
2. operaciones que realizan un computo.
3. Operaciones que preguntan a cerca del estado de un objeto.
4. Operaciones que monitorean un objeto para la ocurrencia de un evento de control.

3.3 Clases.
Un diagrama de clase es similar a un diagrama E-R. Ms adelante en este apartado se mostrarn algunas
caractersticas de los diagramas de clase y cmo se corresponden con los diagramas E-R.

CASOS DE USO
Una tcnica excelente que permite mejorar la compresin de los requerimientos es la creacin de casos
de uso, es decir descripciones narrativas de los procesos del dominio.
Los casos de uso requieren tener al menos un conocimiento parcial de los requerimientos del sistema,
en teora expresados en el documento donde se especifican.
El caso de uso es un documento narrativo que describe la secuencia de eventos de un actor (agente
externo) que utiliza un sistema para completar un proceso. Los casos de uso son historias o casos de utilizacin
de un sistema; no son exactemente los requerimiento o las especificaciones funcionales, sino que ejemplifican
e incluyen tcitamente los requerimientos en las historias que narran.

Comprar productos
Figura. Icono del Lenguaje UML para un caso de uso.
Casos de uso primarios, secundarios y opcionales

Casos primarios de uso, representan los procesos comunes ms importantes, como comprar
productos.
Casos secundarios de uso, representan procesos menores o raros; por ejemplo, solicitud de surtir el
nuevo producto.
Casos opcionales de uso, representan procesos que pueden no abordarse.

Ejemplo de un caso de uso de alto nivel: Comprar productos

El siguiente caso de uso de alto nivel describe clara y concisamente el proceso de comprar artculos en una
tienda cuando se emplea una terminal en el punto de venta.
Caso de uso:

Comprar productos

Actores:

Cliente, cajero

Tipo:

Primario

Descripcin:

Un cliente llega a la caja registradora con los artculos que comprar. El cajero
registra los articulos y cobra el importe. Al terminar la operacin, el cliente se
marcha con los productos.

Ejemplo de un caso expandido de uso: Comprar productos con efectivo.

Nota: un acso de expandido de uso muestra mas detalles que uno de alto nivel; este tipo de casos sueles ser
tiles para alcanzar un conocimiento mas profundo de los procesos y requerimientos. A menudo se llevan a
cabo en un estilo coloquial entre los actores y el sistema.

Caso de uso:

Comprar productos

Actores:

Cliente (iniciador), cajero

Propsito

capturar una venta y su pago en efectivo

Resumen
Tipo:

Un cliente llega a la caja registradora con los artculos que desea comprar. El
cajero registra los articulos y recibe un pago en efectivo. Al terminar la operacin,
el cliente se marcha con los productos comprados.

Descripcin:

Primario y esencial

Curso normal de los eventos

Accin del actor

Respuesta del sistema

1. Este caso de uso comienza cuando un cliente llega

a una caja de TPDV (Terminal de punto de venta) con
productos que desea comprar
2. El cajero registra el identificador de cada producto. 3. Determina el precio del producto e incorpora a la
Si hay varios productos de una misma categora, el transaccin actual la informacin correspondiente.
Cajero tambin puede introducir la cantidad.
Se presentan la descripcon y el precio del producto
actual.
4. Al terminar de introducir el producto, el Cajero indica 5. Calcula y presenta el total de la venta.
a TPDV que se concluy la captura del producto.
6. El cajero le indica el total al cliente.
7. El cliente efecta un pago en efectivo -el efectivo
ofrecido- posiblemente mayor que el total de la venta.
8. El cajero registra la cantidad de efectivo recibida.

9. Muestra al cliente la diferencia. Genera un recibo.

10. El cajero deposita el efectivo recibido y extrae el 11. Registra la venta concluida.
cambio y recibo impreso.
12. El cliente se marcha con los artculos comprados.
Cursos alternos
Linea 2: introduccin de identificador invlido. Indica error.
Lnea 7: el cliente no tena suficiente dinero. Cancelar la transaccin de venta.

Actores
El actor es una entidad externa del sistema que de alguna manera participa en la historia del caso de
uso. Por lo regular estimula el sistema con eventos de entrada o recibe algo de l. Los actores estn
representados por el papel que desempean en el caso: Cliente, Cajero u otro. Conviene escribir el nombre con
mayscula en la narrativa del caso para facilitar la identificacin.

Cliente
Figura: Icono del lenguaje UML que representa un actor de casos de uso.
En un caso de uso hay un actor iniciador que produce la estimulacin inicial y, posiblemente, otros actores
participantes; tal vez convenga indicar quin es el iniciador.
Los actores suelen ser los papeles representados por seres humanos, pero pueden ser cualquier tipo de
sistema, como un computarizado externo de bancos, por ejemplo:

papeles que desempean las personas

sistemas de cmputo
aparatos elctricos o mecnicos

Identificacin de los casos de uso

Existen dos mtodos o estrategias que se pueden utilizar para identificar los casos de uso.
El primero se basa en los actores
1. se identifican los actores lecaionados con un sistema o empresa
2. en cada actor, se identifican los procesos que inician o en que participan.
El segundo mtodo de identificacin se basa en los eventos
1. se identifican los eventos externos a los que un sistema ha de responder.
2. Se relacionan los eventos con los actores y con los casos de uso.
En la aplicacin del punto de venta, algunos actores posiblemente relevantes y los procesos que inician son:

Cajero

Registra
Entrega efectivo

Cliente

Compra productos
Paga los productos

Diagramas de los casos de uso

Un diagrama de casos de uso explica grficamente un conjunto de casos de uso de un sistema, los actores y
la relacin entre stos y los casos de uso. Estos ltimos se muestran en valos y los actores son figuras
estilizadas. Hay lneas de comunicacin entre los casos y los actores; las flechas indican el flujo de la
informacin o el estmulo.

3.4 Diagrama de secuencias

El diagrama de la secuencia de un sistema muestra grficamente los eventos que fluyen de los actores al
sistema. La creacin de los diagramas de la secuencia de un sistema forma parte de la investigacin para
conocer el sistema, y este se incluye dentro del modelo de anlisis. Su creacin depende de la formulacin
previa de los casos de uso.
Los casos de uso indican cmo los actores interactan con el sistema de software que es lo que en realidad
deseamos crear. Durante la interaccin un actor genera eventos dirigidos a un sistema, solicitando alguna
operacin a cambio. Por ejemplo, cuando un cajero introduce un cdigo universal de producto de un artculo,
est pidiendo al sistema TPDV registrar la compra. Con el evento de esa peticin se inicia una operacin del
sistema.
El UML incluye entre su notacin los diagramas de la secuencia que dan una descripcin grfica de las
interacciones del actor y de las operaciones que da origen.
El diagrama de la secuencia de un sistema es una representacin que muestra, en determinado escenario de
un caso de uso, los eventos generados por actores externos , su orden y los eventos internos del sistema.
Ejemplo de un diagrama de la secuencia de un sistema.
En el diagrama el tiempo avanza hacia abajo, y el ordenamiento de los eventos debera seguir el orden indicado
en el caso de uso.
Los eventos del sistema pueden incluir parmetros.
El ejemplo adjunto se refiere al curso normal de los eventos en el caso comprar productos. Indica que el cjero
ees el nico actor en el sistema TPDV y que genera los eventos del sistema introducirProducto, terminar venta
y efectuarPago.

Diagrama de la secuencia del siste,a para el caso de uso Comprar productos

El evento de un sistema es un hecho externo de entrada que un actor produce en un sistema. El evento da
origen a una operacin de respuesta. La operacin de un sistema es una accin que este ejecuta en repuesta
a un evento del sistema.
Por ejemplo cuando el cajero genera el evento introducirProducto, causa la ejecucin de la operacin
introducirProducto; el nombre del evento y de la operacin son idnticos; la distincin reside en que el evento es
el estmulo nombrado y la operacin es la respuesta.
Como elaborar un diagrama de la secuencia de un sistema.
Para elaborar diagramas de la secuencia de un sistema que describan el curso normal de los eventos en un
caso de uso:
1. Trace una lnea que represente el sistema como una caja negra.
2. Identifique los actores que operan directamente sobre el sistema. Trace una lnea para cada uno de
ellos.
3. A partir del curso normal de los eventos del caso de uso identifique loso eventos (externos) del sistema
que son generador por los actores. Muestrelos grficamente en el diagrama.
4. A la izquierda del diagrama puede incluir o no el texto del caso de uso.

3.5 Diccionario de clases segun mdulos

El glosario o diccionario modelo incluye y define todos los trminos que requieren explicacin para mejorar la
comunicacin y aminorar el riesgo de malos entendidos.
El glosario se crea originalmente durante la fase de planeacin y elaboracin confome vayan generndose los
trminos. El glosario es un documento muy til donde se registran las reglas del dominio de la empresa, las
reestricciones y otros puntos.
Ejemplo de glosario aplicado al sistema del punto de venta.
Clase

Comentarios

Atributos

Producto

Un producto para venderse en una Clave,

tienda.
precio,existencia

Veenta

Es una transaccion de ventas

descripcin,

Fecha, cantidad, producto,total

Clase: Producto
clave

Es la clave que identifica de manera nica a cada producto, pudien ser

est el cdigo de barras.

Descripcin

Contiene una breve descripcin del producto.

Precio

Es el precio actual del producto

existencia

Es la cantidad existente del producto.