Analisis Orientado A O

Tema 5
Anlisis Orientado a Objetos
El proceso de desarrollo de software

Detalle del proceso de desarrollo de software
Documentos de anlisis
Especificacin de requisitos o requerimientos
Diagramas de casos de uso
Escenarios y sub-escenarios
Prototipos
Otras tcnicas de anlisis orientado a objetos
Resumen
Juan Manuel Cueva Lovelle
5-1

[Booch 94, captulo 6]
No hay recetas mgicas, aunque es necesario tener un

proceso preceptivo.
Las caractersticas fundamentales de un proyecto con
xito
Buena visin arquitectnica
No existe ningn camino bien definido para idear una
arquitectura. Tan slo se pueden definir los atributos de una
buena arquitectura:
Capas de abstraccin bien definidas

Clara separacin de intereses entre interfaz e implementacin
Arquitectura simple
Es necesario distinguir entre decisiones estratgicas y tcticas

Decisiones estratgicas es aquella que tiene amplias
implicaciones estratgicas e involucra as a la organizacin de
las estructuras de la arquitectura al nivel ms alto
Decisiones tcticas son las que slo tienen implicaciones
arquitectnicas locales, es decir slo involucran a los detalles
de interfaz e implementacin de una clase
Ciclo de vida incremental e iterativo

Los ciclos de desarrollo no deben ser anrquicos ni
excesivamente rgidos
Cada pasada por un ciclo anlisis/diseo/evolucin lleva a
refinar gradualmente las decisiones estratgicas y tcticas,
convergiendo en ltima instancia hacia una solucin con los
requisitos reales de los usuarios finales (habitualmente no
expresados explcitamente por stos)
5-2

Modelo en cascada
Requisitos
Anlisis
Diseo preliminar y detallado
Implementacin & prueba unitaria
Integracin
Mantenimiento
5-3

Modelo en espiral [Jacobson 92]
Esfuerzo
Prueba
Diseo
Implementacin
Anlisis
Tiempo
5-4
Detalle de un proceso de desarrollo de software

Aunque el proceso es iterativo el orden de los pasos fundamentales es el siguiente:
Anlisis
Caractersticas comunes de los documentos.
Identificacin. Ttulo, descripcin, versin, fecha, revisin, cdigo del documento..
Prototipos
Diseo (preliminar y detallado)
Modelado de Clases, Objetos y mecanismos de colaboracin
Diagramas de interaccin
Las decisiones iniciales de implementacin se toman a partir de los diagramas

de componentes y de despliegue
Se implementan las clases de un componente a partir de los diagramas de
clases y diagramas de objetos
A partir de los diagramas de actividades y de los diagramas de estados se
implementa el comportamiento de los mtodos de cada clase
Prueba
Diagramas de componentes
Diagramas de despliegue
Implementacin
Diagramas de actividades
Diagramas de estados
Construccin del modelo fsico
Diagramas de Clases y consulta de patrones de diseo.

Diagramas de objetos
Modelado del comportamiento de clases y objetos
Diagramas de secuencia
Diagramas de colaboracin
Prueba unitaria de cada clase

Prueba de mdulos
Prueba de integracin se realiza siguiendo los escenarios, diagramas de
interaccin., actividades y estados
Mantenimiento
Informes de errores
Nueva especificacin de requisitos. Nueva versin
5-5

Anlisis orientado a objetos (AOO)
[Booch 94]
es un mtodo de anlisis que examina los
requisitos desde la perspectiva de las clases y
objetos que se encuentran en el vocabulario del
dominio del problema
Documentos bsicos de anlisis orientado a

objetos
Escenarios y subescenarios
Prototipos y su evaluacin
Todos los documentos deben estar

identificados y codificados
5-6
Identificacin
Es necesario identificar todos los
elementos del proceso de desarrollo de
software de una forma unvoca
Todos los documentos deben estar
identificados
Ttulo
debe reflejar de la mejor forma posible sus fines
y su funcionalidad
Descripcin
Autores
Versin. Notacin decimal.
Revisin. Autores
Fecha
Cdigo de cada documento o diagrama
5-7
Contiene la documentacin que aporta el

cliente que encarga la aplicacin
Tambin contiene las actas de las
reuniones de trabajo del grupo de anlisis
Es necesario un secretario que tome acta
Es necesario aprobar el acta de cada reunin por
todos los miembros
5-8
Ejemplo de documento de anlisis

