UNIVERSIDAD DEL PACIFICO

CAMPUS SALINA CRUZ

DESARROLLO ORIENTADO A
OBJETOS
UNIDAD IV

EL PROCESO UNIFICADO DE DESARROLLO

DE SOFTWARE

INTRODUCCION

EL PROCESO UNIFICADO DE DESARROLLO DE

SOFTWARE.
Cuando se va a construir un sistema software es necesario conocer un
lenguaje de programacin, pero con eso no basta. Si se quiere que el
sistema sea robusto y mantenible es necesario que el problema sea
analizado y la solucin sea cuidadosamente diseada. Se debe seguir un
proceso robusto, que incluya las actividades principales. Si se sigue un
proceso de desarrollo que se ocupa de plantear cmo se realiza el anlisis
y el diseo, y cmo se relacionan los productos de ambos, entonces la
construccin de sistemas software va a poder ser planificable y repetible,
y la probabilidad de obtener un sistema de mejor calidad al final del
proceso aumenta considerablemente, especialmente cuando se trata de
un equipo de desarrollo formado por varias personas.

EL PROCESO UNIFICADO DE DESARROLLO

DE SOFTWARE.
La notacin que se usa para los distintos modelos, tal y como se ha dicho anteriormente, es la
proporcionada por UML, que se ha convertido en el estndar de facto en cuanto a notacin
orientada a objetos. El uso de UML permite integrar con mayor facilidad en el equipo de
desarrollo a nuevos miembros y compartir con otros equipos la documentacin, pues es de
esperar que cualquier desarrollador versado en orientacin a objetos conozca y use UML (o se
est planteando su uso).
Se va a abarcar todo el ciclo de vida, empezando por los requisitos y acabando en el sistema
funcionando, proporcionando as una visin completa y coherente de la produccin de sistemas
software. El enfoque que toma es el de un ciclo de vida iterativo incremental, el cual permite
una gran flexibilidad a la hora de adaptarlo a un proyecto y a un equipo de desarrollo
especficos. El ciclo de vida est dirigido por casos de uso, es decir, por la funcionalidad que
ofrece el sistema a los futuros usuarios del mismo. As no se pierde de vista la motivacin
principal que debera estar en cualquier proceso de construccin de software: el resolver una
necesidad del usuario/cliente.

VISIN GENERAL
El proceso a seguir para realizar desarrollo orientado a objetos es
complejo, debido a la complejidad que nos vamos a encontrar al
intentar desarrollar cualquier sistema software de tamao medioalto. El proceso est formado por una serie de actividades y
subactividades, cuya realizacin se va repitiendo en el tiempo
aplicadas a distintos elementos. En este apartado se va a
presentar una visin general para poder tener una idea del
proceso a alto nivel, y ms adelante se vern los pasos que
componen cada fase. Las tres fases al nivel ms alto son las
siguientes:

VISIN GENERAL
Planificacin y Especificacin de Requisitos: Planificacin, definicin de requisitos,
construccin de prototipos, etc.

Construccin: La construccin del sistema. Las fases dentro de esta etapa son las siguientes:
- Anlisis: Se analiza el problema a resolver desde la perspectiva de los usuarios y de las
entidades externas que van a solicitar servicios al sistema.

- Diseo: El sistema se especifica en detalle, describiendo cmo va a funcionar internamente

para satisfacer lo especificado en el anlisis.
- Implementacin: Se lleva lo especificado en el diseo a un lenguaje de programacin.
- Pruebas: Se llevan a cabo una serie de pruebas para corroborar que el software funciona
correctamente y que satisface lo especificado en la etapa de Planificacin y Especificacin de
Requisitos.

VISIN GENERAL
Instalacin: La puesta en marcha del sistema en el entorno
previsto de uso.
Con esta aproximacin se consigue disminuir el grado de
complejidad que se trata en cada ciclo, y se tiene pronto en el
proceso una parte del sistema funcionando que se puede
contrastar con el usuario/cliente.

FASE DE PLANIFICACIN.
Esta fase corresponde a la construccin de un borrador de lo
que se pretende realizar de forma conceptual y una definicin
de casos de uso, aqu se decide si se aborda con lenguajes
orientados a objeto o no, en esta fase es completamente
independiente del lenguaje con que se crea al final.

DESARROLLO ORIENTADO A OBJETOS

FASE DE ANALISIS: FASE DE PLANIFICACION

FASE DE PLANIFICACIN.
Actividades:
Las actividades de esta fase son las siguientes:

1.
2.

Definir el Plan-Borrador.
Crear el Informe de Investigacin Preliminar.

PLAN BORRADOR
Plan Estratgico
Qu es el plan borrador?
Elplan borradores un programa de actuacin que consiste en aclarar lo que
pretendemos conseguir y cmo nos proponemos conseguirlo. Esta programacin se
plasma en un documento de consenso donde concretamos las grandes decisiones
que van a orientar nuestra marcha hacia la gestin excelente del proyecto.
Objetivo del plan borrador

- Trazar un mapa de la organizacin, que seale los pasos para alcanzar nuestra
visin.

- Convertir los proyectos en acciones (tendencias, metas, objetivos, reglas,

verificacin y resultados)

PLAN BORRADOR
Por qu lo hacemos?
Para afirmar la organizacin:Fomentar la vinculacin entre los rganos de decisin (E.D.) y los distintos grupos de trabajo.
Buscar el compromiso de todos.

Para descubrir lo mejor de la organizacin:El objetivo es hacer participar a las personas en la valoracin de las cosas que
hacemos mejor, ayudndonos a identificar los problemas y oportunidades.

Aclarar ideas futuras:Muchas veces, las cuestiones cotidianas, el da a da de nuestra empresa, nos absorben tanto que no nos
dejan ver ms all de maana. Este proceso nos va a obligar a hacer una pausa necesaria para que nos examinemos como
organizacin y si verdaderamente tenemos un futuro que construir.

Qu contiene el plan borrador? A qu preguntas responde?

Qu es lo que se va a hacer? Qu va a hacer?Qu necesita para hacerlo?: declaracin de laMisin.
Cundo lo vamos a hacer?:Visinestratgica.
Cmo lo va a hacer? Qu resultados vamos a obtener?: Proposiciones;Objetivos estratgicos.
Qu necesitamos para que lo haga?En que lo vamos a hacer?:Plan de accin; Reglamento de evaluacin.

REDACTAR EL PLAN BORRADOR

Si en los pasos anteriores era imprescindible asegurar la
participacin y el acuerdo del mayor nmero de personas
(implicados), la redaccin delplan borradordebe encargarse
a una persona o a un grupo muy reducido, que recoja la
informacin generada, la sistematice y la presente de forma
ordenada.

REDACTAR EL PLAN BORRADOR