Se debe realizar un sistema capaz de mantener una base de datos con todos los equipos
hardware y software de una empresa, de manera que se pueda obtener informacin acerca del
nmero de licencias instaladas y de los equipos en los que estn instaladas dichas licencias.
Adems debe ser posible controlar el hardware, las modificaciones efectuadas en los
equipos, las averas de dichos equipos, la composicin de cada uno de los ordenadores y el
software que est instalado en ellos.
Por otro lado cada equipo y cada software que posee la empresa tiene asociados una serie
de manuales de los que es necesario seguir la pista, pudiendo, en cada momento, saber qu
manuales tiene cada equipo y tambin cada programa.
Por tanto existen tres elementos importantes implicados en el sistema:
1.El software.
2.El hardware.
3.Los manuales.
Es necesario seguirles la pista a estos tres elementos y saber en todo momento las
relaciones entre ellos para poder localizar, mediante el ordenador el manual de un componente
instalado en un ordenador.
Para el Software es necesario saber el nombre del producto, la versin, la marca o casa que
lo fabrica, la fecha de compra, el precio de compra, el proveedor, el soporte (disquetes, CD-ROM,
etc.), el nmero de elementos del soporte, la localizacin fsica del soporte, el nmero de
instalaciones, los equipos en los que est instalado, el nmero de licencias adquiridas, los manuales
que acompaan el producto y la localizacin fsica de dichos manuales.
Las localizaciones fsicas pueden ser sustituidas por los cdigos si se codifican tanto los
soportes fsicos como los manuales.
El sistema debe ser capaz de contestar a las preguntas:
1.Licencias existentes, en uso y necesarias (si procede) de cada una de las
aplicaciones que se estn usando en la empresa.
2.Ordenador u ordenadores (si hay varios) en que reside una aplicacin.
3.Composicin del paquete original (disquetes, CD-ROM, etc. y manuales).
4.Proveedor que sirvi el programa, fecha y precio de adquisicin.
Un detalle importante a tener en cuenta es que existe la posibilidad de que exista software
llave-en-mano, y en este caso adems hay que saber si se dispone o no de los cdigos fuente, la
casa que lo desarroll, quin posee los derechos de copia, el precio, el tiempo de desarrollo y el
nombre de la persona responsable del proyecto.
Los software se quedan obsoletos y, por tanto, es necesario actualizarlos. Se debe tener en
cuenta que es necesario que el sistema ofrezca una resea histrica del producto (versiones
anteriores) y por tanto es necesario saber el estado de cada uno de ellos (activo, actualizado,
desechado, en preparacin, pedido, etc.)
En el caso de los antivirus y otros programas similares, es necesario obtener regularmente
una adaptacin, por lo que es importante que el sistema nos avise de la inminencia de la caducidad
de dichos sistemas.
5-9
Ejemplo de Documento de Anlisis (continuacin ...)
De cada ordenador se necesita saber su composicin (monitor, teclado, ratn y

unidad central). De esta ltima es necesario saber su composicin (VGA, disco duro,
disquete, placa madre, procesador(es), memoria RAM, memoria cach, etc.).
Cada uno de los cuatro componentes principales estar codificado adecuadamente
para permitir el intercambio de dichos equipos entre los diferentes puestos de ordenador, de
manera que la asociacin no sea fija. De ellos es necesario saber (cuando exista) la marca,
el modelo, el nmero de serie, y otras caractersticas particulares (por ejemplo, del monitor
la resolucin, si es o no Energy, etc.)
Adems de ordenadores existen otros equipos: impresoras, plotters, scaners y
unidades de almacenamiento (ZIP, CD y Magneto-pticos) de los cuales es necesario saber,
al menos, la marca, el modelo, el nmero de serie y una breve descripcin de sus
caractersticas.
De cada uno de los equipos es necesario tener un resea histrica de sus averas y
cambios, as como una estimacin de su precio (en funcin del precio de compra de cada
uno de sus componentes).
En el caso de los ordenadores es necesario saber el software que tienen instalado
(comenzando por el sistema operativo) y debe ser posible seguir la pista de los manuales de
cada una de sus partes componentes.
De los manuales slo es necesario controlar su cdigo, su ISBN (si lo posee), su
precio (si es aparte del paquete) y su ttulo. Pero es imprescindible poder obtener
informacin del software y hardware que est relacionado con ellos.
Los manuales deben de ser actualizados segn se vaya cambiando el software y el
hardware .
El programa debe ser capaz de gestionar el sistema desde diferentes puntos de vista:
responsable de informtica, mantenimiento y usuario.
El responsable de informtica es el encargado de comprar todos los componentes
(equipos, software y manuales). Adems da estos equipos de alta y debe poder apoyarse en
el sistema para gestionar los pedidos.
Para esta ltima labor debe poder anotar en el sistema que ha pedido un componente a un
proveedor (por tanto que est pendiente de recibir), confirmando en la recepcin este
pedido, adems tendr la capacidad de poder anular un pedido o si se da el caso anularlo
5-10
Ejemplo de Documento de Anlisis (continuacin ...)
Adems debe poder obtener informes de inventario de los equipos tasados por el
precio de compra menos una amortizacin del 25% anual (que dejara al equipo sin valor
pasados cuatro aos) para los procesadores y del 10% anual para el resto de los equipos.
Adems debe poder obtener informe de la composicin de cada equipo, del estado
de disponibilidad de cada uno de ellos y de el estado con respecto a la garanta del equipo.
El responsable de informtica es la nica persona que puede dar de alta, modificar y
dar de baja los equipos.
La baja de un equipo se dar en el momento en que se avise de la avera y si el
equipo no tiene arreglo lo daremos de baja permanente.
Adems debe poder obtener toda la informacin que tienen el resto de los usuarios
del sistema (responsable de mantenimiento y usuarios), y tendr acceso a un buzn de
sugerencias sobre el sistema.
El responsable de informtica se encarga adems de reservar un equipo cuando se
solicita por cualquier usuario, para ello tiene que obtener los informes de disponibilidad y
composicin de equipos.
El responsable de mantenimiento debe poder anotar en todo momento las averas
de cada equipo (fecha, hora de comienzo, hora de fin, nombre del mecnico y descripcin).
Debe poder anotar que un equipo no tiene reparacin. Adems debe poder obtener informes
acerca del tiempo de inactividad de los equipos y acceso al buzn de sugerencias.
El usuario debe poder obtener informacin de los manuales, software y hardware
asociado y disponibilidad de un equipo en concreto . Tendr acceso al buzn de
sugerencias.
Se debe tener en cuenta que:
* El sistema trabajar en un entorno multiusuario.
* Las bases de datos sern un modelo estndar.
* Cada equipo estar compuesto por un monitor, un teclado, un ratn, y una unidad
central.
*La unidad central estar formada por una serie de componentes que se describirn
de manera textual en un campo al efecto.
5-11
Especificacin de requisitos o
requerimientos
La captura de requisitos es el proceso de averiguar,

normalmente en circunstancias difciles, lo que que se
debe construir [Jacobson 1999, captulo 6]
La captura de requisitos es complicada
Los usuarios habitualmente no saben expresar exactamente
lo que quieren
Es difcil tener una visin global del problema a resolver
La especificacin de requisitos es un documento ms

tcnico y elaborado de los documentos de anlisis
Es importante codificar los requisitos para poder
seguirlos a lo largo del proceso de desarrollo de software
Se puede utilizar una especificacin jerrquica
Estn todos codificados por niveles, al igual que las leyes.
Se desea que en las actas quede reflejado lo ms
exactamente posible el problema a resolver, y que en las
reuniones de anlisis se determine exactamente que
requisitos se aaden o se eliminan
Los requisitos relacionados se organizan dentro de un
mismo nivel
Cada nivel 1 se puede hacer corresponder posteriormente
con un caso de uso
con un escenario
con un sub-escenario
5-12
Ejemplos de requisitos
R.0
Requisitos generales
R.0.1 Tendremos en cuenta trabajar con fechas que codifiquen el ao con cuatro
cifras.
R.0.2 Las unidades monetarias debern poder trabajar con cifras decimales con
vistas al inmediato cambio de moneda que se nos aproxima.
R.1
Gestin de clientes
R.1.0 Requisitos generales de los clientes
R.1.0.1 Los clientes pueden ser fijos o eventuales
R.1.0.2 A los clientes se les asigna un nmero identificativo
R.1.0.3 Los clientes se definen por D.N.I., nombre, direccin, ciudad,
telfono, y departamento.
R.1.1 Aadir clientes
R.1.1.1Solamente los Usuarios con permiso de Administrador podrn aadir
clientes fijos.
R.1.2
Borrado de clientes.
R.1.2.1Solamente los Usuarios con permiso de Administrador podrn borrar
clientes.
R.1.2.2Para poder borrar clientes es necesario que este no tenga ningn
albarn pendiente de facturacin y que estos tengan una antigedad
mayor a cinco aos.
R.1.2.3Tambin es necesario que no tenga ninguna mquina reparndose
R.1.3 Modificar clientes.

R.1.3.1Solo los usuarios con permiso de Administrador pueden modificar los
datos de un cliente.
R.1.4 Buscar clientes.
R.1.5 Paso de cliente fijo a cliente eventual y viceversa.
R.1.5.1Solo los usuarios con permiso de Administrador pueden hacer
clientes fijos.
5-13
Diagramas de Casos de Uso (I)

[Booch 1999, captulo 17] [Jacobson 1999, captulo 3] [Schneider 1998]
Es uno de los cinco tipos de diagramas de UML que

se utilizan para el modelado de los aspectos
dinmicos de un sistema.
Se corresponden inicialmente con requisitos de
primer nivel. Posteriormente se van modelando
requisitos de los siguientes niveles.
Se suelen codificar con el mismo cdigo que el
requisito, para hacer ms patente su correspondencia.
Un caso de uso es una tcnica de modelado utilizada
para describir lo que un nuevo sistema debe hacer o
lo que un sistema existente ya hace.
Los casos de uso representan una vista externa del
sistema
Un modelo de casos de uso se construye mediante un
proceso iterativo durante las reuniones entre los
desarrolladores del sistema y los clientes (y/o los
usuarios finales) conduciendo a una especificacin de
requisitos sobre la que todos coinciden.
Un caso de uso captura algunas de las acciones y
comportamientos del sistema y de los actores
El modelado con casos de uso fue desarrollado por
Ivar Jacobson [Jacobson 1992]
5-14
Diagramas de Casos de Uso (II)
El sistema que se desea modelar se representa encerrado en un rectngulo

Los actores son los que interactan con el sistema. Representan todo lo que necesite
intercambiar con el sistema.
Un actor es una clase
Se diferenciar entre actores y usuarios.
Un usuario es una persona que utiliza el sistema

Un actor representa el papel (rol) que una persona desempea
Por ejemplo una persona puede ser usuario y administrador en un sistema, unas veces actuar
como usuario y otras como administrador, pero deben contemplarse ambos actores.
Los Casos de Uso es un camino especfico para utilizar el sistema