Presentacin
Delimitacin de prioridades estratgicas, definicin de escenario, estructura de objetivos

Introduccin
Misin y Visin
Anlisis de la situacin actual
Diagnstico

Formular estrategias
Priorizar

Plan de accin
Plan operativo
Una vez elaborado elplan borrador, es aconsejable que circule con el fin de que sea revisado por
los distintos participantes antes de su redaccin definitiva.

Comunicar
Es necesario comunicarse a todos los niveles de la organizacin y explicarse en detalle.

CREAR EL INFORME DE INVESTIGACIN

PRELIMINAR
La investigacin preliminar tambin es conocida comoEstudio de Viabilidad.
Se deben tomar en cuenta los siguientes aspectos que determinarn una buena
investigacin preliminar.
1.- Aclarar y comprender la solicitud del proyecto.
Se deben tener en cuenta preguntas como: Qu se desea realizar? Qu es lo que se
requiere? Por qu? Esto permitir determinar si la solicitud presentada por una persona
es viable o no tiene sustentacin.
Ejemplo:En una empresa que fabrica chompas se requiere crear un sistema informtico
que lleve los inventarios de los productos que esta produce. Para esto el solicitante indica
que es necesario llevar un registro de dichos productos con la finalidad de mantener un
control exacto de la materia prima, productos elaborados que la empresa genera.

CREAR EL INFORME DE INVESTIGACIN

PRELIMINAR
2.- Determinar el tamao del proyecto.
En todo inicio de proyecto informtico se deben tomar en cuenta el alcance del
proyecto, es decir, los lmites hasta los cuales va a cubrir el nuevo sistema. Se
debe tener muy en cuenta este aspecto debido a que se deben tener bien claros
los alcances y firmar con la persona que requiere el nuevo programa para que en
lo posterior los cambios no sean a gran escala ya que esto implicara nuevas
lneas de cdigo y altos costos tanto humanos como econmicos. Aqu tambin
se verificarn quienes utilizarn el sistema y los datos que se manejaran.
Ejemplo:En el caso de la empresa que fabrica chompas debemos preguntar si el
sistema informtico solo va a manejar el inventario de productos, porque
estableceremos los alcances a los cuales debe atender el sistema creado.

CREAR EL INFORME DE INVESTIGACIN

PRELIMINAR
3.- Evaluar los costos y beneficios de las diferentes opciones.
Todo sistema implica costos. Desde su creacin este factor deber ser
tomado muy en cuenta para la creacin del nuevo sistema. Se deben
estudiar los precios que se pagaran por el personal de desarrollo, el de
capacitacin y el tiempo que se utilizar en el mismo.
Ejemplo:Si se requiere automatizar el inventario se deber cancelar el
valor acordado con el analista-programador que ser encargado de
realizar este sistema y de brindar la capacitacin necesaria para el
correcto uso del mismo as como tambin se cubrir los costos de los
equipos que se requieran para la instalacin del sistema.

CREAR EL INFORME DE INVESTIGACIN

PRELIMINAR
4.- Determinar la factibilidad tcnica y operacional.
La factibilidad tcnica, econmica y operacional permitir
conocer por medio de informes si la realizacin del sistema es
viable o no.
Ejemplo:Si la empresa de chompas tiene el dinero, personal y
tiempo necesario para cubrir las demandas que implica el
nuevo desarrollo de software.

CREAR EL INFORME DE INVESTIGACIN

PRELIMINAR
5.- Formular recomendaciones para el desarrollo de
proyectos.
Finalmente se debern establecer los mecanismos necesarios
y las sugerencias o recomendaciones que permitan mejorar los
procesos.
Ejemplo: Se debe sugerir que la implementacin del sistema
de registro de inventarios de la empresa de chompas permitir
conocer si los productos y la materia prima existente permitir
desarrollar el trabajo de manera adecuado optimizando los
recursos de la misma.

FASE DE ESPECIFICACIN DE REQUISITOS.

Un requisito es una descripcin de necesidades o aspiraciones respecto a un producto. El
objetivo principal de la actividad de definicin de requisitos consiste en identificar qu es lo
que realmente se necesita, separar el grano de la paja. Esto se hace en un modo que sirva
de comunicacin entre el cliente y el equipo de desarrollo. Es aconsejable que un
documento de Especificacin de Requisitos tenga los siguientes puntos:

- Propsito.
- mbito del Sistema, Usuarios.
- Funciones del Sistema.
- Atributos del Sistema.
El formato del documento de Especificacin de Requisitos no est definido en UML, pero se
ha incluido este punto para resaltar que la actividad de definicin de requisitos es un paso
clave en la creacin de cualquier producto software.

DESARROLLO ORIENTADO A OBJETOS

FASE DE ANALISIS: FASE DE ESPECIFICACION DE REQUISITOS

FASE DE ESPECIFICACIN DE REQUISITOS.

Actividades:

1.
2.
3.
4.
5.

Definir los Requisitos.

Registrar Trminos en el Glosario. (continuado en posteriores fases)
Implementar un Prototipo. (opcional).
Definir Casos de Uso (de alto nivel y esenciales).
Definir el Modelo Conceptual-Borrador. (puede retrasarse hasta una fase
posterior).

6. Definir la Arquitectura del Sistema-Borrador. (puede retrasarse hasta una fase

posterior)

7. Refinar el Plan.

CASOS DE USO
Un Caso de Uso es un documento narrativo que describe la secuencia de
eventos de un actor (un agente externo) que usa un sistema para completar
un proceso. Es una historia o una forma particular de usar un sistema. Los
casos de uso no son exactamente requisitos ni especificaciones funcionales,
pero ilustran e implican requisitos en las historias que cuentan.
El formato textual que se va a usar en este texto para definir los caso de uso
se va a definir a continuacin, mientras que la representacin de los
escenarios correspondientes a un caso de uso por medio de Diagramas de
Secuencia se ver ms adelante. En un primer momento interesa abordar un
caso de uso desde un nivel de abstraccin alto, es lo que se denomina Caso
de Uso de Alto Nivel.

CASOS DE USO DE ALTO NIVEL

El siguiente Caso de Uso de Alto Nivel describe el proceso de sacar dinero cuando se est
usando un cajero automtico:

- Caso de Uso: Realizar Retiro

- Actores: Cliente
- Tipo: primario
- Descripcin: Un Cliente llega

al cajero automtico, introduce la tarjeta, se identifica y

solicita realizar una operacin de reintegro por una cantidad especfica. El cajero le da el
dinero solicitado tras comprobar que la operacin puede realizarse. El Cliente coge el
dinero y la tarjeta y se va.

En un caso de uso descrito a alto nivel la descripcin es muy general, normalmente se

condensa en dos o tres frases. Es til para comprender el mbito y el grado de complejidad
del sistema.