Para cada Caso de Uso, Actor y Sistema se realiza una descripcin detallada
Los Casos de Uso tan slo indican opciones generales
El diagrama de Casos de Uso es un diagrama sencillo que tiene como

finalidad dar una visin global de toda la aplicacin de forma que se
pueda entender de una forma rpida y grfica tanto por usuarios como por
desarrolladores
Caso de uso 1
Caso de uso 2
Caso de uso
Caso de uso 3
Actor 3
Caso de uso 4
Caso de uso 5
Actor 1
Actor
Caso de uso 6
Caso de uso 7
Interaccin
Actor 2
Lmites del sistema

Sistema
5-15
Ejemplo de Casos de Uso
PEDIDOS
INFORMES
AVERIAS
RESERVAS
Responsable
de
mantenimiento
SUGERENCIAS
Responsable
de informtica
INFORME PARA
USUARIO
ACTIVIDAD
Usuario
5-16
Ejemplo de descripcin de los Casos de Uso

1 .P E D I D O S
E s c e n a rio g e n e ra l d o n d e s e re a liz a n to d a s la s o p e ra c io n e s re la tiv a s a
p e d id o s : h a c e r, re c ib ir, a n u la r y d e v o lv e r p e d id o s . T o d o e s re a liz a d o p o r e l
R e s p o n s a b le d e In fo rm tic a .
2 .I N F O R M E S
T o d o s lo s in fo rm e s q u e so n n e c e s a rio s p a ra e l fu n c io n a m ie n to d e la
e m p re s a : in fo rm e d e p e d id o , d e a m o rtiz a c io n e s , d e in a c tiv id a d , d e
c o m p o s ic i n d e e q u ip o s b s ic o s, d e c o m p o s ic i n d e o tro s e q u ip o s , d e
in v e n ta rio s o ftw a re y m a n u a le s, d e g a ra n ta s y d e d is p o n ib ilid a d . E s to s
in fo rm e s s o n re a liz a d o s p a ra e l R e s p o n sa b le d e In fo rm tic a .
3 .A V E R I A S
E n g lo b a to d a s ls o p e ra c io n e s re la tiv a s a la s a v e ra s ta n to e l a v is o
q u e p u e d e s e r re a liz a d o p o r c u a lq u ie r a c to r (R e sp o n s a b le d e In fo rm tic a , d e
M a n te n im ie n to o U s u a rio ) , c o m o e l p a rte d e a v e ra q u e e s re a liz a d o p o r e l
R e s p o n s a b le d e M a n te n im ie n to y e n tre g a d o a l R e s p o n s a b le d e In fo rm tic a .
4 .R E S E R V A S
E s ta n to la p e tic i n d e re s e rv a d e u n e q u ip o c o n u n a s c a ra c te rs tic a s
d e te rm in a d a s, q u e p u e d e s e r re a liz a d a p o r c u a lq u ie r u su a rio a l R e s p o n s a b le
d e In fo rm tic a , c o m o la c o n c e s i n d e u n a re s e rv a q u e re a liz a e ste ltim o a
u n u su a rio .
5 .S U G E R E N C I A S
E s u n a ln e a d e c o m u n ic a c i n e n tre lo s d ife re n te a g e n te s q u e
in te ra c c io n a n c o n e l s is te m a .
6 .I N F O R M E S P A R A E L U S U A R I O
E s u n in fo rm e e s p e c ia lm e n te re a liz a d o p a ra e l u su a rio d o n d e e s te
p u e d e e n c o n tra r to d a la in fo rm a c i n q u e p u e d a n e c e s ita r e n u n m o m e n to
d e te rm in a d o s o b re u n e q u ip o , s u d is p o n ib ilid a d , s o ftw a re o u n m a n u a l.
7 .A C T I V I D A D
R e a liz a d o p o r e l R e s p o n sa b le d e In fo rm tic a e n g lo b a to d o lo
re la tiv o a l b u e n fu n c io n a m ie n to d e l m a te ria l d e la e m p re sa : d a r d e b a ja
te m p o ra lm e n te u n e q u ip o c u a n d o e s ta e n re p a ra c i n , d a r d e b a ja
p e rm a n e n te m e n te u n e q u ip o c u a n d o n o tie n e a rre g lo y a c tu a liz a r ta n to
s o ftw a re c o m o lo s m a n u a le s .
5-17
Ejemplo de Casos de Uso
Sistema Servidor
Bases de Datos
Administrador
Sistema Cliente
Administracin
Gestin albaranes
Gestin de clientes
Gestin mquinas
Gestin proveedores
Dependiente
Gestin pedidos
Gestin almacn
Gestin reparaciones
Gestin taller
Mecnico
Consultas
5-18
Descripcin de actores
Nombre de Actor: Administrador
Definicin: Es el encargado de administrar el sistema. Tendr todos
los permisos y libertad de movimientos por el sistema.
Notas:
El administrador es el encargado de manipular la
informacin contenida en el sistema.
Tiene acceso a toda la informacin del sistema y es el
nico que puede modificar todo lo que le de la gana..
Nombre de Actor: Mecnico
Definicin: Es el encargado de realizar las oportunas reparaciones en
las mquinas y a su criterio y valoracin queda el tomar
las decisiones oportunas respecto a que reparacin y si es
necesario o no el ingreso de la mquina en el taller.
Notas:
No lo encajamos en la figura de una persona concreta
sino que pueden ser varias personas las que puedan
encargarse de esta tarea.
El mecnico solo tiene acceso a la parte del sistema
referente a las mquinas a las reparaciones y al las
consultas, el acceso al resto le est vedado.
Dentro de la parte del sistema al que puede acceder no
se le permite el borrado de informacin, solo, aadir y
modificar.
Nombre de Actor: Dependiente
Definicin: Es la persona que est en contacto directo con los
clientes. Tiene acceso limitado a las operaciones del
sistema.
Notas:
El dependiente no podr dar de alta a clientes fijos,
pero si a clientes eventuales.
No podr borrar clientes, ni mquinas, ni artculos, ni
reparaciones.
No tiene acceso a la gestin de proveedores ni del taller
5-19
Sistemas
SISTEMA SERVIDOR
El Sistema Servidor, (en nuestro caso particular) estar formado por una mquina
Windows NT Server (tambin podra ser una mquina Unix) que ser atacado por sistemas
Clientes constituidos por mquinas Windows 95 Windows NT.
El gestor de la base de datos (CTSQL de MultiBase...), junto a la propia base de
datos, se encuentran en el servidor UNIX o Windows NT ( solo para el CTSQL).
Existir tambin la posibilidad de configurarlo en una sola mquina en Windows 95
Windows NT, en cuyo caso los programas de la aplicacin, el gestor de la base de datos y
la base de datos residiran en la misma mquina Windows.
SISTEMAS CLIENTES
Los programas de la aplicacin residen en la mquina cliente Windows95 o
Windows NT que atacan al servidor donde se encuentra instalada el gestor de la base de
datos junto con la base de datos correspondiente.
INTERFACES
INTERFAZ ADMINISTRADOR
El interfaz del Administrador le permite acceder a todas las opciones que presenta la
aplicacin
INTERFAZ DEPENDIENTE
El Dependiente solamente tendr acceso a algunas de las funciones que soporta la
aplicacin y dentro de estas su capacidad de maniobra estar limitada
INTERFAZ MECNICO
El mecnico tendr acceso solamente a las reparaciones y a la gestin del taller
adems de las consultas.
5-20
Ejemplo de descripcin de casos de uso

Nombre del Caso de Uso 1: Gestin Clientes
Definicin: Actualizaciones de la informacin acerca de los clientes
de Comercial Quirs
Notas:
Los
clientes vienen definidos por: nmero_cliente,
DNI, nombre, direccin, ciudad, telfono y el

departamento para el que trabajan.
En
el caso de que no pertenezca a un departamento
determinado este aparecer en blanco.

Los
clientes pueden ser fijos o eventuales.
Nombre del Caso de Uso 2: Gestin Mquinas

Definicin: Actualizaciones de la informacin acerca de las
mquinas de los clientes de Comercial Quirs, y de las
cuales
nos encargamos
de su
mantenimiento
reparacin.
Notas: Las mquinas vienen definidas por: n identificatorio,
nmero_cliente, tipo, marca y modelo.
Con
nmero_cliente relacionamos la mquina con el
cliente al que pertenece.

Un
mismo cliente puede tener varias mquinas.
El
tipo nos dice a que clase de mquina pertenece
(fotocopiadora, fax...)
5-21
Casos de uso en Rational Rose

Tiene una seccin para ir introduciendo los Casos de Uso (Use Case View)
Permite el manejo de actores, que se traducirn al sistema como clases
Cada sistema recibe un nombre (no aparece el rectngulo) y est ligado a una ventana
5-22
Cada caso de uso da lugar mltiples escenarios

Se codifican siguiendo la codificacin de los casos de uso
Se estudia cada escenario utilizando guiones como los que se usan en el
cine
Cada equipo que pasa por un escenario identifica los objetos y sus
responsabilidades, as como los mecanismos que relacionan los objetos
De los escenarios iniciales se puede pasar a otros escenarios secundarios
Los escenarios tambin se pueden utilizar para probar el sistema en la fase
de pruebas
El estudio de los escenarios con detalle permitir enriquecer el
Diccionario de clases
No es necesario hacer todos los escenarios y sub-escenarios posibles si se
observa que no enriquecen el diccionario de clases
Numeracin: 1.1.
Titulo: Hacer pedido
Precondiciones: Sugerencias de compra, caducidad de licencias, bajas permanente
hardware,
Quien Lo Comienza: Responsable de Informtica.
Quien Lo Finaliza: Responsable de Informtica.
Postcondiciones:
Excepciones:
Descripcin: Son las operaciones de compra de todos los componentes (hardware,
software y manuales) que realiza el responsable de informtica. Adems da estos
equipos de alta y debe apoyarse en el sistema para gestionar los pedidos
correctamente para lo que debe anotar en el sistema que ha pedido un componente a
un proveedor ( por tanto que est pendiente de recibir).
Numeracin: 1.2.
Titulo: Anular pedido
Precondiciones: Cambio de precio, cambio de necesidades de la Empresa.
Quien Lo Comienza: Responsable de Informtica
Quien Lo Finaliza: Responsable de Informtica
Postcondiciones:
Excepciones
Descripcin: Esta operacin la realiza el responsable de informtica cuando toma la
decisin de anular un pedido que haba realizado con anterioridad.
de informtica confirma la recepcin de los pedidos.
5-23
Ejemplo de escenarios
Caso de uso 1: Gestin de Clientes
Nombre de Escenario 1.1: Dar de alta un cliente eventual
Precondiciones: No existe ficha de cliente.
Postcondiciones: Todos los datos se han introducido correctamente.
El numero de clientes se incrementa en uno
Excepciones:
Iniciado por: Dependiente/Administrador.
Finalizado por: Dependiente/Administrador.
Detalle operaciones: Cliente acude a una tienda de la compaa.
Dependiente
( Administrador) obtiene datos de
cliente.
Dependiente
( Administrador) introduce ficha en el
sistema con los datos nmero, dni, nombre, direccin,