CASOS DE USO EXPANDIDOS.

Los casos de uso que se consideren los ms importantes y que se considere que son los que ms influencian
al resto, se describen a un nivel ms detallado: en el formato expandido.
La principal diferencia con un caso de uso de alto nivel est en que incluye un apartado de Curso Tpico de
Eventos, pero tambin incluye otros apartados como se ve en el siguiente ejemplo:

- Caso de Uso: Realizar Reintegro

- Actores: Cliente (iniciador)
- Propsito: Realizar una operacin de reintegro de una cuenta del banco.
- Visin General: Un Cliente llega al cajero automtico, introduce la tarjeta, se identifica y solicita realizar
una operacin de reintegro por una cantidad especfica. El cajero le da el dinero solicitado tras comprobar
que la operacin puede realizarse. El Cliente coge el dinero y la tarjeta y se va.

- Tipo: primario y esencial

- Referencias: Funciones: R1.3, R1.7.
- Curso tpico de eventos:

CASOS DE USO EXPANDIDOS

Accin de Actor.
1.- Este caso de uso empieza cuando un
Cliente introduce una tarjeta en el
cajero.
3.- Introduce la clave.
5.- Selecciona la operacin de reintegro.

Respuesta del sistema.

2.- Pide la clave del sistema.
4.- Presenta las opciones de operaciones disponibles.
6.- Pide la cantidad a retirar.

7.- Introduce la cantidad requerida.

8.- Procesa la peticin y, eventualmente, da el dinero solicitado.

9.- Recoge la tarjeta.

Devuelve la tarjeta y genera un recibo.

10.- Recoge el recibo.

11.- Recoge el dinero y se va.

CASOS DE USO EXPANDIDOS.

Cursos Alternativos:
Lnea 4: La clave es incorrecta. Se indica el error y se cancela
la operacin.
Lnea 8: La cantidad solicitada supera el saldo. Se indica el
error y se cancela la operacin.

CASOS DE USO EXPANDIDOS.

El significado de cada apartado de este formato es como sigue:

- Caso de Uso: Nombre del Caso de Uso

- Actores: Lista de actores (agentes externos), indicando quin inicia el caso de uso. Los actores son normalmente
roles que un ser humano desempea, pero puede ser cualquier tipo de sistema.

- Propsito: Intencin del caso de uso.

- Visin General: Repeticin del caso de uso de alto nivel, o un resumen similar.
- Tipo: 1. primario, secundario u opcional (descritos ms adelante).
- 2. esencial o real (descritos ms adelante).
- Referencias: Casos de uso relacionados y funciones del sistema que aparecen en los requisitos.
- Curso Tpico de Eventos: Descripcin de la interaccin entre los actores y el sistema mediante las acciones
numeradas de cada uno. Describe la secuencia ms comn de eventos, cuando todo va bien y el proceso se
completa satisfactoriamente. En caso de haber alternativas con grado similar de probabilidad se pueden aadir
secciones adicionales a la seccin principal.

- Cursos Alternativos: Puntos en los que puede surgir una alternativa, junto con la descripcin de la excepcin.

IDENTIFICACIN DE CASOS DE USO

La identificacin de casos de uso requiere un conocimiento medio acerca de los
requisitos, y se basa en la revisin de los documentos de requisitos existentes, y en
el uso de la tcnica de brainstorming entre los miembros del equipo de desarrollo.
Como gua para la identificacin inicial de casos de uso hay dos mtodos:

a) Basado en Actores
1. Identificar los actores relacionados con el sistema y/o la organizacin.
2. Para cada actor, identificar los procesos que inicia o en los que participa.
b) Basado en Eventos

1. Identificar los eventos externos a los que el sistema va a tener que responder.
2. Relacionar los eventos con actores y casos de uso.

IDENTIFICACIN DE CASOS DE USO

Ejemplos de casos de uso:
Pedir un producto.
Matricularse en un curso de la facultad.
Comprobar la ortografa de un documento en un procesador
de textos.
Realizar una llamada telefnica.

IDENTIFICACIN DE LOS LMITES DEL

SISTEMA
En la descripcin de un caso de uso se hace referencia en todo momento al sistema. Para
que los casos de uso tengan un significado completo es necesario que el sistema est definido
con precisin.
Al definir los lmites del sistema se establece una diferenciacin entre lo que es interno y lo
que es externo al sistema. El entorno exterior se representa mediante los actores.
Ejemplos de sistemas son:
El hardware y software de un sistema informtico.
Un departamento de una organizacin.
Una organizacin entera.
Si no se est haciendo reingeniera del proceso de negocio lo ms normal es escoger como
sistema el primero de los ejemplos: el hardware y el software del sistema que se quiere
construir.

TIPOS DE CASOS DE USO.

a) Segn Importancia.
Para poder priorizar los casos de uso que identifiquemos los vamos a
distinguir entre:
Primarios: Representan los procesos principales, los ms comunes,
como Realizar Reintegro en el caso del cajero automtico.
Secundarios: Representan casos de uso menores, que van a
necesitarse raramente, tales como Aadir Nueva Operacin.
Opcionales: Representan procesos que pueden no ser abordados en
el presente proyecto.

TIPOS DE CASOS DE USO.

b) Segn el Grado de Compromiso con el Diseo En las descripciones que se han
visto anteriormente no se han hecho apenas compromisos con la solucin, se han
descrito los casos de uso a un nivel abstracto, independiente de la tecnologa y de la
implementacin. Un caso de uso definido a nivel abstracto se denomina esencial.
Los casos de uso definidos a alto nivel son siempre esenciales por naturaleza, debido
a su brevedad y abstraccin.
Por el contrario, un caso de uso real describe concretamente el proceso en trminos
del diseo real, de la solucin especfica que se va a llevar a cabo. Se ajusta a un
tipo de interfaz especfica, y se baja a detalles como pantallas y objetos en las
mismas.
Como ejemplo de una parte de un Caso de Uso Real para el caso del retiro en un
cajero automtico tenemos la siguiente descripcin del Curso Tpico de Eventos:

TIPOS DE CASOS DE USO.

Accin del Actor
1.- Este caso de uso empieza
cuando un Cliente introduce
una tarjeta en la ranura.
3.- Introduce el PIN a travs
del teclado numrico.
5.- etc.

Respuesta del Sistema

2.- Pide el PIN(Personal Identification Number).
4.- Presenta las opciones de operaciones disponibles.
6.- etc.

NOTAS SOBRE CASOS DE USO.