ciudad, telfono, y departamento.
Nombre de Escenario 1.2: Dar de alta un cliente fijo.

Precondiciones: No existe ficha de cliente.
Postcondiciones: Todos los datos se han introducido correctamente.
El nmero de clientes se incrementa en 1
Excepciones
Iniciado por: Administrador.
Finalizado por: Administrador.
Detalle operaciones: Cliente acude a una tienda de la compaa.
Administrador obtiene los datos del cliente.
Administrador
introduce ficha en el sistema con los
datos nmero, dni, nombre, direccin, ciudad, telfono,

y departamento.
5-24
Diagramas de Casos de Uso (III)
Un caso de uso es la tpica interaccin entre un usuario y

un sistema informtico
Un actor es el papel que el usuario juega con respecto al
sistema. Un actor no tiene que ser un humano, puede ser
por ejemplo otro sistema externo que pide informacin al
sistema actual
La relacin <<extend>> se utiliza cuando un caso de uso
es similar a otro caso de uso pero se le aade alguna
caracterstica nueva
La relacin << use >> se utiliza cuando se tiene una
parte del comportamiento comn a ms de un caso de
uso, y no se desea almacenar una copia en cada caso de
uso de la descripcin de este comportamiento.
<< use >>
Caso de uso
Actor
<<extend >>
5-25
Prototipos
[Piattini 96]
El prototipado consiste en la elaboracin de un modelo o maqueta del sistema que

se construye para evaluar mejor los requisitos que se desea que cumpla
Es particularmente til cuando:
El rea de la aplicacin no est bien definida, bien por su dificultad o bien por falta de
tradicin en su automatizacin.
El coste del rechazo de la aplicacin por los usuarios, por no cumplir sus expectativas, es
muy alto.
Es necesario evaluar previamente el impacto del sistema en los usuarios y en la organizacin.
Estos modelos o prototipos suelen consistir en versiones reducidas, demos o

conjuntos de pantallas (que no son totalmente operativos) de la aplicacin pedida.
Existen tres razones principales para emplear prototipado, ordenadas por frecuencia
de uso:
Prototipado de la interfaz de usuario para asegurarse de que esta bien diseada, que
satisface las necesidades de quienes deben usarlo. Este tipo de prototipado es bastante
frecuente, no cuesta mucho y puede consistir en simples modelos de pantallas en papel,
simuladas con programas de dibujo o presentacin o autnticas simulaciones muy elaboradas
de la interfaz. No suele resultar ms caro que el trabajo tradicional y es muy efectivo para evitar
los mltiples cambios que suelen solicitar los usuarios en este aspecto.
Modelos de rendimiento para evaluar el posible rendimiento de un diseo tcnico,
especialmente en aplicaciones crticas en este aspecto. Estos modelos tienen un carcter
puramente tcnico y, por lo tanto, no son aplicables al trabajo de anlisis de requisitos.
Prototipado funcional. Cada vez ms utilizado, est relacionado con un ciclo de vida
iterativo. En este caso, en vez de seguir el procedimiento habitual (tirar el prototipo una vez
probado y empezar a desarrollar la aplicacin), el prototipo supone una primera versin del
sistema con funcionalidad limitada. A medida que se comprueba si las funciones
implementadas son las apropiadas, se corrigen, refinan o se aaden otras nuevas hasta llegar
al sistema fina
5-26
Otras tcnicas de anlisis

orientado a objetos
Anlisis OO mediante fichas CRC
(Clases/Responsabilidades/Colaboradores)
Descripcin informal en lenguaje natural
5-27
Anlisis mediante fichas CRC

(Clases/Responsabilidades/Colaboradores)
[Wirfs-Brock 1990] [Wilkinson 1995, captulo 4 ] [Bellin 1997]
Es una forma simple de analizar escenarios

Son muy tiles para la enseanza del AOO, DOO y POO
Facilitan las tormentas de ideas y la comunicacin entre
desarrolladores
Se crea una ficha para cada clase que se identifique como
relevante en el escenario
A medida que el equipo avanza puede dividir las
responsabilidades
Las fichas CRC pueden disponerse espacialmente para
representar relaciones de colaboracin
Las fichas CRC tambin se pueden colocar para expresar
jerarquas de generalizacin/especializacin
No estn contempladas en UML
Ficha CRC (anverso y reverso)

Clase
Clase
Responsabilidades
Superclase
Subclase
Colaboraciones
Atributos
5-28
Ejemplo de ficha CRC

Clase: Reunin
Responsabilidades
Planificar
Comprobar la sala asignada
Conocer hora de comienzo
Conocer la fecha
Conocer nmero de asistentes
Conocer equipamiento necesario
Colaboraciones
Sala de conferencias
Organizador de reuniones
Clase: Reunin
Superclase:
Subclases: Reunin de trabajo, Junta de Escuela, Clase de un curso
Atributos:
Orden del da
Lugar
Fecha
Hora de inicio
Asistentes
Equipo necesario
5-29
Descripcin informal en lenguaje natural

[Abbott 1983]
Subrayar los nombres y los verbos de la descripcin del problema

Los nombres representan los objetos candidatos
Los verbos representan las operaciones candidatas
Ventajas
Obliga al desarrollador a trabajar sobre el vocabulario del espacio del
problema
Es sencillo
Es didctico
Inconvenientes
No es riguroso, al ser el lenguaje natural ambiguo
Es compleja su aplicacin a grandes proyectos
5-30
Resumen
No existen recetas fciles para el anlisis de software

La correcta definicin de los requisitos y su seguimiento
en el proceso de desarrollo es uno de los factores
fundamentales de la calidad del software
Los escenarios son una potente herramienta para el
anlisis orientado a objetos, y pueden utilizarse para guiar
los procesos de anlisis clsico, anlisis del
comportamiento y anlisis de dominios.
Las abstracciones clave reflejan el vocabulario del
dominio del problema y pueden ser descubiertas en el
dominio del problema, o bien ser inventadas como parte
del diseo.
Los mecanismos denotan decisiones estratgicas de
diseo respecto a la actividad de colaboracin entre
muchos tipos diferentes de objetos
El nico artefacto que tiene UML a nivel de anlisis son
los Diagramas de Casos de Uso.
5-31
EJERCICIOS PROPUESTOS
5.1 Realizar el anlisis del juego del ajedrez. Se puede jugar dos personas entre s o
una persona contra el ordenador. En este ltimo caso debe ser posible seleccionar el
nivel de dificultad entre una lista de varios niveles. El juego de ajedrez permitir al
jugador elegir el color de las piezas. La aplicacin deber permitir detectar los
movimientos ilegales de las piezas, tiempos utilizados cada jugador, registro de
jugadas y piezas perdidas. Tambin determinar si se alcanzan tablas, y permitir
abandonar la partida a un jugador.
5.2 Realizar el anlisis de una aplicacin que realiza estudios de mercado para situar
grandes superficies (hipermercados). Se supone que cada gran superficie necesita un
mnimo de poblacin que pueda acceder a dicho hipermercado en menos de un tiempo
dado. La red de carreteras se puede representar mediante un grafo.
5.3 Realizar el anlisis para gestionar los fondos bibliogrficos y de socios de una
biblioteca por Internet.
5.4 Realizar el anlisis para gestionar un centro de enseanza (profesores,
asignaturas, alumnos, matriculacin, calificaciones de cada asignatura, expediente,...)
por Internet.
5-32
Referencias Bibliogrficas
[Abbott 1983] Abbott, R.J.Program Design by Informal English Descriptions. Comunications of the ACM, 26(11),882-894.
1983.
[Bock/Odell 1994] C. Bock and J. Odell, A Foundation For Composition, Journal of Object-oriented Programming,
October 1994.
[Booch 1994] G.Booch. Object-oriented analysis and design with applications. Benjamin Cummings (1994). Versin
castellana: Anlisis y diseo orientado a objetos con aplicaciones. 2 Edicin. Addison-Wesley/ Daz de Santos (1996).
[Booch 1999] G. Booch, J. Rumbaugh, I. Jacobson. The unified modeling language user guide. Addison-Wesley (1999).
Versin castellana El lenguaje unificado de modelado. Addison-Wesley (1999)
[Bellin 1997] D. Bellin and S. Suchman Simone.The CRC Card book. Addison-Wesley, 1997
[Coad 1991] P. Coad, E. Yourdon. Object-Oriented Analysis. Second Edition .Prentice-Hall, 1991.
[Cook 1994] S. Cook and J. Daniels, Designing Object Systems: Object-oriented Modelling with Syntropy, Prentice-Hall
Object-Oriented Series, 1994.
[Eriksson 1998] H-E Eriksson & M. Penker. UML Toolkit. Wiley, 1998.
[Fowler 1997] M. Fowler with K. Scott, UML Distilled: Applying the Standard Object Modeling Language, ISBN 0-20132563-2, Addison-Wesely, 1997. Versin castellana UML gota a gota, Addison-Wesley 1999.
[Jacobson 1992] I. Jacobson, M. Christerson, P. Jonsson, G. vergaard. Object-Oriented Software Enginneering. A use
Case Driven Approach., ISBN 0-201-54435-0, Addison-Wesely, 1992.
[Jacobson 1999] I. Jacobson, G. Booch, J. Rumbaugh. The unified software development process. Addison-Wesley
(1999).Versin Castellana. El Proceso Unificado de Desarrollo de Software. Prentice-Hall, 2000.
[Lee 1997] R. C.Lee & W. M. Tepfenhart. UML and C++, Prentice-Hall, 1997
[Piattini 1996] M.G. Piattini, J.A. Calvo-Manzano, J. Cervera, L. Fernndez. Anlisis y diseo detallado de aplicaciones
de gestin. RA-MA (1996)
[Rumbaught 1991] Rumbaught J., Blaha M., Premerlani W., Wddy F., Lorensen W. Object-oriented modeling and design.
Prentice-Hall (1991). Versin castellana: Modelado y diseo orientado a objetos. Metodologa OMT. Prentice-Hall (1996)
[Rumbaught 1999] Rumbaught J., I. Jacobson, G. Booch. The Unified Modeling Language Reference Manual. AddisonWesley (1999). Versin castellana. El Lenguaje Unificado de Modelado. Manual de Referencia.Addison-Wesley, 2000.
[Reenskaug 1996] T. Reenskaug. Working with Objects. The Ooram Software Engineering Method.Prentice-Hall, 1996
[Schneider 1998] G. Schneider, J. Winters. Applying Use Cases: A Practical Approach. Addison-Wesley, 1998.
[Wilkinson 1995 ] N. M. Wilkinson. Using CRC Cards. An Informal Approach to Object-Oriented Development, 1995,
SIGS BOOKS, ISBN 1-884842-07-0
[Wirfs-Brock 1990] R. Wirfs-Brock, B. Wilkerson y L. Wiener. Designing Object-Oriented Software.Pentice-Hall, 1990.
5-33
Referencias en la web
[Coad] Peter Coad http://www.togethersoft.com/
[OMG] Object Management Group, http://www.omg.org
[ROSE] Herramienta Rational Rose http://www.rational.com
[Shlaer-Mellor] Shlaer-Mellor Object-Oriented Analysis http://www.projtech.com
[UML] UML en www.rational.com y en http://www.omg.org
5-34