En principio, los casos de uso reales deberan ser creados en la fase de
Diseo y no antes, puesto que se trata de elementos de diseo. Sin embargo,
en algunos proyectos se plantea la definicin de interfaces en fases
tempranas del ciclo de desarrollo, en base a que son parte del contrato. En
este caso se pueden definir algunos o todos los casos de uso reales, a pesar
de que suponen tomar decisiones de diseo muy pronto en el ciclo de vida.
No hay una diferencia estricta entre un Caso de Uso Esencial y uno Real, el
grado de compromiso con el Diseo es un continuo, y una descripcin
especfica de un caso de uso estar situada en algn punto de la lnea entre
Casos de Uso Esenciales y Reales, normalmente ms cercano a un extremo
que al otro, pero es raro encontrar Casos de Uso Esenciales o Reales puros.

CONSEJOS RELATIVOS A CASOS DE USO.

a) Nombre
El nombre de un Caso de Uso debera ser un verbo, para enfatizar que se trata de
un proceso, por ejemplo: Comprar Artculos o Realizar Pedido.
b) Alternativas equiprobables
Cuando se tiene una alternativa que ocurre de manera relativamente ocasional, se
indica en el apartado Cursos Alternativos. Pero cuando se tienen distintas opciones,
todas ellas consideradas normales se puede completar el Curso Tpico de Eventos
con secciones adicionales.
As, si en un determinado nmero de lnea hay una bifurcacin se pueden poner
opciones que dirigen el caso de uso a una seccin que se detalla al final del Curso
Tpico de Eventos, en la siguiente forma:

CURSO TPICO DE EVENTOS.

Accin del Actor.
1.- Inicia cuando Actor llega al sistema.
3.- Escoge la operacin A.
5.- Selecciona el tipo de pago.

Respuesta del Sistema.

a)Si se paga al contado ver seccin

Pago al contado.

2.- Pide la operacin a realizar.

b) Si se paga con tarjeta ver seccin

Pago con tarjeta.
7..- Recoge el recibo y se va.

4.- Presenta las opciones de pago.

6.- Genera el recibo.

CURSOS ALTERNATIVOS
Lneas 3 y 5 selecciona Cancelar. Se cancela la operacin.
- Seccin: Pago al contado.
Accin del Actor

Respuesta del Sistema

1.- Mete los billetes

correspondientes.

1.- Coge los billetes y

sigue pidiendo dinero
hasta que la cantidad
est satisfecha.

Cursos Alternativos:
- Lnea 3: No hay
cambio suficiente. Se
cancela la operacin.

- Devuelve el cambio.

CONSTRUCCIN DEL MODELO DE CASOS

DE USO
Para construir el Modelo de Casos de Uso en la fase de Planificacin y Especificacin de Requisitos se siguen
los siguientes pasos:

1.

Despus de listar las funciones del sistema, se definen los lmites del sistema y se identifican los
actores y los casos de uso.

2.

Se escriben todos los casos de uso en el formato de alto nivel. Se categorizan como primarios,
secundarios u opcionales.

3.

Se dibuja el Diagrama de Casos de Uso.

4.

Se relacionan los casos de uso y se ilustran las relaciones en el Diagrama de Casos de Uso (<> y <>).

5.

Los casos de uso ms crticos, importantes y que conllevan un mayor riesgo, se describen en el
formato expandido esencial. Se deja la definicin en formato expandido esencial del resto de casos de
uso para cuando sean tratados en posteriores ciclos de desarrollo, para no tratar toda la complejidad
del problema de una sola vez.

6. Se crean casos de uso reales slo cuando:

Descripciones ms detalladas ayudan significativamente a incrementar la comprensin del problema.
El cliente pide que los procesos se describan de esta forma.
7. Ordenar segn prioridad los casos de uso (este paso se va a ver a continuacin).

PLANIFICACIN DE CASOS DE USO SEGN

CICLOS DE DESARROLLO.

PLANIFICACIN DE CASOS DE USO SEGN

CICLOS DE DESARROLLO.
Para tomar la decisin de qu casos de uso se van a tratar primero es necesario ordenarlos
segn prioridad. Las caractersticas de un caso de uso especfico que van a hacer que un caso
de uso tenga una prioridad alta son las siguientes:

a. Impacto significativo en el diseo de la arquitectura. Por ejemplo, si aporta muchas clases

al modelo del dominio o requiere persistencia en los datos.

b. Se obtiene una mejor comprensin del diseo con un nivel de esfuerzo relativamente bajo.
c. Incluye funciones complejas, crticas en el tiempo o de nivel elevado de riesgo.
d. Implica bien un trabajo de investigacin significante, o bien el uso de una tecnologa nueva
o arriesgada.

e. Representa un proceso de gran importancia en la lnea de negocio.

f. Supone directamente un aumento de beneficios o una disminucin de costos.

PLANIFICACIN DE CASOS DE USO SEGN

CICLOS DE DESARROLLO.
Para realizar la clasificacin se puede asignar a cada caso de uso una
valoracin numrica de cada uno de estos puntos, para conseguir
una puntuacin total aplicando pesos a cada apartado. En la
siguiente tabla se muestra un ejemplo de tal tipo de clasificacin:

CASO DE USO INICIALIZACIN.

Prcticamente todos los sistemas van a tener un caso de uso
Inicializacin. Aunque puede ser que no tenga una prioridad
alta en la clasificacin realizada segn el punto anterior,
normalmente va a interesar que sea desarrollado desde el
principio. Inicialmente se desarrolla una versin simplificada,
que se va completando en cada ciclo de desarrollo para
satisfacer las necesidades de inicializacin de los casos de uso
que se tratan en dicho ciclo. As se tiene un sistema en cada
ciclo de desarrollo que puede funcionar.

DESARROLLO ORIENTADO A OBJETOS

FASE DE CONSTRUCCION: FASE DE ANALISIS

FASE DE ANLISIS
En la fase de Anlisis de un ciclo de desarrollo se investiga sobre el problema, sobre los
conceptos relacionados con el subconjunto de casos de uso que se est tratando. Se intenta
llegar a una buena comprensin del problema por parte del equipo de desarrollo, sin entrar
en cmo va a ser la solucin en cuanto a detalles de implementacin.
Cuando el ciclo de desarrollo no es el primero, antes de la fase de Anlisis hay una serie de
actividades de planificacin. Estas actividades consisten en actualizar los modelos que se
tengan segn lo que se haya implementado, pues siempre se producen desviaciones entre
lo que se ha analizado y diseado y lo que finalmente se construye. Una vez se tienen los
modelos acordes con lo implementado se empieza el nuevo ciclo de desarrollo con la fase
de Anlisis.
En esta fase se trabaja con los modelos de Anlisis construidos en la fase anterior,
amplindolos con los conceptos correspondientes a los casos de uso que se traten en el
ciclo de desarrollo actual.

ACTIVIDADES.
Las actividades de la fase de Anlisis son las siguientes:

1. Definir Casos de Uso Esenciales en formato expandido. (si no estn

definidos).

2.
3.
4.
5.
6.
7.

Refinar los Diagramas de Casos de Uso.

Refinar el Modelo Conceptual.
Refinar el Glosario. (continuado en posteriores fases).
Definir los Diagramas de Secuencia del Sistema.
Definir Contratos de Operacin.
Definir Diagramas de Estados. (opcional)

MODELO CONCEPTUAL.
Una parte de la investigacin sobre el dominio del problema consiste en
identificar los conceptos que lo conforman. Para representar estos
conceptos se va a usar un Diagrama de Estructura Esttica de UML, al
que se va a llamar Modelo Conceptual.
En el Modelo Conceptual se tiene una representacin de conceptos del
mundo real, no de componentes software.
El objetivo de la creacin de un Modelo Conceptual es aumentar la
comprensin del problema. Por tanto, a la hora de incluir conceptos en el
modelo, es mejor crear un modelo con muchos conceptos que quedarse
corto y olvidar algn concepto importante.

TIPO DE CONCEPTO

EJEMPLOS

IDENTIFICACI
N DE
CONCEPTOS.

Objetos fsicos o tangibles

Avin, Terminal_de_Caja

Especificaciones, diseos o
descripciones de cosas.

Especificacin_de_Producto,
Descripcion_de_Vuelo

Lugares

Supermercado, Aeropuerto

Para
identificar
conceptos hay que
basarse
en
el
documento
de
Especificacin
de
Requisitos y en el
conocimiento general
acerca del dominio
del problema.

Transacciones

Venta, Pago, Reservacin

Lneas de una transaccin

Artculo_de_Venta

Roles de una persona

Cajero, Piloto

Contenedores de otras cosas

Supermercado, Cesta, Avin

Cosas en un contenedor

Artculo, Pasajero

Otros ordenadores o sistemas

electromecnicos externos a
nuestro sistema

Sistema_de_Autorizacin_de_Tarj
etas_de_Credito,
Sistema_Controlador_de_Trfico_
Areo

Conceptos abstractos

Hambre, Sed

Organizaciones

Departamento_de_Ventas,
Compaa_Aerea_Toto

Eventos

Venta, Robo, Reunin, Vuelo,

Accidente

Reglas y Politicas

Politica_de_Devoluciones,

IDENTIFICACIN DE CONCEPTOS.
Otro consejo para identificar conceptos consiste en buscar sustantivos en los documentos de
requisitos o, ms concretamente, en la descripcin de los casos de uso. No es un mtodo
infalible, pero puede servir de gua para empezar.
Para poner nombre a los conceptos se puede usar la analoga con el cartgrafo, resumida en los
siguientes tres puntos:
Usar los nombres existentes en el territorio: Hay que usar el vocabulario del dominio para
nombrar conceptos y atributos.
Excluir caractersticas irrelevantes: Al igual que el cartgrafo elimina caractersticas no
relevantes segn la finalidad del mapa (por ejemplo datos de poblacin en un mapa de
carreteras), un Modelo Conceptual puede excluir conceptos en el dominio que no son
pertinentes en base a los requisitos.
No aadir cosas que no estn ah: Si algo no pertenece al dominio del problema no se aade al
modelo.

CREACIN DEL MODELO CONCEPTUAL

Para crear el Modelo Conceptual se siguen los siguientes pasos:

1. Hacer una lista de conceptos candidato usando la Lista de

Categoras de Conceptos y la bsqueda de sustantivos

relacionados con los requisitos en consideracin en este ciclo.

2. Representarlos en un diagrama.
3. Aadir las asociaciones necesarias para ilustrar las relaciones
entre conceptos que es necesario conocer.

4. Aadir los atributos necesarios para contener toda la informacin

que se necesite conocer de cada concepto.

IDENTIFICACIN DE ASOCIACIONES
Una asociacin es una relacin entre conceptos que indica una
conexin con sentido y que es de inters en el conjunto de
casos de uso que se est tratando. Se incluyen en el modelo
las asociaciones siguientes:
Asociaciones para las que el conocimiento de la relacin
necesita mantenerse por un cierto perodo de tiempo
(asociaciones necesita-conocer).
Asociaciones derivadas de la Lista de Asociaciones Tpicas.

LISTA DE ASOCIACIONES TPICAS.

CATEGORIA

EJEMPLOS

A es una parte fsica de B

Ala Avin

A es una parte lgica de B

Articulo_en_Venta Venta

A esta contenido fsicamente en B

Articulo Estanteria, Pasajero Avion

A esta lgicamente contenido en B

Descripcin_de_Artculo Catlogo

A es una descripcin de B

Descripcin_de_Artculo Artculo

A es un elemento en una transaccin o

un informe B

Trabajo_de_Reparacin
Registro_de_Reparaciones

A es registrado/archivado/capturado en B Cajero_Supermercado,
Mantenimiento_Compaia_Aerea
A es una subunidad organizativa de B

Seccin_Supermercado,
Mantenimiento_Compaia_Aerea

A usa o gestiona B

Cajero - Terminal_de_Caja, Piloto Avion

A comunica con B

Cliente Cajero, Empleado

Agencia_de_Viajes

IDENTIFICACIN DE ATRIBUTOS
Es necesario incorporar al Modelo Conceptual los atributos necesarios para satisfacer las necesidades de
informacin de los casos de uso que se estn desarrollando en ese momento.
Los atributos deben tomar valor en tipos simples (nmero, texto, etc.), pues los tipos complejos deberan
ser modelados como conceptos y ser relacionados mediante asociaciones.
Incluso cuando un valor es de un tipo simple es ms conveniente representarlo como concepto en las
siguientes ocasiones:
Se compone de distintas secciones. Por ejemplo: un nmero de telfono, el nombre de una persona, etc.
Tiene operaciones asociadas, tales como validacin. Ejemplo: NIF.
Tiene otros atributos. Por ejemplo un precio de oferta puede tener fecha de fin.
Es una cantidad con una unidad. Ejemplo: El precio, que puede estar en pesos o en euros.
Una vez definidos los atributos se tiene ya un Modelo Conceptual. Este modelo no es un modelo
definitivo, pues a lo largo del Anlisis y del Diseo se va refinando segn se le aaden conceptos que se
haban pasado por alto.

GLOSARIO.
En el glosario debe aparecer una descripcin textual de cualquier
elemento de cualquier modelo, para eliminar toda posible ambigedad.

TERMINO

CATEGORIA

DESCRIPCION

Realizar Retiro

Caso de Uso

Descripcin del proceso por el que un

Cliente realiza un retiro en un cajero
automatico.

Banco

concepto

Entidad que ofrece servicios financieros a

sus clientes

DIAGRAMAS DE SECUENCIA DEL SISTEMA.