Analisis Orientado A O

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Analisis Orientado A O

Caricato da

Copyright:

Formati disponibili

Tema 5

Anlisis Orientado a Objetos

El proceso de desarrollo de software

Juan Manuel Cueva Lovelle

El proceso de desarrollo de software

No hay recetas mgicas, aunque es necesario tener un

Capas de abstraccin bien definidas

Es necesario distinguir entre decisiones estratgicas y tcticas

Ciclo de vida incremental e iterativo

Juan Manuel Cueva Lovelle

El proceso de desarrollo de software

Diseo preliminar y detallado

Implementacin & prueba unitaria

Juan Manuel Cueva Lovelle

El proceso de desarrollo de software

Detalle de un proceso de desarrollo de software

Caractersticas comunes de los documentos.

Identificacin. Ttulo, descripcin, versin, fecha, revisin, cdigo del documento..

Diseo (preliminar y detallado)

Modelado de Clases, Objetos y mecanismos de colaboracin

Las decisiones iniciales de implementacin se toman a partir de los diagramas

Construccin del modelo fsico

Diagramas de Clases y consulta de patrones de diseo.

Modelado del comportamiento de clases y objetos

Prueba unitaria de cada clase

Juan Manuel Cueva Lovelle

Anlisis Orientado a Objetos

Documentos bsicos de anlisis orientado a

Todos los documentos deben estar

Juan Manuel Cueva Lovelle

Juan Manuel Cueva Lovelle

Contiene la documentacin que aporta el

Juan Manuel Cueva Lovelle

Ejemplo de documento de anlisis

Juan Manuel Cueva Lovelle

Ejemplo de Documento de Anlisis (continuacin ...)

De cada ordenador se necesita saber su composicin (monitor, teclado, ratn y

Juan Manuel Cueva Lovelle

Ejemplo de Documento de Anlisis (continuacin ...)

Juan Manuel Cueva Lovelle

La captura de requisitos es el proceso de averiguar,

La especificacin de requisitos es un documento ms

Juan Manuel Cueva Lovelle

R.1.3 Modificar clientes.

Juan Manuel Cueva Lovelle

Diagramas de Casos de Uso (I)

Es uno de los cinco tipos de diagramas de UML que

Juan Manuel Cueva Lovelle

Diagramas de Casos de Uso (II)

El sistema que se desea modelar se representa encerrado en un rectngulo

Un actor es una clase

Se diferenciar entre actores y usuarios.

Un usuario es una persona que utiliza el sistema

Los Casos de Uso es un camino especfico para utilizar el sistema

El diagrama de Casos de Uso es un diagrama sencillo que tiene como

Lmites del sistema

Ejemplo de Casos de Uso

Juan Manuel Cueva Lovelle

Ejemplo de descripcin de los Casos de Uso

Juan Manuel Cueva Lovelle

Ejemplo de Casos de Uso

Juan Manuel Cueva Lovelle

Juan Manuel Cueva Lovelle