Adems de investigar sobre los conceptos del sistema y su estructura, tambin es
preciso investigar en el Anlisis sobre el comportamiento del sistema, visto ste
como una caja negra. Una parte de la descripcin del comportamiento del sistema
se realiza mediante los Diagramas de Secuencia del Sistema.
En cada caso de uso se muestra una interaccin de actores con el sistema. En esta
interaccin los actores generan eventos, solicitando al sistema operaciones. Por
ejemplo, en el caso de una reserva de un billete de avin, el empleado de la
agencia de viajes solicita al sistema de reservas que realice una reserva. El evento
que supone esa solicitud inicia una operacin en el sistema de reservas. Los casos
de uso representan una interaccin genrica. Una instancia de un caso de uso se
denomina escenario, y muestra una ejecucin real del caso de uso, con las posibles
bifurcaciones y alternativas resueltas de forma particular.

DIAGRAMAS DE SECUENCIA DEL SISTEMA.

Un Diagrama de Secuencia de Sistema se representa usando la
notacin para diagramas de secuencia de UML. En l se muestra
para un escenario particular de un caso de uso los eventos que
los actores generan, su orden, y los eventos que se intercambian
entre sistemas. Para cada caso de uso que se est tratando se
realiza un diagrama para el curso tpico de eventos, y adems se
realiza un diagrama para los cursos alternativos de mayor inters.
En la Figura se muestra el Diagrama de Secuencia del Sistema
para el caso de uso Realizar Reintegro de un cajero automtico.

DIAGRAMAS DE SECUENCIA DEL SISTEMA.

CONSTRUCCIN DE UN DIAGRAMA DE
SECUENCIA DEL SISTEMA.
Para construir un Diagrama de Secuencia del Sistema para el curso tpico de eventos de un
caso de uso, se siguen los siguientes pasos:

1.
2.

Representar el sistema como un objeto con una lnea debajo.

3.

Partiendo del texto del curso tpico de eventos del caso de uso, identificar los eventos
(externos) del sistema que cada actor genera y representarlos en el diagrama.

4.

Opcionalmente, incluir el texto del caso de uso en el margen del diagrama.

Identificar los actores que directamente operan con el sistema, y dibujar una lnea para
cada uno de ellos.

Los eventos del sistema deberan expresarse en base a la nocin de operacin que
representan, en vez de en base a la interfaz particular. Por ejemplo, se prefiere
finOperacin a presionadaTeclaEnter, porque captura la finalidad de la operacin sin
realizar compromisos en cuanto a la interfaz usada.

CONTRATOS DE OPERACIONES.
Una vez se tienen las Operaciones del Sistema identificadas en los Diagramas de
Secuencia, se describe mediante contratos el comportamiento esperado del sistema en
cada operacin.
Un Contrato es un documento que describe qu es lo que se espera de una operacin.
Tiene una redaccin en estilo declarativo, enfatizando en el qu ms que en el cmo. Lo
ms comn es expresar los contratos en forma de pre- y post-condiciones en torno a
cambios de estado.
Se puede escribir un contrato para un mtodo individual de una clase software, o para una
operacin del sistema completa. En este punto se ver nicamente ste ltimo caso.
Un Contrato de Operacin del Sistema describe cambios en el estado del sistema cuando
una operacin del sistema es invocada. A continuacin se ve un ejemplo de Contrato:

CONTRATOS DE OPERACIONES.
Nombre: insertarTarjeta (nmero_tarjeta: nmero).
Responsabilidades: Comenzar una sesin con el sistema para realizar una operacin.
Presentar las opciones disponibles.
Referencias Cruzadas:
Funciones del Sistema: R1.2, R1.6, R1.7
Casos de Uso:
Reintegro Notas:
Excepciones: Si la tarjeta es ilegible, indicar que ha habido un error. Salida: Pre-condiciones:
No hay una sesin activa. Post-condiciones:
Una nueva Sesin se ha creado. (creacin de instancia).
La Sesin se ha asociado con Cajero. (asociacin formada).

CONTRATOS DE OPERACIONES.

CONSTRUCCIN DE UN CONTRATO.
Los pasos a seguir para construir un contrato son los siguientes:

1. Identificar las operaciones del sistema a partir de los Diagramas de Secuencia del Sistema.
2. Para cada operacin del sistema construir un contrato.
3. Empezar escribiendo el apartado de Responsabilidades, describiendo informalmente el
propsito de la operacin. Este es el apartado ms importante del contrato.

4. A continuacin rellenar el apartado de Post-condiciones, describiendo declarativamente los

cambios de estado que sufren los objetos en el Modelo Conceptual. Puede ser que este
apartado quede vaco si no cambia el valor de ningn dato de los maneja el sistema (por
ejemplo en una operacin del sistema que tan solo se encarga de sacar por pantalla algo al
usuario).

5. Para describir las post-condiciones, usar las siguientes categoras:

Creacin y borrado de instancias.
Modificacin de atributos.
Asociaciones formadas y retiradas.
6. Completar el resto de apartados en su caso.

POST-CONDICIONES.
Las post-condiciones se basan en el Modelo Conceptual, en los cambios que
sufren los elementos del mismo una vez se ha realizado la operacin.
Es mejor usar el tiempo pasado o el pretrito perfecto al redactar una postcondicin, para enfatizar que se trata de declaraciones sobre un cambio en el
estado que ya ha pasado. Por ejemplo es mejor decir se ha creado una
Sesin que decir crear una Sesin.
Cuando se ha creado un objeto, lo normal es que se haya asociado a algn otro
objeto ya existente, porque si no queda aislado del resto del sistema. Por tanto,
al escribir las postcondiciones hay que acordarse de aadir asociaciones a los
objetos creados. Olvidar incluir estas asociaciones es el fallo ms comn
cometido al escribir las post-condiciones de un contrato.

DIAGRAMAS DE ESTADOS
Se puede aplicar un Diagrama de Estados al comportamiento de los siguientes elementos:

- Una clase software.

- Un concepto.
- Un caso de uso.
En la fase de Anlisis slo se hara para los dos ltimos tipos de elemento, pues una clase software
pertenece al Diagrama de Clases de Diseo.
Puesto que el sistema entero puede ser representado por un concepto, tambin se puede modelar
el comportamiento del sistema completo mediante un Diagrama de Estados.
La utilidad de un Diagrama de Estados en el anlisis reside en mostrar la secuencia permitida de
eventos externos que pueden ser reconocidos y tratados por el sistema. Por ejemplo, no se puede
insertar una tarjeta en un cajero automtico si se est en el transcurso de una operacin.
Para los casos de uso complejos se puede construir un Diagrama de Estados. El Diagrama de
Estados del sistema sera una combinacin de los diagramas de todos los casos de uso.
El uso de Diagramas de Estados es opcional. Tan solo los usaremos cuando consideremos que nos
ayudan a expresar mejor el comportamiento del elemento descrito.

DESARROLLO ORIENTADO A OBJETOS

FASE DE CONSTRUCCION: FASE DE DISEO

FASE DE DISEO
En la fase de Diseo se crea una solucin a nivel lgico para
satisfacer los requisitos, basndose en el conocimiento reunido
en la fase de Anlisis.

ACTIVIDADES.
Las actividades que se realizan en la etapa de Diseo son las siguientes: 1.
Definir los Casos de Uso Reales.
2. Definir Informes e Interfaz de Usuario.
3. Refinar la Arquitectura del Sistema.
4. Definir los Diagramas de Interaccin.
5. Definir el Diagrama de Clases de Diseo. (en paralelo con los Diagramas de
Interaccin).
6. Definir el Esquema de Base de Datos.
El paso de Refinar la Arquitectura del Sistema no tiene por qu realizarse en la
posicin 3, puede realizarse antes o despus.

CASOS DE USO REALES.

Un Caso de Uso Real describe el diseo real del caso de uso
segn una tecnologa concreta de entrada y de salida y su
implementacin. Si el caso de uso implica una interfaz de
usuario, el caso de uso real incluir bocetos de las ventanas y
detalles de la interaccin a bajo nivel con los widgets (botn,
lista seleccionable, campo editable, etc.) de la ventana.
Como alternativa a la creacin de los Casos de Uso Reales, el
desarrollador puede crear bocetos de la interfaz en papel, y
dejar los detalles para la fase de implementacin.

DIAGRAMAS DE COLABORACIN.
Los Diagramas de Interaccin muestran el intercambio de mensajes entre instancias del
modelo de clases para cumplir las post-condiciones establecidas en un contrato.
Hay dos clases de Diagramas de Interaccin:

1. Diagramas de Colaboracin.
2. Diagramas de Secuencia.
De entre ambos tipos se prefieren los Diagramas de Colaboracin por su expresividad y por su
economa espacial (una interaccin compleja puede ser muy larga en un Diagrama de
Secuencia).
La creacin de los Diagramas de Colaboracin de un sistema es una de las actividades ms
importantes en el desarrollo orientado a objetos, pues al construirlos se toman unas decisiones
clave acerca del funcionamiento del futuro sistema. La creacin de estos diagramas, por tanto,
debera ocupar un porcentaje significativo en el esfuerzo dedicado al proyecto entero.

CREACIN DE DIAGRAMAS DE
COLABORACIN.
Para crear los Diagramas de Colaboracin se pueden seguir los siguientes consejos:
Crear un diagrama separado para cada operacin del sistema en desarrollo en el ciclo
de desarrollo actual.

- Para cada evento del sistema, hacer un diagrama con l como mensaje inicial.
Si el diagrama se complica, dividirlo en diagramas ms pequeos.
Usando los apartados de responsabilidades y de post-condiciones del contrato de
operacin, y la descripcin del caso de uso como punto de partida, disear un sistema
de objetos que interaccionan para llevar a cabo las tareas requeridas.
La capacidad de realizar una buena asignacin de responsabilidades a los distintos
objetos es una habilidad clave, y se va adquiriendo segn aumenta la experiencia en el
desarrollo orientado a objetos.

RESPONSABILIDAD.
Definen responsabilidad como un contrato u obligacin de una clase o tipo. Las
responsabilidades estn ligadas a las obligaciones de un objeto en cuanto a su
comportamiento. Bsicamente, estas responsabilidades son de los dos siguientes tipos:
Conocer:

- Conocer datos privados encapsulados.

- Conocer los objetos relacionados.
- Conocer las cosas que puede calcular o derivar.
Hacer: q Hacer algo l mismo.

- Iniciar una accin en otros objetos.

- Controlar y coordinar actividades en otros objetos.

RESPONSABILIDAD.
Por ejemplo, puedo decir que un Recibo es responsable de
imprimirse (tipo hacer), o que una Transaccin es
responsable de saber su fecha (tipo conocer). Las
responsabilidades de tipo conocer se pueden inferir
normalmente del Modelo Conceptual. Una responsabilidad no
es lo mismo que un mtodo, pero los mtodos se implementan
para satisfacer responsabilidades.

DIAGRAMA DE CLASES DE DISEO.

Al construir los Diagramas de Colaboracin se van usando
clases procedentes del Modelo Conceptual, junto con otras
creadas para encargarse de responsabilidades especficas. El
conjunto de todas las clases usadas, junto con sus relaciones,
forma el Diagrama de Clases de Diseo.

DIAGRAMA DE CLASES DE DISEO.

Un Diagrama de Clases de Diseo muestra la especificacin para las clases
software de una aplicacin.
Incluye la siguiente informacin:
Clases, asociaciones y atributos.
Interfaces, con sus operaciones y constantes.
Mtodos.
Navegabilidad.
Dependencias.
A diferencia del Modelo Conceptual, un Diagrama de Clases de Diseo muestra
definiciones de entidades software ms que conceptos del mundo real. En la
figura se muestra un ejemplo de Diagrama de Clases de Diseo sencillo.

RELACIONES DE DEPENDENCIA PARA

REPRESENTAR VISIBILIDAD ENTRE
CLASES.
Cuando una clase conoce a otra por un medio que no es a travs de un
atributo (una asociacin con la navegabilidad adecuada), entonces es
preciso indicar esta situacin por medio de una dependencia.
Un objeto debe conocer a otro para poder llamar a uno de sus mtodos, se
dice entonces que el primer objeto tiene visibilidad sobre el segundo.
La visibilidad ms directa es por medio de atributo, cuando hay una
asociacin entre ambas clases y se puede navegar de la primera a la
segunda (un atributo de la primera es un puntero a un objeto de la
segunda). Hay otros tres tipos de visibilidad que hay que representar en el
diagrama de clases mediante relaciones de dependencia:

RELACIONES DE DEPENDENCIA PARA

REPRESENTAR VISIBILIDAD ENTRE
CLASES.
- Parmetro: Cuando a un mtodo de una clase se le pasa como parmetro un objeto
de otra clase, se dice que la primera tiene visibilidad de parmetro sobre la segunda.
La relacin de dependencia entre ambas clases se etiqueta con el estereotipo
<<parametro>> (<<parameter>> en ingls).

- Local: Cuando en un mtodo de una clase se define una variable local que es un
objeto de otra clase, se dice que la primera tiene visibilidad local sobre la segunda.
La relacin de dependencia entre ambas clases se etiqueta con el estereotipo
<<local>>.

- Global: Cuando hay una variable global en el sistema, y un mtodo de una clase

llama a un mtodo de esa variable global, se dice que la clase tiene visibilidad global
sobre la clase a la que pertenece la instancia que es una variable global. La relacin
de dependencia entre ambas clases se etiqueta con el estereotipo <<global>>.

RELACIONES DE DEPENDENCIA PARA

REPRESENTAR VISIBILIDAD ENTRE
CLASES.
No es necesario representar la relacin de dependencia entre clases que
ya estn relacionadas por medio de una asociacin, que se trata de una
dependencia ms fuerte. Las relaciones de dependencia se incluyen tan
solo para conocer qu elementos hay que revisar cuando se realiza un
cambio en el diseo de un elemento del sistema.

a) Solitario: Caso Particular de Visibilidad global

El uso de variables globales no se aconseja por los efectos laterales que se
pueden presentar, pero hay un caso en el que s hay cierta globalidad:
las clases que slo van a tener una instancia. Suele tratarse de clases que
se han creado en el diseo, que no aparecan en el Modelo Conceptual.

RELACIONES DE DEPENDENCIA PARA

REPRESENTAR VISIBILIDAD ENTRE
CLASES.
Varias clases de nuestro sistema pueden querer llamar a los mtodos de la
nica instancia de una clase de ese tipo, entonces s se considera que es
beneficioso que se pueda acceder a esa instancia como un valor accesible
de forma global. Una solucin elegante para este caso se implementa
mediante un mtodo de clase para obtener esa nica instancia (los
mtodos de clase los permiten algunos lenguajes orientados a objetos, por
ejemplo Java), en vez de definirla directamente como una variable global.
Para indicar que una clase slo va a tener una instancia, se etiqueta la
clase con el estereotipo <<solitario>> (<<singleton>> en ingls), y las
relaciones de dependencia entre las clases que la usan y se etiquetan
tambin <<solitario>> en vez de <<global>>.

CONSTRUCCIN DE UN DIAGRAMA DE
CLASES DE DISEO.
Para crear un Diagrama de Clases de Diseo se puede seguir la siguiente estrategia:

1.

Identificar todas las clases participantes en la solucin software. Esto se lleva a cabo
analizando los Diagramas de Interaccin.

2.
3.
4.
5.
6.
7.

Representarlas en un diagrama de clases.

8.

Aadir relaciones de dependencia para indicar visibilidad no correspondiente a atributos.

Duplicar los atributos que aparezcan en los conceptos asociados del Modelo Conceptual.
Aadir los mtodos, segn aparecen en los Diagramas de Interaccin.
Aadir informacin de tipo a los atributos y mtodos.
Aadir las asociaciones necesarias para soportar la visibilidad de atributos requerida.
Aadir flechas de navegabilidad a las asociaciones para indicar la direccin de visibilidad
de los atributos.

CONSTRUCCIN DE UN DIAGRAMA DE
CLASES DE DISEO.
No todas las clases que aparecan en el Modelo Conceptual tienen por qu
aparecer en el Diagrama de Clases de Diseo. De hecho, tan solo se incluirn
aquellas clases que tengan inters en cuanto a que se les ha asignado algn tipo
de responsabilidad en el diseo de la interaccin del sistema. No hay, por tanto,
un transicin directa entre el Modelo Conceptual y el Diagrama de Clases de
Diseo, debido a que ambos se basan en enfoques completamente distintos: el
primero en comprensin de un dominio, y el segundo en una solucin software.
En la fase de Diseo se aaden los detalles referentes al lenguaje de
programacin que se vaya a usar. Por ejemplo, los tipos de los atributos y
parmetros se expresarn segn la sintaxis del lenguaje de implementacin
escogido.

NAVEGABILIDAD.
La navegabilidad es una propiedad de un rol (un extremo de una asociacin) que
indica que es posible navegar unidireccionalmente a travs de la asociacin,
desde objetos de la clase origen a objetos de la clase destino. Se representa en
UML mediante una flecha.
La navegabilidad implica visibilidad, normalmente visibilidad por medio de un
atributo en la clase origen. En la implementacin se traducir en la clase origen
como un atributo que sea una referencia a la clase destino.
Las asociaciones que aparezcan en el Diagrama de Clases deben cumplir una
funcin, deben ser necesarias, si no es as deben eliminarse.
Las situaciones ms comunes en las que parece que se necesita definir una
asociacin con navegabilidad de A a B son:

NAVEGABILIDAD.
A enva un mensaje a B.
A crea una instancia B.
A necesita mantener una conexin con B.

VISIBILIDAD DE ATRIBUTOS Y MTODOS.

Los atributos y los mtodos deben tener una visibilidad
asignada, que puede ser:
+ Visibilidad pblica.
# Visibilidad protegida.

- Visibilidad privada.
Tambin puede ser necesario incluir valores por defecto, y
todos los detalles ya cercanos a la implementacin que sean
necesarios para completar el Diagrama de Clases.

OTROS ASPECTOS EN EL DISEO DEL

SISTEMA.
En los puntos anteriores se ha hablado de decisiones de diseo a un nivel de
granularidad fina, con las clases y objetos como unidades de decisin. En el
diseo de un sistema es necesario tambin tomar decisiones a un nivel ms alto
sobre la descomposicin de un sistema en subsistemas y sobre la arquitectura
del sistema.
Esta parte del Diseo es lo que se denomina Diseo del Sistema. Estas
decisiones no se toman de forma distinta en un desarrollo orientado a objetos a
como se llevan a cabo en un desarrollo tradicional. Por tanto, no se va a entrar
en este documento en cmo se realiza esta actividad.
S hay que tener en cuenta que las posibles divisiones en subsistemas tienen
que hacerse en base a las clases definidas en el Diagrama de Clases del Diseo.

FASES DE IMPLEMENTACIN Y PRUEBAS

Una vez se tiene completo el Diagrama de Clases de Diseo,
se pasa a la implementacin en el lenguaje de programacin
elegido. El programa obtenido se depura y prueba, y ya se
tiene una parte del sistema funcionando que se puede probar
con los futuros usuarios, e incluso poner en produccin si se ha
planificado una instalacin gradual. Una vez se tiene una
versin estable se pasa al siguiente ciclo de desarrollo para
incrementar el sistema con los casos de uso asignados a tal
ciclo.

BIBLIOGRAFA.
El Lenguaje Unificado de Modelado. G. Booch, J. Rumbaugh, I.
Jacobson. Addison Wesley Iberoamericana, 1999.

The UML Specification Document. G. Booch, I. Jacobson and J.

Rumbaugh. Rational Software Corp., 2000.

UML

Resource
Center.
http://www.rational.com/uml/

Rational

Software.

INGENIERIA EN SISTEMAS
COMPUTACIONALES

ING. JOSE ADAN GUEVARA ALBORES