Analisis y Diseño de Sistem As - Senati

SERVICIO NACIONAL DE ADIESTRAMIENTO EN TRABAJO INDUSTRIAL
DESARROLLO DE
SOFTWARE
MANUAL DE APRENDIZAJE
ANLISIS Y DISEO DE
SISTEMAS
CDIGO: 89001638
Profesional Tcnico
ANLISIS Y DISEO DE SISTEMAS
TAREA 01: ENTENDER LA CONCEPTUALIZACIN DE UN

SISTEMA, SISTEMA DE INFORMACIN.
En esta tarea trataremos las siguientes operaciones:
Entender los conceptos de elementos o componentes de un sistema.
Reconocer las caractersticas de los sistemas y los tipos de sistemas.
EQUIPOS Y MATERIALES:
Computadora con microprocesadores core 2 Duo o de mayor capacidad.

Sistema operativo Windows y la aplicacin de Wampserver.
Acceso a internet.
OPERACIN:
Instalacin de Rational Rose Enterprise.
La aplicacin de Rational Rose Enterprise es un software desarrollado por IBM
que tiene como finalidad brindar una herramienta y un lenguaje de modelado
comn para simplificar el entorno de trabajo y permitir una creacin ms rpida
de software de calidad, lo que las organizaciones necesitan actualmente.
1. Ingresar a la carpeta que contiene los archivos de instalacin, por lo general
recibe el nombre de Rational Rose Enterprise 20017.
2. Ubique el archivo que inicia la instalacin y haga doble clic Setup.exe.
3. Haga clic en la opcin Install IBM Rational Rose Enterprise Edition.
Haga clic en la opcin Install

IBM Rational Rose
Enterprise Edition.
4. Se muestra la pantalla de bienvenida, haga clic en el botn Siguiente.

ESCUELA DE TECNOLOGAS DE LA INFORMACIN
5. Seleccione la opcin Desktop installation fron CD imagem y luego haga

clic en el botn Siguiente.
6. En el siguiente pantallazo haga clic en Next, y se mostrar un mensaje de

advertencia para la instalacin. Se recomiendo desactivar el antivirus para
realizar la instalacin.
Haga clic en el botn Next.
7. Se mostrar la licencia. Haga clic en el botn Aceptar.

8. Seleccione la ubicacin de los archivos de instalacin y haga clic en botn
Next
9. Elija la opcin Rose Ada Addin y luego haga clic en la segundo opcin.
10. Haga clic en Next y por ltimo en el botn Install.

11. Activar la opcin Import a Rational License File y haga clic en Siguiente.
12. Haga clic en Browser para seleccionar el archivo de la licencia.

13. Pantalla de inicio del Rational Rose.
Interfaz de Rational Rose.

1. Ingrese a la aplicacin Rational Rose.
2. En la primera pantalla haga clic en el botn Cancel. La primera pantalla
tiene la tpica estructura de una venta de Microsoft Windows.

Barra de Titulo.
Barra de Mens.
Barra de Herramientas Estandar.
Barra de
Herramientas
rea de
de Diagramas
Navegacin.
Ventana de
diagrama.
rea de Documentacin.
rea de Registro.
Qu sub-elementos se encuentra en el elemento Use Case View?
Instalacin de ArgoUML.
ArgoUML es una aplicacin que cumple con todas la caractersticas de ser un
software Open Source, publicado bajo la licencia de BSD, dicha aplicacin se
ha terminado por convertir en una herramienta necesaria cuando elaboracin
de software se trata, bsicamente fortaleciendo los puntos de anlisis, es por
eso que se suele decir que con la aplicacin se ha llegado al cambio en los
procesos involucrados en el ciclo de vida de desarrollo de software.
1. Ingrese a la siguiente direccin web. http://argouml.tigris.org/.
2. Haga clic en la opcin Dowload para Windows.
3. Luego de generar la descarga. Haga doble clic en el archivo de instalacin.

ArgoUML-0.34-setup.exe.
4. Seleccione el idioma Espaol y luego haga clic en el botn Ok.
5. Se mostrar la pantalla de bienvenida. Haga clic en Siguiente.

6. Seleccione los componentes con los cuales trabajara el ArgoUML, para este
caso, active las dos opciones mostradas en la ventana. Y luego haga clic en
Siguiente.
Activar los dos

componentes.
7. Elija el lugar de instalacin y luego haga clic en siguiente.

10
8. Defina la carpeta del men inicio y haga clic en Instalar.
Asistente de configuracin de ArgoUML.

1. Ingrese a la aplicacin ArgoUML.
2. Haga clic en el men Editar y luego en la opcin Configuracin.
Instalacin de StarUML.
1. Ingrese a la siguiente direccin web http://staruml.sourceforge.net/en/.
2. Haga clic en la opcin Downloads.
11
3. Haga doble clic en el icono staruml-5.0-with-cm, para iniciar la instalacin.

4. En la pantalla de bienvenida elegir el botn Next, luego acepte la licencia
para la aplicacin.
5. Haga doble clic en el acceso directo StarUML, para iniciar la aplicacin.
6. Ubicar el cursos del mouse en el rea de exploracin de modelos y haga clic
en el botn + de la opcin DeploymentModel y luego doble clic en la
opcin Main.
Haga doble clic

en la opcin
Main.
Procedimiento para crear nuevo proyecto:

1. Ingrese a la aplicacin StarUML
2. Seleccione el men File y luego la opcin New Project. Un nuevo proyecto
se crea con el seleccionado por el usuario dependiendo de los perfiles o
marcos pueden ser incluidos.
12
Haga clic en la opcin New Project.
Opciones para administrar el Proyecto
Qu otras opciones tiene el Men File y cules son sus combinaciones de

tecla?
N
Opcin
Combinacin de teclas
New Project
Ctrl + N
New Project Approach
Ctrl + I
3
4
5
6
7
8
9
10
11
12
13
14
Procedimiento para crear nuevo proyecto de la seleccin de la caja de
dilogo.
1. Ingrese a la aplicacin StarUML
2. Una lista de los enfoques disponibles se mostrar en el cuadro de dilogo
Seleccionar Nuevo proyecto.
13
Seleccione uno de la lista y

haga clic en el botn OK.
3. Un nuevo proyecto se crea y se inicializa segn el enfoque seleccionado.
Procedimiento para la apertura de un Proyecto.

1. Ingrese a la aplicacin StarUML.
2. Seleccione el men File y luego la opcin Open.
3. En el cuadro de dilogo Abrir proyecto, seleccione un archivo de proyecto y
haga clic en el botn Abrir. El archivo de proyecto seleccionado se abrir.
Procedimiento para guardar el proyecto:

2. Seleccione el men File y luego la opcin Save as.
3. Si no se ha especificado el nombre de archivo de proyecto, aparecer el
cuadro de dilogo Guardar proyecto, e ingrese el nombre de archivo y haga
clic en el botn Guardar.
Importancia de un Framework.
2. Seleccione el men File y luego la opcin Import.
Haga clic en la opcin Import y luego en la

opcin Framework.
14

En el cuadro de dilogo Importar Framework, seleccione un marco para
importar y haga clic en Ok.
Aparecer el cuadro de dilogo Seleccionar

elemento,
para
determinar
qu
elemento
contendr.
FUNDAMENTO TERICO:
Entender los conceptos de elementos o componentes de un sistema.
Hoy en da hablar de sistemas es bsicamente enfocarse a un conjunto de
elementos que tienen que poseer algunas caractersticas para poder ser
catalogado como tal, es por ello que la gente asocia mucho la palabra sistemas
a las computadoras, es cierto un computadora es un sistema pero no es nico,
existen a nuestro alrededor muchos sistemas, pero como nos somos capaces
de identificarlos cometemos una apreciacin errnea de ello.
Es por eso que se recomienda trabajar teniendo en cuenta los muchos
aspectos del enfoque de sistemas y cmo se relacionan con la ya famosa
teora general de sistemas (TGS). En pocas palabras se tiene que tener claro lo
que realmente es TGS ya que esta proporciona los fundamentos tericos.
Los diferentes aspectos del enfoque de sistemas.
Metodolo
ga de
diseo.
Marco de
trabajo
conceptu
al comn.
Nueva
clase de
mtodo
cientfico.
Teora de
organizaci
ones.
Direccin
por
sistemas.
Mtodo
relaciona
do
15

1. Una metodologa de diseo.
Hoy en da la gran mayora de personas que tienen un puesto de trabajo en
organizaciones de sector pblico, industrial, educativo, se dan con la
complejidad de encontrar la forma ms eficaz de poder solucionar tus
problemas, esto quiere decir que no encuentra el camino correcto o el ms
adecuado para dar con una solucin feliz a dicho problema. Todo ello genera
que estas personas se vean atormentadas por bandos que los urgen para que
observen todos los aspectos del problema y al mismo tiempo incorporen sus
opiniones en el diseo final del sistema en cuestin. No importa cun pequeo
sea el impacto que una decisin tiene en uno o varios sistemas, en donde por
sistema se entiende no slo la organizacin de una rea, sino tambin la
funcin y todos los usuario y componentes de ste. Es por ello que primera se
llegar a la conclusin de que existen sistemas dentro de los sistemas.
La organizacin entiende que su personal es parte de un sistema potencial
humano que a su vez pertenece a un sistema de trabajo y este terminara
adhirindose y a un sistema operativo, y de esta forma poder ir encontrado
otros sistemas inmersos dentro de otros sistemas.
Pero eso no solo queda ah, no basta con reconocer otro un sistema dentro de
otro, tambin es importante recomer la relacin que se tienen entre ellos ya que
un movimiento en uno de los sistemas puede afectar y hacer que ste mismo
se perciba en los dems. En conclusin los sistemas deben planearse, no debe
permitirse que slo "sucedan".
2. Un marco de trabajo conceptual comn.
De todas formas los sistemas mantienen caractersticas en comn por ms que
tengan objetivos distintos.
Propiedades y estructuras, Uno de los objetivos del enfoque de sistemas,
es buscar similitudes de estructura y de propiedades, as como fenmenos
comunes, esto quiere decir que el enfoque de sistemas busca
generalizaciones que se refieran a la forma en que estn organizados los
sistemas, a los medios por los cuales los sistemas reciben, almacenan,
procesan y recuperan informacin, y a la forma en que funcionan; es decir, la
forma en que se comportan, responden y se adaptan ante diferentes
entradas del medio.
Mtodos de solucin y modelos, En este caso el enfoque de sistemas
busca encontrar la relacin de mtodos de solucin, a fin de extender su
dominio de aplicacin y facilitar la comprensin de nuevos fenmenos.
Siempre que sea posible, se debe combatir la especializacin y
compartimentalizacin.
16

Dilemas y paradojas, Los sistemas no trata problemas metodolgicos. Tan
pronto como se adopta el enfoque de sistemas, aparecen los siguientes
problemas de dualismo o dualidad.
Simplicidad contra complejidad. Se tiene que partir de la premisa que no
se puede hacer frente a problemas complejos, esto quiere decir que se debe
de optar por emplear versiones ms simples. Al simplificar las soluciones,
stas pierden realismo. Por tanto se llega al punto en la que uno se
encuentra en un dilema dividido entre la incapacidad de resolver problemas
complejos y la falta de aplicabilidad de soluciones obtenidas de modelos
simples.
Optimizacin y suboptimizacin. Se puede optimizar sistemas cerrados,
como son los modelos en los cuales se conocen todos los supuestos y
condiciones limitantes. Las situaciones de la vida real son sistemas abiertos,
porciones que pueden, a lo mejor, estar parcialmente optimizadas. Adems,
optimizar los subsistemas no garantiza que el sistema total ptimo se logre.
Idealismo contra realismo. Se tiene que entender que no se puede
alcanzar lo ptimo, la solucin claramente ideal. Si va a tener lugar la
implantacin, se deben aceptar versiones ms realistas de lo ptimo.
Acuerdo y consenso. La planeacin requiere que todos los participantes
contribuyan a las soluciones de los sistemas y su implantacin. Para obtener
tales resultados se necesita un consenso que es difcil de lograr cuando se
premia la individualidad e independencia.
3. Nueva clase de mtodo cientfico.
El mundo est hecho de entidades fsicas y de sistemas vivientes. Hay un
conocimiento creciente de que, en tanto estas dos clases de sistemas
comparten muchas propiedades, sus atributos respectivos son tan diferentes
que aplicar los mismos mtodos a ambos, conduce a grandes conceptos falsos
y errores. El mtodo cientfico que nos ha sido de gran utilidad para explicar el
mundo fsico debe complementarse con nuevos mtodos que pueden explicar
el fenmeno de los sistemas vivientes. El enfoque de sistemas y la teora
general de sistemas de la cual se deriva, estn animando el desarrollo de una
nueva clase de mtodo cientfico abarcado en el paradigma de sistemas, que
puede enfrentarse con procesos como la vida, muerte, nacimiento, evolucin,
adaptacin, aprendizaje, motivacin e interaccin.
4. Una teora de organizaciones.
El enfoque de sistemas tiene que ver, en gran parte, con las organizaciones. El
enfoque de sistemas otorga una nueva forma de pensamiento a las
organizaciones que complementan las escuelas previas de la teora de la
organizacin. ste busca unir el punto de vista conductual con el estrictamente
mecnico y considerar la organizacin como un todo integrado, cuyo objetivo
17

sea lograr la eficacia total del sistema, adems de armonizar los objetivos en
conflicto de sus componentes. Esta integracin demanda nuevas formas de
organizacin formal, como las que se refieren a los conceptos de proyecto de
administracin y programa de presupuesto con estructuras horizontales
superpuestas sobre las tradicionales lneas de autoridad verticales.
5. El enfoque de sistemas: direccin por sistemas.
Las grandes organizaciones, como por ejemplo, las corporaciones
multinacionales, enfrentan problemas cuyas ramificaciones e implicaciones
requieren que stos sean tratados en una forma integral, a fin de competir con
sus complejidades e interdependencias. Tales organizaciones deben tener la
habilidad de "planear, organizar y administrar la tecnologa eficazmente.
Deben aplicar el enfoque de sistemas y el paradigma de sistemas a la solucin
de sus problemas, un enfoque que requiere que las funciones de sistemas, se
apliquen a la direccin de los problemas complejos de la organizacin. Al tratar
cada situacin, sta debe considerarse en el contexto y marco de trabajo de la
organizacin tomada como un "sistema", un todo complejo en el cual el director
busca la eficacia total de la organizacin.
6. Mtodos relacionados.
Creemos que existe una distincin entre lo que algunos llaman anlisis de
sistemas, y lo que aqu llamamos enfoque de sistemas. Muchos tratados de
anlisis de sistemas se han dedicado al estudio de problemas relacionados a
los sistemas de informacin administrativa, sistemas de procesamiento de
datos, sistemas de decisin, sistemas de negocios, y similares.
El enfoque de sistemas, como se le concibe en este texto, es bastante general
y no se interesa en un tipo particular de sistema. Algunas presentaciones del
anlisis de sistemas slo enfatizan el aspecto metodolgico de este campo.
Nuestro tratado sobre el enfoque de sistemas intenta estudiar las herramientas
del oficio, as como el fundamento conceptual y filosfico de la teora. La
metodologa de Checkland, llamada anlisis aplicado de sistemas, es ms
parecida a nuestra teora general de sistemas aplicada que lo que pudiera
parecer que implica su nombre.
La ingeniera de sistemas y la eficiencia de costos tambin son nombres
relacionados al enfoque de sistemas. Todos ellos se derivan de una fuente
comn, y la literatura de estos campos est ntimamente relacionada con el de
anlisis de sistemas. No se debe pasar por alto los lazos que unen el enfoque
de sistemas con la investigacin de operaciones y con la ciencia de la
administracin. Muchos artculos de esos campos pueden considerarse del
dominio de la teora general de sistemas. Estas tres jvenes disciplinas an se
18

encuentran en estado de flujo. Mantienen intereses comunes y poseen races
comunes. Es concebible que algn da una nueva disciplina que lleve uno de
los nombres arriba citados, o alguno nuevo, abarcar a las dems. Hasta este
momento, la teora general de sistemas ha proporcionado el mpetu hacia esa
direccin.
Reconocer las caractersticas de los sistemas y los tipos de sistemas.
Las caractersticas de los sistemas dependen de su dominio. El dominio de los
sistemas es el campo sobre el cual estn trabajando. De acuerdo a ello se
puedo encontrar la siguiente clasificacin:
1. Sistemas vivientes y no vivientes.
En este sentido se hace mencin de forma especfica aquellos sistemas que
poseen funciones biolgicas como son el nacimiento, la muerte y la
reproduccin.
2. Sistemas abstractos y concretos.
De acuerdo con Ackoff, "un sistema abstracto es aquel en que lodos sus
elementos son conceptos. Un sistema concreto es aquel en el que por lo
menos dos de sus elementos son objetos".
Para entrar un poco ms al detalle se puede entender que un sistema concreto
dicho como tal, los elementos terminan siendo objetos y en otras casos sujetos
3. Sistemas abiertos y cerrados.
Los conceptos de sistemas abierto y cerrado introducen una diferenciacin muy
importante entre ellos y radica en la influencia ya que un sistema cerrado es un
sistema que no se deja influencia por otro sistema es por eso su nombre, caso
contrario con un sistema abierto, ya que dicho sistema por ser de tipo abierto
posee otros sistemas con los cuales se relaciona, intercambia y comunica.
La distincin entre sistemas abierto y cerrado, es fundamental para la
comprensin de los principios bsicos de la teora general de sistemas.
Cualquier consideracin de sistemas abiertos como sistemas cerrados, en los
que pasa inadvertido el medio, trae consigo graves riesgos que deben
comprenderse totalmente.
Tomando los datos de la primera caractersticas se puede llegar a la conclusin
que los sistemas vivientes son sistemas abiertos.
Los sistemas cerrados se mueven a un estado esttico de equilibrio que es
nicamente dependiente de las condiciones iniciales del sistema. S cambian
las condiciones iniciales, cambiar el estado estable final.
19

4. Entropa, incertidumbre e informacin.
La entropa es tomada de la termodinmica, para efectos de medir el desorden
dentro de los sistemas.
Un sistema muestra una alta o baja entropa (variedad, incertidumbre,
desorden). Reducir la entropa de un sistema, es reducir la cantidad de
incertidumbre que prevalece. La incertidumbre se disminuye al obtenerse
informacin. La informacin, en el sentido de la teora sobre la informacin,
posee un significado especial que est ligado al nmero de alternativas en el
sistema.
Estos conceptos pueden utilizarse para caracterizar los sistemas vivientes y no
vivientes. Los sistemas no vivientes (considerados generalmente como
cerrados), tienden a moverse hacia condiciones de mayor desorden y entropa.
Los sistemas vivientes (y por tanto abiertos), se caracterizan como resistentes
a la tendencia hacia el desorden y se dirigen hacia mayores niveles de orden.
5. Complejidad organizada y no organizada.
Los sistemas vivientes son sistemas de complejidad organizada, en tanto que
los sistemas no vivientes muestran propiedades ya sea de simplicidad
organizada o complejidad no organizada.
En contraste a la simplicidad organizada.
Se reconoce al sistema que muestran una complejidad catica desorganizada.
Los sistemas vivientes muestran un tipo de conducta que no puede explicarse
ni en trminos de leyes dinmicas resultantes de la suma de las propiedades
de las partes, ni por el resultado probable de un nmero infinito de
interacciones como podra encontrarse, respectivamente, en sistemas de
simplicidad organizada y de complejidad no organizada. Los sistemas vivientes
generalmente muestran una clase diferente de complejidad llamada
complejidad organizada.
6. Propsito y conducta con un propsito.
La conducta con un propsito e intencional es la que est dirigida hacia el logro
de un objetivo, un estado final. El objetivo hacia el cual se esfuerzan los
sistemas, tiene una consecuencia ms inmediata que el concepto rechazado
de la antigua teleologa. La conducta sin un propsito es la que no est dirigida
hacia el logro de un objetivo.
Los criterios para distinguir entre una conducta con propsito y sin ste,
pueden elaborarse como sigue:
Para que tenga lugar la conducta con propsito, el objeto al cual se atribuye la
conducta debe ser parte del sistema.
La conducta con propsito debe estar dirigida hacia un objetivo.
Debe haber una relacin recproca entre el sistema y su medio.
La conducta debe estar relacionada o acoplada con el medio, del cual debe
recibir y registrar seales que indiquen si la conducta progresa hacia el
objetivo.
20

Un sistema con un propsito debe siempre mostrar una eleccin de cursos
alternos de accin.
La eleccin de una conducta debe conducir a un producto final o resultado.
Deben distinguirse las condiciones suficientes y necesarias para un evento. Las
condiciones suficientes nos capacitan para predecir que ste ocurra, en tanto
que las condiciones necesarias nos descubren elementos en la naturaleza que
son responsables de l.
7. Retroalimentacin.
Vimos que los sistemas no vivientes pueden dirigirse con retro alimentacin
hacia una salida especfica mediante la regulacin de la conducta con un
mecanismo controlado. Este mecanismo se basa en el principio de
retroalimentar una porcin de la salida, para controlar la entrada. Podemos
tener una retroalimentacin positiva, en la cual la multiplicacin entre la entrada
y la salida es tal que la salida aumenta con incrementos en la entrada, o una
retroalimentacin negativa, en la cual la salida disminuye al aumentar la
entrada. La retroalimentacin positiva generalmente conduce a la inestabilidad
de sistemas, en tanto que la retroalimentacin negativa se usa para
proporcionar un control de sistema estable. Las condiciones para un control
estable e inestable a travs de una retroalimentacin positiva y negativa han
sido resueltas matemticamente y estn en la base de la teora de los
servomecanismos, que trata con dispositivos por los cuales los grandes
sistemas pueden controlarse automticamente. La aplicacin de los principios
de control de la retroalimentacin a sistemas vivientes no es tan integra como
la que trata con los sistemas no vivientes. En el estudio sobre la teora de
control, en el captulo 18, tendremos un anlisis completo de estos problemas.
Ser suficiente en este punto, enfatizar la importancia que mantiene el
concepto de control para la teora de sistemas. El cientfico social est
primordialmente interesado en organizaciones o sistemas vivientes, sistemas
que tienen un propsito en el sentido limitado, como se describi en la seccin
anterior. El cientfico social est interesado en dirigir esos sistemas hacia su
objetivo o en proporcionar principios al administrador a fin de que pueda^
controlar los movimientos hacia esos objetivos. En tanto se pueda hacer un
intento para traducir los principios de control y servomecanismos a sistemas
vivientes, su aplicacin ser ms difcil, debido a que las entradas y salidas no
estn tan claramente definidas, como cuando se trata de sistemas no vivientes,
o abstracciones matemticas. A pesar de tales dificultades, esos intentos son
de la mayor importancia para mejorar el desempeo de sistemas que sirven al
ser humano. Tenemos que encontrar principios y procedimientos por los cuales
la organizacin humana pueda lograr el progreso y moverse en direccin a los
objetivos que se ha fijado para s misma.
21

8. Jerarqua en los sistemas.
La jerarqua es un concepto importante que puede utilizarse para representar
el hecho de que los sistemas pueden ordenarse de acuerdo a varios criterios,
uno de los cuales es la complejidad en incremento de la funcin de sus
componentes. Pueden considerarse los siguientes niveles de sistemas.
9. Organizacin.
La organizacin es una caracterstica de sistemas que van ms all de la
complejidad de la estructura. Por tanto, Ackoff define una organizacin como
"un sistema por lo menos parcialmente autocontrolado" que posee las
siguientes caractersticas: Contenido ya que hay una relacin sistemas
hombre-mquina. Estructura porque el sistema debe mostrar la posibilidad de
cursos de accin alternativos, la responsabilidad por la cual puede
diferenciarse con base en funciones (mercadeo, produccin, contabilidad, etc.),
geogrfica, o alguna otra propiedad. Las Comunicaciones desempean un
papel importante en la determinacin de la conducta e interaccin de
subsistemas en la organizacin. Por ltimo la eleccin de toma de decisin ya
que los cursos de accin conduce a resultados que tambin deben ser el objeto
de elecciones entre los participantes.
El estudio anterior es importante, principalmente por la leccin que contiene
para mejorar el conocimiento sobre organizaciones. Es obvio que las
organizaciones son sistemas que muestran rdenes ms elevados que otros
sistemas vivientes; el orden se interpreta en trminos de elevada complejidad y
determinacin consciente para alcanzar objetivos autoestablecidos. Los
sistemas de nivel bajo muestran una complejidad menor y contienen conjuntos
de objetivos impuestos, ya sea por el medio o por otros sistemas. La conciencia
es la que se mueve en direccin al progreso, hacia objetivos autoimpuestos, la
que hace del ser humano un sistema superior en la jerarqua de los sistemas.
Se acredita a la teora general de sistemas, haber separado la teora de los
sistemas no vivientes, los cuales pueden tratarse mediante el enfoque
mecnico, de la teora de los sistemas vivientes, la que requiere un enfoque
diferente del anterior.
22

TAREA 02: DEFINIR EL PROCEDIMIENTO PARA EL ANLISIS Y DISEO
DE SISTEMAS.
Definir los procedimientos para el anlisis y diseo de sistemas.

Sistema operativo Windows y la aplicacin de Wampserver.
Acceso a internet.
OPERACIONES:
Cmo se trabaja en Rational Rose.
3. Haga clic en Use Case View. (incluye todos los actores y todos los
diagramas de caso de uso), luego doble clic en la opcin Main (Cambia la
barra de herramientas).
4. Elija el botn Actor y haga clic en el rea de diseo para ingresar la entidad
y por ultimo ingrese el nombre alumno.
Una entidad es todo aquello que puede ser descrito por sus
atributos.
5. Haga doble clic en la entidad alumno, aparece la ventana de

especificaciones para el actor alumno.
23
6. Ubicar el cursor en la seccin Documentation que cumple la funcin de

ayuda o de recordatorio para las entidades empleadas en el diseo. Para el
ejemplo ingrese el siguiente texto: El alumno es el encargado de realizar
las acciones ms importante dentro del sistema, como realizar la
matricula, estudias y cancelas las pensiones.
7. Haga clic en el botn Ok.
8. Haga clic en la entidad alumno para lograr visualizar la ayuda creada.
Ayuda o
recordatorio para
las entidades
9. Elija el botn Use Case y haga clic en el rea de diseo y por ltimo ingrese
el texto Estudia Software.
24
10. Elija el botn Actor y haga clic en el rea

cliente.
11. Elija el botn Use Case y haga clic en el
ingrese el texto Compra Producto.
12. Elija el botn Actor y haga clic en el rea
Cajero.
13. Elija el botn Use Case y haga clic en el
ingrese el texto Registra Pedidos.
de diseo e ingrese el texto

rea de diseo y por ltimo
de diseo e ingrese el texto
rea de diseo y por ltimo
Los Use Case son en su mayora procedimientos generados

por los actores.
14. Haga clic en el botn Unidirectional Association y realice un arrastre

desde el actor alumnos hacia el use case Estudia Software.
15. Repetir la accin con los actores restantes.
16. Haga doble clic a la entidad Cliente para poder ingresar a las propiedades
de la entidad.
17. Del campo Stereotype seleccione la opcin Business Actor.
25

18. Ubique el cursor en la seccin Documentation que cumple la funcin de
ayuda o de recordatorio El cliente es alguien que es externo a la
organizacin pero que lograr interactuar con la misma, en pocas
palabras se podra decir que el cliente no es parte de la organizacin pero
interacta con ella.
19. Haga clic en el botn Ok.
Tomar en cuenta cmo cambia el actor dentro del diseo.
18. Haga doble clic a la entidad Cajero para poder ingresar a las propiedades
de la entidad.
19. Del campo Stereotype seleccione la opcin Business Worker.
20. Ubique el cursor en la seccin Documentation que cumple la funcin de
ayuda o de recordatorio El cajero representa un rol dentro de la
organizacin en pocas palabras se podra decir que interacta de forma
directa en la organizacin.
21. Clic en el men File y luego en la opcin Save As. Ingrese el nombre y la
ubicacin para el archivo.
22. Haga clic en Guardar.
Cmo se trabaja en ArgoUML.
Asistente de Configuracin.
2. Seleccione el idioma en el Panel de Apariencias.
26
Seleccione la opcin es
(espaol)
Configuracin de atajos.
2. Seleccione la opcin Configuracin de Atajos.
3. Ingresar los primeros atajos hasta completar la tabla.
Accin
Atajo
Por defecto
Guardando el Proyecto.
1. Haga clic en el men Archivo y luego en la opcin Guardar el proyecto
como.
2. Ingrese un nombre y una ubicacin y luego haga clic en Guardar.
27

FUNDAMENTO TERICO:
Definir los procedimientos para el anlisis y diseo de sistemas.
Muchas de las organizaciones no tiene an claro el valor del software dentro de
la misma, y lo ms grave se podra decir que mucho de los departamento de TI
dentro de la organizacin no est preparadas para asumir el papel que deben
cumplir, es por ello que no se entiende mucho el software como un producto, y
es as. Por se debe entender al software, como todo capital, es conocimiento
incorporado y a que el conocimiento originalmente se halla disperso, tcito,
latente e incompleto en gran medida, tal como se habl en la tarea anterior,
pero hay que tener en cuenta que tambin es un aprendizaje social debido a su
caracterstica de sistema abierto.
El software como producto, mejor dicho como cualquier otro producto se
desarrolla mediante procesos. De forma genrica este proceso debe ser un
dilogo en el que el conocimiento tiene la finalidad de convertirse en software.
Ahora este proceso que se debe dar debe generar interaccin entre usuarios y
diseadores, entre usuarios y herramientas cambiantes, y entre diseadores y
herramientas tecnolgicas. Todos estos elementos interactan entre s, gracias
a la herramienta tecnolgica, por otro lado con cada nueva interaccin del
dilogo se genera ms conocimiento til a partir de las personas involucradas.
Pero desde el punto de vista tcnico, qu es exactamente un proceso del
software?, se define proceso del software como una estructura para las
actividades, acciones y tareas que se requieren a fin de construir software de
alta calidad, pero las organizaciones tiene diferentes requerimientos y son
estos lo que termina por convertir la actividad de desarrollo de software en algo
realmente interesante porque se tiene que adaptar los procesos segn las
circunstancias.
Cuando se trabaja en la construccin de un producto o sistema, es importante
ejecutar una serie de pasos predecibles el mapa de carreteras que lo ayuda a
obtener a tiempo un resultado de alta calidad.
Definicin de actividad estructural.

Cuando se define la actividad estructural es bsicamente que un equipo de
software necesitar mucha ms informacin antes de poder ejecutar de manera
apropiada cualquiera de ellas como parte del proceso del software. Por tanto,
sale una pregunta importante: qu trabajos son apropiadas para una actividad
estructural, dados la naturaleza del problema por resolver, las caractersticas
de las personas que hacen el trabajo y los participantes que patrocinan el
proyecto?
28

Para un proyecto de software pequeo solicitado por una persona con
requerimientos sencillos y directos, la actividad de comunicacin tal vez no
incluya algo ms que una llamada telefnica con el participante apropiado.
Entonces, la nica accin necesaria es una conversacin telefnica, y las
tareas del trabajo que engloba son las siguientes:
1. Hacer contacto con el colaborador de la organizacin por va telefnica.
2. Analizar los requerimientos por parte de la organizacin y tomar notas.
3. Organizar las notas por escrito en una formulacin breve de los
requerimientos.
4. Enviar correo electrnico al colaborador de la organizacin para que
examine y apruebe.
Pero hay que dejar en claro que estas cuatro tareas se dan por la naturaleza
del proyecto, esto quiere decir un software para un problema pequeo, esto
termina en un requerimiento corto. Pero en el caso de que el proyecto fuera
considerablemente ms complejo, esto quiere decir muchos colaboradores por
parte de la organizacin y cada uno de ellos con sus propios requerimientos,
esto nos es nada ya que en muchos casos estos requerimientos terminar por
generar conflictos entre los mismos. En un caso as la actividad de
comunicacin puede tener seis acciones distintas: concepcin, indagacin,
elaboracin, negociacin, especificacin y validacin. Cada una de estas
acciones de la ingeniera del software tendr muchas tareas de trabajo y un
nmero grande de diferentes productos finales.
Diseo del Sistema.

En el caso del diseo el objetivo primordial es la definicin de la arquitectura
del sistema y del ambiente tecnolgico que le va a dar soporte, junto con la
especificacin detallada de los componentes del sistema de informacin. Luego
se generan todas las especificaciones de construccin relativas al propio
sistema, as como la descripcin tcnica del plan de pruebas, la definicin de
los requisitos de implantacin y el diseo de los procedimientos de migracin si
fuere el caso y carga inicial,
Definicin de la arquitectura del sistema.

En esta actividad se define la arquitectura general del sistema de informacin,
especificando las distintas particiones fsicas del mismo, la descomposicin
lgica en subsistemas de diseo y la ubicacin de cada subsistema en cada
particin, as como la especificacin detallada de la infraestructura tecnolgica
necesaria para dar soporte al sistema de informacin.
29

El aprisionamiento fsico del sistema de informacin se especifica identificando
los nodos y las comunicaciones entre los mismos, con cierta independencia de
la infraestructura tecnolgica que da soporte a cada nodo.
Con el fin de organizar y facilitar el diseo, se realiza una divisin del sistema
de informacin en subsistemas de diseo, como partes lgicas coherentes y
con interfaces claramente definidas.
Se establece una distincin entre subsistemas especficos del sistema de
informacin (en adelante, subsistemas especficos) y subsistemas de soporte,
con la finalidad de independizar, en la medida de lo posible, las funcionalidades
a cubrir por el sistema de informacin de la infraestructura que le da soporte.
En la mayora de los casos, los subsistemas especficos provienen
directamente de las especificaciones de anlisis y de los subsistemas de
anlisis, mientras que los subsistemas de soporte provienen de la necesidad de
interaccin del sistema de informacin con la infraestructura y con el resto de
los sistemas, as como de la reutilizacin de mdulos o subsistemas ya
existentes en la instalacin.
Debido a que la definicin de los subsistemas de soporte puede exigir la
participacin de distintos perfiles tcnicos, se propone el diseo de ambos tipos
de subsistemas en actividades distintas, aunque en paralelo.
Una vez identificados y definidos los distintos subsistemas de diseo, se
determina su ubicacin ptima de acuerdo a la arquitectura propuesta. La
asignacin de dichos subsistemas a cada nodo permite disponer, en funcin de
la carga de proceso y comunicacin existente entre los nodos, de la
informacin necesaria para realizar una estimacin de las necesidades de
infraestructura tecnolgica que da soporte al sistema de informacin. Este
factor es especialmente crtico en arquitecturas multinivel o cliente/servidor,
donde las comunicaciones son determinantes en el rendimiento final del
sistema.
Se propone crear un catlogo de excepciones en el que se especifiquen las
situaciones anmalas o secundarias en el funcionamiento y ejecucin del
sistema de informacin, y que se ir completando a medida que se avance en
el diseo detallado de los subsistemas
En esta actividad tambin se establecen los requisitos, normas y estndares
originados como consecuencia de la adopcin de una determinada solucin de
arquitectura o infraestructura, que sern aplicables tanto en este proceso como
en la Construccin del Sistema de Informacin (CSI). Se detallan a su vez, de
acuerdo a las particularidades de la arquitectura del sistema propuesta, los
30

requisitos de operacin, seguridad y control, especificando los procedimientos
necesarios para su cumplimiento.
Como resultado de esta actividad, se actualizan los catlogos de requisitos y
normas, y se generan los siguientes productos:
Diseo de la Arquitectura del Sistema, como producto que engloba el
aprisionamiento fsico del sistema de informacin y la descripcin de
subsistemas de diseo.
Entorno Tecnolgico del Sistema, que a su vez comprende la especificacin
del entorno tecnolgico, las restricciones tcnicas y la planificacin de
capacidades.
Catlogo de Excepciones.
Procedimientos de Operacin y Administracin del Sistema.
Procedimientos de Seguridad y Control de Acceso.
Tarea
Definicin de
DSI
Niveles de
Arquitectura
Productos
Diseo de la Arquitectura
del Sistema o
Aprisionamiento. Fsico del
Sistema de Informacin.
Identificacin de
DSI
Requisitos de
Diseo y
DSI
Excepciones
DSI
Normas de Diseo
Diagrama de
Trabajo.
Trabajo.
Catalogacin.
Sesiones de
Catlogo de Normas
Trabajo.
Catalogacin.
y Construccin
Equipo de Arquitectura.
Equipo de Soporte Tcnico.
Equipo de Seguridad.
Despliegue.
Sesiones de
Especificacin de
Estndares y
Representacin-
Catalogacin.
Catlogo de Excepciones.
Participantes
Diagrama de
Sesiones
Catlogo de Requisitos.
Construccin
Especificacin de
Tcnicas y
Prcticas
de
Equipo de Soporte Tcnico
Matricial
Diagrama de
Estructura
DSI
Identificacin de
Subsistemas de
del Sistema o Descripcin
Diseo
de Subsistemas de Diseo
Diagrama de
Inter-accin de
Objetos.
Diagrama de
Equipo de Seguridad
Paquetes.
Diagrama de
Despliegue
31

Entorno Tecnolgico del
Especificacin del
DSI
Entorno
Tecnolgico
Sistema: o Especificacin Sesiones de

del Entorno Tecnolgico o
Trabajo.
Restricciones Tcnicas o Diagrama de

Estimacin
de
Planifi-
Representacin
cacin de Capacidades
Especificacin de
DSI
Requisitos de
Operacin y
Seguridad
Procedimientos de Seguridad y Control de Acceso.

Procedimientos de
Operacin y Adminis-
tracin del Sistema.
1. Definicin de Niveles de Arquitectura.

En esta tarea se describen los niveles de la arquitectura software, mediante la
definicin de las principales particiones fsicas del sistema de informacin,
representadas como nodos y comunicaciones entre nodos.
Se entiende por nodo cada particin fsica o parte significativa del sistema de
informacin, con caractersticas propias de ejecucin o funcin, e incluso de
diseo y construccin.
Para facilitar la comprensin del sistema, se recomienda identificar como nodos
los elementos de infraestructura ms significativos de la arquitectura en la que
se va a implementar el sistema de informacin. Los elementos que se aconseja
especificar son los siguientes:
Gestores de datos.
Tipos de puesto cliente.
Tipos de dispositivos de impresin.
Monitores de teleproceso.
Servidores.
Comunicaciones.
La comunicacin se expresa por una conexin entre nodos, indicando su
carcter bidireccional o unidireccional, con las principales caractersticas de los
protocolos o tipo de mensajes utilizados.
32

La especificacin de los niveles de la arquitectura se realiza con el detalle
suficiente como para permitir un diseo dirigido hacia una solucin concreta. En
general, no es preciso indicar en cada nodo detalles relativos al hardware,
capacidad, rendimiento o configuraciones de tolerancia a fallos, entre otros.
Esta informacin se concreta en la tarea Especificacin del Entorno
Tecnolgico.
Los criterios para disear la arquitectura se obtienen a partir de directrices
tecnolgicas o de integracin, propias de la instalacin, y del catlogo de
requisitos del sistema de informacin. Es necesario tener en cuenta,
especialmente, aspectos relacionados con:
Usuarios: ubicacin, movilidad, concurrencia, nmero, etc.
Datos: variabilidad, volmenes, necesidades de consolidacin, seguridad,
etc. Procesos: distribucin, reutilizacin, concurrencia, carcter crtico, etc.
Productos. (Entrada)
Descripcin General del
Sistema.
Especificacin de Interfaz
de Usuario.
Tcnicas
Diagrama de Despliegue.
En Diseo Estructurado
Matriz de Procesos /
Localizacin Geogrfica.
Descripcin de Interfaz
con otros Sistemas.
Modelo de Procesos.
Modelo Lgico de Datos
Normalizado.
En Diseo Orientado a
Objetos.
Modelo de Casos de Uso.
Especificacin de Casos
de Uso.
Descripcin de
Subsistemas de Anlisis.
Descripcin Interfaces
entre Subsistemas.
Modelo de Clases de
Anlisis.
Anlisis de la Realizacin
de los Casos de Uso.
De salida.
del Sistema o
Particionamiento Fsico
del Sistema de
Informacin.
Prcticas.
Diagrama de
Representacin
Participantes
Equipo de Arquitectura
Equipo de Soporte
Tcnico
Equipo de Seguridad
2. Identificacin de Requisitos de Diseo y Construccin.

En esta tarea se realiza la especificacin de los requisitos que estn
directamente relacionados con la adopcin o diseo de una arquitectura o
33

infraestructura concreta, y que pueden condicionar el diseo o la construccin
del sistema de informacin.
Entre estos requisitos pueden estar los relacionados con lenguajes,
rendimiento de los distintos elementos de la arquitectura, as como criterios de
ubicacin de mdulos y datos en los distintos nodos.
Por tanto, como resultado de esta tarea se actualiza el catlogo de requisitos
elaborado en el proceso Anlisis de Sistemas de Informacin.
del Sistema.
De salida
Prcticas
Sesiones de Trabajo
Catalogacin
Participantes
Equipo de Soporte
Tcnico
3. Especificacin de Excepciones.
El objetivo de esta tarea es la definicin de los comportamientos no habituales
en el sistema, que reflejan situaciones anmalas o secundarias en el
funcionamiento y ejecucin del sistema de informacin. Para ello, se establece
previamente el nivel de especificacin de las mismas, as como los criterios de
catalogacin y clasificacin.
Se propone su catalogacin como ayuda para el diseo del sistema de
informacin y como gua en la especificacin tcnica de las pruebas, al permitir
la generacin de algunos casos de prueba de forma inmediata. Dicho catlogo
se va completando a partir de las actividades correspondientes al diseo
detallado de los subsistemas.
Las excepciones se describen incluyendo, al menos, los siguientes conceptos:
Tipo y descripcin de la excepcin.
Condiciones previas del sistema de informacin.
Elemento afectado (nodo, mdulo, caso de uso).
Respuesta del sistema de informacin.
Elemento asociado a la respuesta esperada del sistema (mdulo, clase,
procedimiento, etc.).
Las excepciones que se proponen como obligatorias son las relacionadas con
el funcionamiento general del sistema de informacin, habitualmente asociadas
a:
Nodos y comunicaciones del aprisionamiento fsico del sistema de
informacin. Este tipo de excepciones tiene lugar cuando no estn
34

disponibles los gestores de bases de datos o los recursos compartidos del
sistema (representados como nodos), cuando se producen fallos en las
comunicaciones entre nodos, etc.
Rangos o valores no vlidos en la entrada de datos, como pueden ser
atributos obligatorios, con formatos especficos, etc.
Se recomienda, segn el nivel de especificacin que se establezca en cada
caso, catalogar tambin las excepciones particulares que se identifiquen en las
actividades del diseo de detalle.
En Diseo
Orientado a
Objetos.
Productos.
(Entrada)
Catlogo de
Requisitos
Diseo de la
Arquitectura del
Sistema
Prcticas
Modelo de Casos
de Uso
Especificacin de
Casos de Uso.
De salida
Catlogo de
Excepciones.
Sesiones de
Trabajo
Catalogacin
Participantes.
Equipo de
Arquitectura
Equipo de
Soporte Tcnico
4. Especificacin de Estndares y Normas de Diseo y Construccin.

En esta tarea se definen los estndares tcnicos y de nomenclatura, normas y
recomendaciones, que generalmente estn relacionados con la adopcin o
diseo de una arquitectura o infraestructura tecnolgica concreta, y que pueden
condicionar el diseo o la construccin del sistema de informacin.
Como resultado de esta tarea, se actualiza el catlogo de normas obtenido en
el proceso Anlisis del Sistema de Informacin.
La informacin recogida en el catlogo se debe tener en cuenta en la
elaboracin de los productos resultantes del diseo y construccin del sistema
de informacin. El catlogo de normas es, por tanto, producto de entrada en
todas las tareas, aunque por sencillez se omite la referencia al mismo.
Estndares y Normativas
de la Instalacin (externo)
Catlogo de Normas.
del Sistema.
De salida
Catlogo de Normas.
Prcticas
Sesiones de Trabajo
Catalogacin
Participantes.
Equipo de Soporte
Tcnico
35

5. Identificacin de Subsistemas de Diseo.
En esta tarea se divide de forma lgica el sistema de informacin en
subsistemas de diseo, con el fin de reducir la complejidad y facilitar el
mantenimiento. Hay que tomar como referencia inicial los subsistemas de
anlisis especificados en el proceso de Anlisis del Sistema de Informacin
(ASI).
La divisin en subsistemas de diseo se puede realizar con una continuidad
directa de los modelos del anlisis, o aplicando nuevos criterios de diseo,
entre los que es posible citar los siguientes:
Facilidad de mantenimiento.
Reutilizacin de elementos del propio sistema o de la instalacin.
Optimizacin de recursos (por ejemplo, lneas de comunicaciones).
Caractersticas de ejecucin (en lnea o por lotes).
Funcionalidad comn.
Aplicacin de mecanismos genricos de diseo al nivel de arquitectura.
Los subsistemas resultantes se califican como especficos o de soporte,
asignando cada subsistema al nodo correspondiente.
Los subsistemas especficos contemplan las funcionalidades propias del
sistema de informacin, mientras que los de soporte cubren servicios comunes,
proporcionando un acceso transparente a los distintos recursos. Estos ltimos
estn relacionados con: Comunicaciones entre subsistemas.
Gestin de
datos
Seguridad y
control de
acceso.
Gestin de
transacciones
Control y
gestin de
errores
Control y
gestin de
errores.
Gestin de
interfaz.
Interaccin con
los recursos
propios del
sistema.
36

La interaccin del sistema de informacin con la infraestructura que le da
soporte, as como con el resto de los sistemas y servicios de la instalacin,
puede originar la necesidad de nuevos subsistemas, mdulos, clases o
servicios no especificados en el anlisis.
La definicin del comportamiento externo de cada subsistema se completa
durante el diseo de detalle con la especificacin de su interfaz, as como con
la dependencia entre subsistemas.
El diseo de detalle de los subsistemas identificados por criterios de
optimizacin y reutilizacin, puede aconsejar la reorganizacin y reubicacin de
los elementos que forman parte de cada subsistema y, a su vez, puede dar
lugar a la identificacin de nuevos subsistemas de soporte. En diseo
estructurado, la descripcin de los subsistemas de diseo que conforman el
sistema de informacin se especifica mediante un diagrama de estructura de
alto nivel, que muestra los distintos subsistemas de que consta el sistema,
incluidos los subsistemas de soporte, junto con la definicin de la interfaz de
cada subsistema.
La ubicacin de subsistemas en nodos y la dependencia entre subsistemas se
especifica por medio de tcnicas matriciales, o bien en lenguaje natural o
pseudocdigo.
Sistema.
del Catlogo de
Requisitos.
Objetos
Localizacin.
con otros Sistemas.
Modelo de Procesos.
Tcnicas
Diagrama de Estructura
Matricial
Diagrama de Interaccin de Objetos
Diagrama de Paquetes
Diagrama de Despliegue
Descripcin de
Subsistemas de Anlisis.
Descripcin Interfaces
entre Subsistemas.
De salida
del Sistema o
Descripcin de
Subsistemas de Diseo.
Participantes
Equipo de Seguridad
6. Especificacin del Entorno Tecnolgico.

En esta tarea se definen en detalle los distintos elementos de la infraestructura
tcnica que dan soporte al sistema de informacin, determinando la
37

implementacin concreta de los nodos y comunicaciones especificados en la
tarea Definicin de Niveles de Arquitectura
Se propone agrupar los elementos de la infraestructura en los siguientes
conceptos:
Hardware: procesadores, unidades de almacenamiento, estaciones de
trabajo, etc.
Software: sistemas operativos, subsistemas, middleware, gestores de bases
de datos, sistemas de ficheros, software de base, herramientas y utilidades
de gestin propias del sistema, etc.
Comunicaciones: diseo de la topologa de la red, protocolos, nodos de red,
etc.
La definicin de los distintos elementos puede generar restricciones tcnicas
que afecten al diseo o construccin del sistema de informacin.
As mismo, se realiza una estimacin de la planificacin de capacidades
(capacity planning) o se especifican los parmetros que Explotacin y Sistemas
precisen para realizar dicha planificacin. Se indican, al menos, las
necesidades previstas de:
Almacenamiento: espacio en disco, espacio en memoria, pautas de
crecimiento y evolucin estimada del sistema de informacin, etc.
Procesamiento: nmero y tipo de procesadores, memoria, etc.
Comunicaciones: lneas, caudal, capacidades de elementos de red, etc.
Para poder determinar la planificacin de capacidades, es necesario conocer
los diseos detallados de los mdulos / clases y escenarios, incluida la
informacin de control en las comunicaciones, as como el diseo fsico de
datos optimizado, productos que se estn generando en paralelo a esta
actividad. Tambin se tienen en cuenta, cuando proceda, las estimaciones de
volmenes de datos propios de la migracin y carga inicial de datos.
Sistema.
Diseo del Sistema de
Informacin
Diseo de la arquitectura
del sistema.
Localizacin Geogrfica.
Plan de Migracin y
Carga Inicial de Datos
Objetos
Plan de Migracin.
Sistema o Especificacin
del Entorno Tecnolgico
o Restricciones Tcnicas
o Estimacin de
Planificacin de
Capacidades
38
Prcticas
Sesiones de Trabajo
Diagrama de Representacin
Participantes
7. Especificacin de Requisitos de Operacin y Seguridad.

El objetivo de esta tarea es definir los procedimientos de seguridad y operacin
necesarios para no comprometer el correcto funcionamiento del sistema y
garantizar el cumplimiento de los niveles de servicios que exigir el sistema en
cuanto a la gestin de operaciones (procesos por lotes, seguridad,
comunicaciones, etc.). Los niveles de servicio se especifican formalmente en el
proceso Implantacin y Aceptacin del Sistema.
Tomando como referencia los requisitos establecidos para el sistema, y
teniendo en cuenta la arquitectura propuesta y las caractersticas del entorno
tecnolgico definido en esta actividad, se lleva a cabo la definicin de los
requisitos de seguridad y control de acceso necesarios para garantizar la
proteccin del sistema y minimizar el riesgo de prdida, alteracin o consulta
indebida de la informacin. Para ello, se disean los procedimientos
relacionados con:
Acceso al sistema y a sus recursos (datos, transacciones, libreras, etc.).

Mantenimiento de la integridad y confidencialidad de los datos.
Control y registro de accesos al sistema (logs, certificacin, etc.).
Copias de seguridad y recuperacin de datos y su periodicidad.
Recuperacin ante catstrofes.
As mismo, se definen los requisitos de operacin para los distintos elementos

del sistema (mdulos, clases, estructuras fsicas de datos, sistemas de
ficheros), que se estn elaborando en paralelo a esta actividad, y se disean
los procedimientos asociados relacionados con:
Tratamiento en lnea (franja horaria/periodos crticos, nmero mximo de
usuarios, etc.).
Tratamiento por lotes (periodicidad y secuencia de ejecucin,
interdependencias, peticin de ejecucin, etc.).
Control y planificacin de trabajos.
Recuperacin y reanudacin de trabajos.
Distribucin de informacin generada por el sistema, tanto trabajos
planificados o bajo peticin.
Control y seguimiento del correcto funcionamiento de los procedimientos de
backup y recuperacin utilizados habitualmente.
39
del Sistema.
Sistema.
De salida
Procedimientos de
Seguridad y Control de
Acceso.
Procedimientos de
Operacin y
Administracin del
Sistema.
Prcticas.
Sesiones de Trabajo
Catalogacin
Participantes
Equipo de Seguridad
Equipo de Soporte
Tcnico.
Diseo de la arquitectura de soporte.

En esta actividad se lleva a cabo la especificacin de la arquitectura de
soporte, que comprende el diseo de los subsistemas de soporte identificados
en la actividad de Definicin de la Arquitectura del Sistema (DSI 1), y la
determinacin de los mecanismos genricos de diseo. Estos ltimos sirven de
gua en la utilizacin de diferentes estilos de diseo, tanto en el mbito global
del sistema de informacin, como en el diseo de detalle.
El diseo de los subsistemas de soporte, conceptualmente, es similar al diseo
de los subsistemas especficos, aunque debe cumplir con unos objetivos claros
de reutilizacin. De esta manera, se consigue simplificar y abstraer el diseo de
los subsistemas especficos de la complejidad del entorno tecnolgico, dotando
al sistema de informacin de una mayor independencia de la infraestructura
que le da soporte. Con este fin, se aconseja la consulta de los datos de otros
proyectos existentes, disponible en el Histrico de Proyectos. Si esto no fuera
suficiente, se puede contar en esta actividad con la participacin de perfiles
tcnicos, con una visin global de la instalacin.
Esta actividad se realiza en paralelo al diseo detallado, debido a que existe
una constante realimentacin, tanto en la especificacin de los subsistemas
con sus interfaces y dependencias, como en la aplicacin de esqueletos o
patrones en el diseo.
Los productos resultantes de esta actividad son:
Diseo del Sistema de Informacin.
Diseo Detallado de los Subsistemas de Soporte.
Mecanismos Genricos de Diseo y Construccin.
40

Tarea
DSI
DSI
Diseo de
Subsistemas de
Soporte
Identificacin
de
Mecanismos
Genricos de
Diseo
Productos
Diseo Detallado
de los
Subsistemas de
Soporte.
Mecanismos
Genricos de
Diseo y
Construccin.
Tcnicas y Prcticas
Diagrama de Estructura.
Diagrama de Interaccin
de Objetos.
Diagrama de Clases
Sesiones de Trabajo
de Objetos.
Diagrama de Clases
Participantes
Equipo de
Arquitectura.
Equipo
de
Arquitectura
1. Diseo de Subsistemas de Soporte.

El objetivo de esta tarea es la especificacin y diseo de los mdulos/clases
que forman parte de los subsistemas de soporte, identificados en la tarea
Identificacin de Subsistemas de Diseo (DSI 1.5). Se lleva a cabo siempre y
cuando no se disponga en la instalacin de servicios comunes que respondan
satisfactoriamente a los requisitos planteados.
El nivel de reutilizacin de los subsistemas de soporte y sus servicios es
potencialmente alto, de modo que se debe intentar emplear, en la medida de lo
posible, los subsistemas que ya existan en la instalacin y se consideren
viables. La informacin relativa a dichos subsistemas podr obtenerse del
Histrico de Proyectos. En cualquier caso, cuando proceda realizar el diseo
de los subsistemas de soporte, se recomienda hacerlo con ese fin.
El diseo sigue las mismas pautas que las establecidas para los subsistemas
especficos, aunque con las siguientes particularidades:
Generalmente, ser necesaria una descomposicin de los subsistemas de
soporte en servicios, entendiendo como tales mdulos o clases
independientes y reutilizables.
Se recomienda realizar una descripcin de la interfaz y del comportamiento
de cada servicio, previa a su diseo de detalle, que permita completar el
diseo de los subsistemas especficos.
La especificacin y diseo de cada servicio, mdulo o clase, se realiza con
las tcnicas habituales de especificacin y diseo de mdulos o clases, o
incluso opcionalmente, si la simplicidad de los elementos lo aconseja, otros
lenguajes de especificacin, pseudocdigo o lenguaje natural.
A medida que se lleva a cabo esta tarea pueden surgir comportamientos de
excepcin que debern contemplarse igualmente en el diseo, y que en funcin
del nivel de especificacin que se haya establecido, se incorporan al catlogo
de excepciones.
41
Productos.
De entrada
Tcnicas
del Sistema.
De salida.
Diseo Detallado de los
Subsistemas de Soporte.
Diagrama de Interaccin de
Objetos
Diagrama de Clases
Participantes
2. Identificacin de Mecanismos Genricos de Diseo.

El objetivo es identificar y disear, en el caso de no existir en la instalacin,
esqueletos, patrones de diseo o guas de diseo. Estos mecanismos
genricos se definen a partir del estudio de comportamientos comunes
relacionados, generalmente, con gestin de transacciones, persistencia de
datos, control y recuperacin de errores, utilizacin de recursos comunes, etc.
Los mecanismos genricos de diseo se aplican tanto en la definicin de la
arquitectura del sistema como en el diseo de los subsistemas.
Productos
De entrada
del Sistema.
De salida
Mecanismos Genricos
de Diseo y Construccin.
Tcnicas
de Objetos
Diagrama de Clases
Prcticas
Participantes
Sesiones de Trabajo
42

Diseo de casos de uso reales.
Esta actividad, que se realiza solo en el caso de Diseo Orientado a Objetos,
tiene como propsito especificar el comportamiento del sistema de informacin
para un caso de uso, Diseo del Sistema de Informacin mediante objetos o
subsistemas de diseo que interactan, y determinar las operaciones de las
clases e interfaces de los distintos subsistemas de diseo.
Para ello, una vez identificadas las clases participantes dentro de un caso de
uso, es necesario completar los escenarios que se recogen del anlisis,
incluyendo las clases de diseo que correspondan y teniendo en cuenta las
restricciones del entorno tecnolgico, esto es, detalles relacionados con la
implementacin del sistema. Es necesario analizar los comportamientos de
excepcin para dichos escenarios. Algunos de ellos pueden haber sido
identificados en el proceso de anlisis, aunque no se resuelven hasta este
momento. Dichas excepciones se aadirn al catlogo de excepciones para
facilitar las pruebas.
Algunos de los escenarios detallados requerirn una nueva interfaz de usuario.
Por este motivo es necesario disear el formato de cada una de las pantallas o
impresos identificados.
Es importante validar que los subsistemas definidos en la tarea Identificacin
de Subsistemas de Diseo tienen la mnima interfaz con otros subsistemas. Por
este motivo, se elaboran los escenarios al nivel de subsistemas y, de esta
forma, se delimitan las interfaces necesarias para cada uno de ellos, teniendo
en cuenta toda la funcionalidad del sistema que recogen los casos de uso.
Adems, durante esta actividad pueden surgir requisitos de implementacin,
que se recogen en el catlogo de requisitos.
Las tareas de esta actividad se realizan en paralelo con las de Diseo de
Clases.
Tarea
DSI
Identificacin de
Diseo de la Realizacin de los

Casos de Uso o Especificacin
Interaccin de
Detallada.
Objetos
Diagrama de
Diseo de la
Realizacin de los
Casos de Uso o Especificacin
Interaccin de
Detallada.
Objetos.
Casos de Uso
Diseo de Interfaz de Usuario:

DSI
Tcnicas y Prcticas
Clases Asociadas a
un Caso de Uso
DSI
Productos
Revisin de la
Interfaz de Usuario
Diagrama de
Catalogacin
o Formatos Individuales de
Diagrama de
Interfaz de Pantalla Grfica o
Transicin de
Catlogo de Controles y
Estados Diagrama
Participantes
Equipo del
Proyecto.
Equipo del
Proyecto.
Equipo del
Proyecto.
Usuarios
Expertos
43

Elementos de Diseo de
Modelo de Navegacin de
de Interaccin de
Objetos.
Prototipado

Formatos de Impresin o
Prototipo de Interfaz de
Pantalla Grfica
DSI
Revisin de
Subsistemas de
Diseo e Interfaces
Diagrama de
Casos de Uso o Definicin a
Interaccin de
Nivel de Subsistemas e Interfaz
Objetos.
Equipo del
Proyecto
Equipo de
Arquitectura
1. Identificacin de Clases Asociadas a un Caso de Uso.

El objetivo de esta tarea es identificar las clases que intervienen en cada caso
de uso, a partir del conjunto de clases definidas en la tarea Identificacin de
Clases Adicionales, ya que, como se ha sealado en la introduccin de esta
actividad, las actividades DSI 3 y DSI 4 se realizan en paralelo. Dichas clases
se identifican a partir de las clases del modelo del anlisis y de aquellas clases
adicionales necesarias para el escenario que se est diseando.
A su vez, a medida que se va estudiando la descripcin de los casos de uso,
pueden aparecer nuevas clases de diseo que no hayan sido identificadas
anteriormente y que se incorporan al modelo de clases en la tarea
Identificacin de Clases Adicionales.
Tcnicas.
De entrada
Modelo de Clases de
Diseo.
Especificacin de Casos de
Uso.
Anlisis de la Realizacin de
los Casos de Uso.
De salida
Diseo de la Realizacin de
los Casos de Uso o
Especificacin Detallada
Objetos
Participantes
Equipo de Proyecto
2. Diseo de la Realizacin de los Casos de Uso.

El objetivo de esta tarea es definir cmo interactan entre s los objetos
identificados en la tarea anterior para realizar, desde un punto de vista tcnico,
un caso de uso del sistema de informacin. Para ello, se parte de los
44

escenarios especificados en el anlisis, y se detallan teniendo en cuenta que
se deben llevar cabo sobre un entorno tecnolgico concreto y unos
mecanismos genricos de diseo.
Durante el desarrollo de esta tarea, es posible que surjan excepciones que se
incluyen en el catlogo de excepciones, y que ahora quedan resueltas en los
escenarios correspondientes. Algunos de estos escenarios necesitan nueva
interfaz de usuario. Por lo tanto, las clases de interfaz que se identifiquen se
incorporan al modelo de clases de la tarea Identificacin de Clases Adicionales,
para realizar su diseo detallado.
Tambin se realiza el estudio de los escenarios de los distintos casos de uso,
para identificar comportamientos comunes sobre los que se aplican
mecanismos genricos de diseo identificados en la tarea de Identificacin de
Mecanismos Genricos de Diseo, o se puede decidir disear un subsistema
de soporte que contenga dicho comportamiento, como un servicio. El estudio
de los comportamientos comunes identificados puede servir de ayuda para
detallar o revisar la herencia entre clases en la tarea Diseo de la Jerarqua.
Tcnicas.
De entrada
Modelo de casos de uso.
Especificacin de casos de
uso.
Anlisis de la realizacin de
los casos de uso.
Especificacin de interfaz
de usuario.
Diseo de la realizacin de
los casos de uso.
De salida.
Diseo de la realizacin de
los casos de uso o
especificacin detallada.
Diagrama de interaccin de
objetos (colaboracin o
secuencia).
Participantes
Equipo de proyecto.
3. Revisin de la Interfaz de Usuario.

El objetivo de esta tarea es realizar el diseo detallado del comportamiento de
la interfaz de usuario a partir de la especificacin de la misma, obtenida en el
proceso de anlisis, y de acuerdo con el entorno tecnolgico definido. Si se
hubiera realizado un prototipo de la interfaz de usuario, ste se tomara como
punto de partida para el diseo. Adems, se incluyen las ventanas alternativas
o elementos de diseo surgidos como consecuencia del diseo de los
escenarios definidos en la tarea anterior.
45

Adems, se revisa: la interfaz de usuario, la navegacin entre ventanas, los
elementos que forman cada interfaz, sus caractersticas (que deben ser
consistentes con los atributos con los que estn relacionadas), su disposicin, y
cmo se gestionan los eventos relacionados con los objetos.
En aquellos casos en los que se realizan modificaciones significativas sobre la
interfaz de usuario, es conveniente que ste las valide, siendo opcional la
realizacin de un nuevo prototipo.
Tcnicas.
De entrada
Diseo de la
eealizacin de los
casos de uso.
Especificacin de
interfaz de usuario de
salida.
Diseo de interfaz de
usuario o formatos
individuales de
interfaz de pantalla
grfica.
Catlogo de controles
y elementos de diseo
de interfaz de pantalla
grfica o modelo de
navegacin de interfaz
de pantalla grfica o
formatos de impresin
Prototipo de interfaz
de pantalla grfica.
Diagrama de
interaccin de objetos.
Diagrama de
transicin de estados.
Prcticas
Prototipado
Catalogacin
Participantes
Prototipado.
Catalogacin.
Equipo del proyecto.
Usuarios expertos.
4. Revisin de Subsistemas de Diseo e Interfaces.

El objetivo de esta tarea es describir cada caso de uso en trminos de los
subsistemas que participan en el caso de uso y las interfaces que se requieren
entre ellos.
Para un caso de uso hay que definir, adems de los subsistemas y actores que
intervienen en el mismo, los mensajes que intercambian los objetos de un
subsistema con otro. Estos mensajes sirven para verificar y detallar las
interfaces de cada subsistema, teniendo en cuenta todos los casos de uso en
los que interviene, y completar de esta manera la definicin de subsistemas
establecida en la tarea Identificacin de Subsistemas de Diseo.
46

Tcnicas.
De entrada
Especificacin de Casos de
Uso.
los Casos de Uso.
De salida
los Casos de Uso o
Definicin a Nivel de
Subsistemas e Interfaz
Objetos
Participantes
Equipo del Proyecto
Diseo de clases.
El propsito de esta actividad, que se realiza slo en el caso de Diseo
Orientado a Objetos, es transformar el modelo de clases lgico, que proviene
del anlisis, en un modelo de clases de diseo. Dicho modelo recoge la
especificacin detallada de cada una de las clases, es decir, sus atributos,
operaciones, mtodos, y el diseo preciso de las relaciones establecidas entre
ellas, bien sean de agregacin, asociacin o jerarqua. Para llevar a cabo todos
estos puntos, se tienen en cuenta las decisiones tomadas sobre el entorno
tecnolgico y el entorno de desarrollo elegido para la implementacin.
Se identifican las clases de diseo, que denominamos clases adicionales, en
funcin del estudio de los escenarios de los casos de uso, que se est
realizando en paralelo en la actividad Diseo de Casos de Uso Reales y
aplicando los mecanismos genricos de diseo que se consideren
convenientes por el tipo de especificaciones tecnolgicas y de desarrollo. Entre
ellas se encuentran clases abstractas, que integran caractersticas comunes
con el objetivo de especializarlas en clases derivadas. Se disean las clases de
interfaz de usuario, que provienen del anlisis. Como consecuencia del estudio
de los escenarios secundarios que se est realizando, pueden aparecer nuevas
clases de interfaz.
Tambin hay que considerar que, por el diseo de las asociaciones y
agregaciones, pueden aparecer nuevas clases, o desaparecer incluyendo sus
atributos y mtodos en otras, si se considera conveniente por temas de
optimizacin.
La jerarqua entre las clases se va estableciendo a lo largo de esta actividad, a
medida que se van identificando comportamientos comunes en las clases,
aunque haya una tarea propia de diseo de la jerarqua.
47

Otro de los objetivos del diseo de las clases es identificar para cada clase, los
atributos, las operaciones que cubren las responsabilidades que se
identificaron en el anlisis, y la especificacin de los mtodos que implementan
esas operaciones, analizando los escenarios del Diseo de Casos de Uso
Reales. Se determina la visibilidad de los atributos y operaciones de cada
clase, con respecto a las otras clases del modelo.
Una vez que se ha elaborado el modelo de clases, se define la estructura fsica
de los datos correspondiente a ese modelo, en la actividad Diseo Fsico de
Datos.
Adems, en los casos en que sea necesaria una migracin de datos de otros
sistemas o una carga inicial de informacin, se realizar su especificacin a
partir del modelo de clases y las estructuras de datos de los sistemas origen.
Como resultado de todo lo anterior se actualiza el modelo de clases del
anlisis, una vez recogidas las decisiones de diseo.
Tarea
DSI
Identificacin de
Clases Adicionales
Diseo de
DSI
Productos
Asociaciones y
Diseo
DSI
Atributos de las
DSI
Operaciones de las
Clases
DSI
Diseo de la
DSI
Mtodos de las
Modelo de Clases
de Diseo
Jerarqua
Descripcin de
Modelo de Clases de
Diseo
Clases
Identificacin de
Modelo de Clases de
Diseo
Agregaciones
Identificacin de
Modelo de Clases de
Diagrama de Clases
Diagrama de Clases
Diagrama de Clases
Diagrama de Clases
Diagrama de
Transicin de
Clases de Diseo
Estados
Modelo de Clases de
Modelo de Clases de
Diseo
Operaciones
Comportamiento de
Diseo
Tcnicas y Prcticas
Diagrama de Clases
Diagrama de Clases
Especificacin de
DSI
Necesidades de
Migracin y Carga
Plan de Migracin y
Carga Inicial de Datos
Sesiones de Trabajo
Inicial de Datos
Participantes
Equipo del
Proyecto.
Equipo del
Proyecto.
Equipo del
Proyecto.
Equipo del
Proyecto.
Equipo del
Proyecto.
Equipo del
Proyecto.
Analistas.
Usuarios
Expertos.
1. Identificacin de Clases Adicionales.

El objetivo de esta tarea es identificar un conjunto de clases que completen el
modelo de clases analizado en la tarea Validacin de los Modelos del proceso
anterior (clases y/o interfaces) teniendo en cuenta que:
48

Cada interfaz identificada en el anlisis se corresponde en el diseo con una
clase que proporcione esa interfaz.
El conjunto de clases del anlisis puede modificarse en funcin de las
tecnologas de desarrollo utilizadas y de los mecanismos genricos de
diseo especificados.
Las clases de control deben contemplar la coordinacin y secuencia entre
objetos y, en algunos casos, deben contener lgica de negocio. De cualquier
manera, se deben considerar cuestiones de distribucin, de rendimiento, de
transaccin y de serializacin.
El diseo de las clases de entidad vara segn el sistema de gestin de datos
utilizado. Las clases pueden ser construidas por el propio desarrollador,
adquiridas en forma de bibliotecas, facilitadas por el entorno de trabajo o por el
entorno tecnolgico.
El diseo de las clases de interfaz de usuario depende de la tecnologa
especfica que se est utilizando. As, por ejemplo, la interfaz puede crearse a
partir de los objetos grficos disponibles en el entorno de desarrollo, sin
necesidad de que estos se contemplen en el modelo de clases
correspondiente.
Entre las clases identificadas a lo largo de esta tarea se encuentran clases
abstractas, que renen caractersticas comunes a varias clases. Cada subclase
aumenta su estructura y comportamiento con la clase abstracta de la que
hereda.
De entrada
Modelo de Clases de
Anlisis
de Usuario
De salida
Modelo de Clases de
Diseo
Tcnicas.
Diagrama de Clases.
Participantes
Equipo del Proyecto
2. Diseo de Asociaciones y Agregaciones.

En esta tarea se completan las asociaciones entre las clases del modelo de
clases del diseo, estudiando la secuencia de mensajes entre los objetos
correspondientes en el diagrama de interaccin de los escenarios definidos en
la tarea Descripcin de la Interaccin entre Objetos.
49

Para definir las asociaciones, partimos de las que fueron identificadas en la
tarea Identificacin de Asociaciones y Agregaciones teniendo en cuenta que:
Las caractersticas de la asociacin (papeles que desempea, multiplicidad,
etc.) se detallan segn el entorno de desarrollo utilizado.
Las relaciones bidireccionales se transforman en unidireccionales, para
simplificar la implementacin del sistema.
Se realiza la modelizacin de las rutas de acceso ptimas entre las
asociaciones para evitar problemas de rendimiento.
Se analiza la posibilidad de disear como clases algunas de las
asociaciones.
Opcionalmente, se especifica la forma en la que se va a implementar cada
asociacin (punteros, colecciones, etc.).
De entrada
Modelo de Clases de
Anlisis
Modelo de Clases de
Diseo
De salida
Modelo de Clases de
Diseo
Tcnicas.
Diagrama de Clases.
Participantes
Equipo del Proyecto
3. Identificacin de Atributos de las Clases.

El objetivo de esta tarea es identificar y describir, una vez que se ha
especificado el entorno de desarrollo, los atributos de las clases.
Para identificar los atributos se revisa el modelo de clases obtenido en el
proceso de Anlisis del Sistema de Informacin, considerando que, a partir de
uno de ellos, puede ser necesario definir atributos adicionales. Para cada
atributo identificado se define su tipo, con formatos especficos, y si existieran,
las restricciones asociadas a ese atributo.
Asimismo, se analiza la posibilidad de convertir un atributo en clase en aquellos
casos en los que:
El atributo se defina en varias clases de diseo.
La complejidad del atributo aumente la dificultad para comprender la clase a
la que pertenece.
50
De entrada
Modelo de Clases de
Anlisis
Modelo de Clases de
Diseo
De salida
Modelo de Clases de
Diseo
Tcnicas.
Diagrama de Clases.
Participantes
Equipo del Proyecto
4. Identificacin de Operaciones de las Clases.

El objetivo de esta tarea es definir, de forma detallada, las operaciones de cada
clase de diseo. Para ello, se toma como punto de partida el modelo de clases
generado en el anlisis, as como el diseo de los casos de uso reales y los
requisitos de diseo que pueden aparecer al definir el entorno de desarrollo.
Las operaciones de las clases de diseo surgen para dar respuesta a las
responsabilidades de las clases de anlisis y, adems, para definir las
interfaces que ofrece esa clase.
Segn el entorno de desarrollo utilizado, se describe cada operacin
especificando: su nombre, parmetros y visibilidad (pblica, privada, protegida).
Si el entorno de desarrollo lo permite, se tiene en cuenta la posibilidad de
simplificar el modelo de clases haciendo uso del polimorfismo y la sobrecarga
de operaciones.
Para identificar las operaciones de aquellos objetos que presenten distintos
estados, por lo que su comportamiento depende del estado en el que se
encuentren, es recomendable realizar un diagrama de transicin de estados, y
traducir cada accin o actividad del mismo en una de estas operaciones.
De entrada
Modelo de Clases de
Anlisis
Comportamiento de Clases
de Anlisis
Modelo de Clases de Diseo
De salida
de Diseo
Modelo de Clases de Diseo
Tcnicas.
Diagrama de Clases
Diagrama de Transicin de
Estados
Participantes
Equipo del Proyecto
51

5. Diseo de la Jerarqua.
El objetivo de esta tarea es revisar la jerarqua de clases que ha surgido en el
modelo de clases a lo largo de las tareas anteriores y comprobar que esa
jerarqua es viable segn los mecanismos disponibles en el entorno de
desarrollo utilizado.
Entre las modificaciones realizadas sobre la jerarqua se identifican clases
abstractas, que son superclases en las que se agrupan atributos y operaciones
que heredan sus subclases.
Productos.
De entrada
Modelo de Clases de
Diseo
De salida
Modelo de Clases de
Diseo
Tcnicas.
Diagrama de Clases
Participantes
Equipo del Proyecto
6. Descripcin de Mtodos de las Operaciones.

En esta tarea se describen los mtodos que se usan para detallar como se
realiza cada una de las operaciones de una clase. Los mtodos pueden
especificarse mediante un algoritmo, usando pseudocdigo o lenguaje natural.
Su implementacin se basa en la secuencia de interacciones del diagrama de
interaccin en los que la clase aparezca o en la secuencia de transiciones del
diagrama de transicin de estados.
En la mayora de los casos, esta tarea no se realiza hasta el proceso de
construccin, en el que los mtodos se describen directamente en el lenguaje
de programacin que se va a utilizar.
Productos.
De entrada
Modelo de Clases de
Diseo.
de Diseo.
De salida
Modelo de Clases de
Diseo
Tcnicas.
Diagrama de Clases
Participantes
Equipo del Proyecto
7. Especificacin de Necesidades de Migracin y Carga Inicial de Datos.

En esta tarea se realiza, en los casos que sea necesario y a partir de los
resultados de la tarea, una primera especificacin de las necesidades de
52

migracin o carga inicial de los datos requeridos por el sistema, que se
completa en la actividad Diseo de la Migracin y Carga Inicial de Datos.
Productos.
De entrada
Estructura de Datos del
Sistema Origen (externo)
Modelo de Clases de
Diseo
Plan de Migracin y Carga
Inicial de Datos
De salida
Inicial de Datos
Practicas.
Sesiones de trabajo.
Participantes
Analista.
Usuarios Expertos.
Diseo de la arquitectura de mdulos del sistema.

El objetivo de esta actividad, que slo se realiza en el caso de Diseo
Estructurado, es definir los mdulos del sistema de informacin, y la manera
en que van a interactuar unos con otros, intentando que cada mdulo trate total
o parcialmente un proceso especfico y tenga una interfaz sencilla.
Para cada uno de los subsistemas especficos, identificados en la tarea
Identificacin de los Subsistemas de Diseo, se disea la estructura modular
de los procesos que lo integran, tomando como punto de partida los modelos
obtenidos en la tarea Validacin de los Modelos del proceso de Anlisis del
Sistema de Informacin (ASI) y el catlogo de requisitos. Dicha estructura se
ir completando con los mdulos que vayan apareciendo como consecuencia
del diseo de la interfaz de usuario, as como de la optimizacin del diseo
fsico de datos.
Durante el diseo de los mdulos, se pueden identificar caractersticas o
comportamientos comunes relacionados con accesos a las bases de datos o
ficheros, lgica de tratamiento, llamadas a otros mdulos, gestin de errores,
etc. que determinen la necesidad de realizar su implementacin como
subsistemas de soporte.
Adems, se analizan los comportamientos de excepcin asociados a los
diferentes mdulos y a las interfaces entre los mismos, intentando independizar
en la medida de lo posible aqullos que presenten un tratamiento comn.
Dichas excepciones se incorporan al catlogo de excepciones.
53

En esta fase se consideran los estndares y normas establecidas para el
diseo, aplicando, cuando proceda, los mecanismos genricos de diseo
identificados en la tarea Identificacin de Mecanismos Genricos de Diseo.
Las tareas de esta actividad no se realizan de forma secuencial, sino en
paralelo, con continuas realimentaciones entre ellas y con las realizadas en las
actividades Definicin de la Arquitectura del Sistema, Diseo de la Arquitectura
de Soporte y Diseo Fsico de Datos.
Tarea
DSI
Diseo de Mdulos
del Sistema
Diseo de la
Arquitectura Modular
del Sistema
DSI
Tcnicas y
Prcticas
Productos
Diseo
de
la
Arquitectura
Modular
del Sistema
Diseo de
Comunicaciones
entre Mdulos
Participantes
Diagrama de
Estructura
Diagrama de
Estructura
Equipo de
Arquitectura.
Equipo del
Proyecto.
Equipo de
Arquitectura.
Equipo del
Proyecto.
Equipo de
Seguridad.
DSI
Revisin de la
Interfaz de Usuario
Diseo de Interfaz de
Usuario:
Descomposicin
Funcional en Dilogos o
Formatos Individuales de
Interfaz de Pantalla
Catlogo de Controles y
Elementos de Diseo de
Interfaz de Pantalla.
Modelo de Navegacin de
Interfaz de Pantalla
Formatos de Impresin o
Prototipo de Interfaz de
Pantalla o Prototipo de
Interfaz de Impresin
Diagrama de
Descomposicin
Funcional
Diagrama de
Transicin de
Estados.
Matricial
Catalogacin
Prototipo
Equipo del
Proyecto.
Usuarios
Expertos
1. Diseo de Mdulos del Sistema.

El objetivo de esta tarea es realizar una descomposicin modular de los
subsistemas especficos identificados en la tarea Identificacin de Subsistemas
de Diseo, a partir del modelo de procesos obtenido en el proceso Anlisis del
Sistema de Informacin. En esta tarea tambin se disean los mdulos de
consulta, generalmente no especificados en el modelo de procesos, aunque s
en el catlogo de requisitos.
Como paso previo al diseo de la estructura modular del sistema, se identifican
los procesos que se van a implementar en cada subsistema especfico. Para
cada uno de ellos se establece el tipo de implementacin y el tipo de iniciacin.
54

A su vez, se analiza el alcance y caractersticas propias de cada proceso con el
fin de determinar qu parte gestiona el acceso a la informacin soportada en
bases de datos, qu parte se encarga de integrar las funcionalidades
necesarias para cumplir las reglas del negocio y, en el caso de tratamiento en
lnea, qu parte gestiona la presentacin de la informacin en los dispositivos
de interfaz con los que el usuario va a interactuar.
Este anlisis permite identificar los procesos que son especficos del propio
sistema y aqullos que comparten servicios comunes o dan respuesta a los
mismos requisitos, y como consecuencia, considerar la posibilidad de
independizar dichos servicios e implementarlos como subsistemas de soporte,
teniendo en cuenta que su incorporacin puede llevar a una reorganizacin de
los subsistemas inicialmente identificados en la actividad Definicin de la
Arquitectura del Sistema.
De acuerdo a la arquitectura propuesta y al resultado del anlisis de cada
proceso, se disea su estructura en mdulos considerando los
comportamientos de excepcin correspondientes, en sucesivos niveles de
detalle, de forma que los mdulos resultantes tengan el mnimo acoplamiento y
la mxima cohesin. Finalmente, se especifica la lgica interna de tratamiento
por medio de lenguaje natural o pseudocdigo.
La estructura modular refleja, en el caso de tratamiento en lnea, las sucesivas
transacciones y dilogos, y en el caso de implementacin en lotes, la secuencia
de mdulos dentro de cada ejecucin.
En sistemas interactivos en los que exista una gran complejidad de gestin de
pantalla se propone, complementariamente al diagrama de estructura de
cuadros, perfeccionar el diseo de la interfaz de usuario en la tarea Revisin de
la Interfaz de Usuario, relacionando cada control/evento/accin de los formatos
individuales de presentacin de pantalla con los respectivos mdulos.
55
Productos.
De entrada
Modelo de Procesos
Especificacin de
Interfaz de Usuario.
con otros Sistemas.
Localizacin.
Diseo de la
Arquitectura del Sistema.
De salida
Diseo de la
Arquitectura Modular del
Sistema.
Tcnicas.
Diagrama de
Estructura
Participantes
Equipos de
Arquitectura.
Equipo de Proyecto.
2. Diseo de Comunicaciones entre Mdulos.

El objetivo de esta tarea es definir las interfaces entre los mdulos de cada
subsistema, entre subsistemas y con el resto de los sistemas, incluyendo tanto
la comunicacin de control como los datos propios del sistema, de acuerdo a la
arquitectura propuesta y a las caractersticas del entorno tecnolgico. Hay que
definir interfaces sencillas, que permitan reducir la complejidad de
comunicacin entre los distintos mdulos, especialmente los relacionados con
las comunicaciones entre subsistemas.
Por tanto, la especificacin de la estructura modular obtenida en la tarea
anterior se completa con la descripcin de las comunicaciones existentes entre
los distintos mdulos, considerando los requisitos establecidos inicialmente
para el sistema. Para garantizar el cumplimiento de dichos requisitos y
especialmente los relacionados con el rendimiento, disponibilidad y seguridad,
puede ser necesaria la incorporacin de nuevos mdulos o redisear la lgica
asociada. Para el diseo de las interfaces es necesario especificar:
Los datos o mensajes involucrados y formato de los mismos en el
intercambio.
Los valores o rangos de los datos intercambiados.
El origen y destino de los datos.
La informacin de control y valores posibles.
En el diseo de las interfaces con otros sistemas hay que tener en cuenta,
adems, la informacin recogida en la descripcin de interfaz con otros
sistemas obtenida en el proceso de Anlisis del Sistema del Informacin.
56

Las interfaces entre mdulos permiten evaluar las necesidades de
comunicacin entre los distintos nodos, de modo que influyen decisivamente en
el dimensionamiento del entorno tecnolgico.
Productos.
De entrada
Modelo de Procesos.
con otros Sistemas.
Modular del Sistema.
De salida
Modular del Sistema
Tcnicas.
Participantes
Equipo del Proyecto
3. Revisin de la Interfaz de Usuario.

El objetivo de esta tarea es realizar el diseo detallado de la interfaz de
usuario, tanto de pantalla como impresa, a partir de la especificacin obtenida
en el proceso de Anlisis del Sistema de Informacin, de acuerdo al entorno
tecnolgico seleccionado y considerando los estndares y directrices marcados
por la instalacin.
Se revisa la descomposicin funcional en dilogos de acuerdo a la arquitectura
modular para el sistema de informacin definida en la tarea anterior. Se
realizan las adaptaciones oportunas, teniendo en cuenta, a su vez, los
requisitos de rendimiento, de seguridad, la necesidad de alcanzar los tiempos
de respuesta establecidos y las caractersticas de cada dilogo.
Asimismo, se revisa en detalle la navegacin entre ventanas y la informacin
precisa para la ejecucin de cada dilogo, identificando las relaciones de
dependencia entre los datos para establecer la secuencia de presentacin ms
apropiada. Se determinan los datos obligatorios y opcionales, y aqullos que
requieren un rango de valores predefinido o algn tipo de informacin que se
considere relevante en el contexto del dilogo. Se definen las ventanas
alternativas o elementos de diseo necesarios, especificando su contenido.
Se comprueba que la informacin necesaria en cada interfaz, tanto de pantalla
como impresa, es tratada por el mdulo correspondiente de la arquitectura del
sistema, y es consistente con el modelo fsico de datos que se est elaborando
en paralelo en la actividad Diseo Fsico de Datos.
En dilogos complejos, se propone utilizar como base de la especificacin el
modelo de navegacin de interfaz de pantalla, relacionando cada
57

control/evento/accin de los formatos individuales de presentacin de pantalla
con el mdulo correspondiente, especificado en la tarea Diseo de Mdulos del
Sistema.
Igualmente, se realiza el diseo de los mensajes de error, mensajes de aviso o
advertencia que genera el sistema en funcin del tipo de accin realizado por el
usuario en el contexto del dilogo, as como las facilidades de ayuda que
proporciona la interfaz durante la interaccin con el sistema.
En el caso de que las modificaciones sean significativas en cuanto al formato o
la definicin de dilogos, se propone una validacin por parte del usuario, con
la realizacin opcional de prototipos para facilitar la revisin y aceptacin.
Productos.
De entrada
de Usuario.
Modular del Sistema
De salida
Usuario:
Descomposicin Funcional
en Dilogos o Formatos
Individuales de Interfaz de
pantalla
Catlogo de Controles.
Tcnicas.
Diagrama de
Descomposicin Funcional.
Diagrama de Transicin de
Estados.
Matricial.
Participantes
Equipo del Proyecto
Usuarios Expertos.
En el caso de las Prcticas tomar en cuenta la catalogacin

y prototipo.
Diseo fsico de datos.

En esta actividad se define la estructura fsica de datos que utilizar el sistema,
a partir del modelo lgico de datos normalizado o modelo de clases, de manera
que teniendo presentes las caractersticas especficas del sistema de gestin
de datos concreto a utilizar, los requisitos establecidos para el sistema de
informacin, y las particularidades del entorno tecnolgico, se consiga una
mayor eficiencia en el tratamiento de los datos.
58

Tambin se analizan los caminos de acceso a los datos utilizados por cada
mdulo/clase del sistema en consultas y actualizaciones, con el fin de mejorar
los tiempos de respuesta y optimizar los recursos de mquina.
Las tareas de esta actividad se realizan de forma iterativa y en paralelo con las
realizadas en las actividades Definicin de la Arquitectura del Sistema, dnde
se especifican los detalles de arquitectura e infraestructura y la planificacin de
capacidades, Diseo de la Arquitectura de Soporte, dnde se determinan y
disean los servicios comunes que pueden estar relacionados con la gestin de
datos, Diseo de Casos de Uso Reales y de Clases, para desarrollo orientado
a objetos, y Diseo de la Arquitectura de Mdulos del Sistema, para desarrollo
estructurado, dnde se especifica la lgica de tratamiento y las interfaces
utilizadas.
En el caso de diseo orientado a objetos, esta actividad tambin es necesaria.
La obtencin del modelo fsico de datos se realiza aplicando una serie de
reglas de transformacin a cada elemento del modelo de clases que se est
generando en la actividad Diseo de Clases.
Asimismo, en esta actividad hay que considerar los estndares y normas
establecidos para el diseo aplicando, cuando proceda, los mecanismos
genricos de diseo identificados en la tarea Identificacin de Mecanismos
Genricos de Diseo.
Tarea
DSI
Diseo del Modelo

Fsico de Datos
Modelo Fsico de Datos
DSI
Especificacin de
los Caminos de
Acceso a los Datos
Especificacin de los
Caminos de Acceso a los
Datos
DSI
Optimizacin del
Modelo Fsico de
Datos
DSI
Especificacin de la
Distribucin de
Datos
Tcnicas y
Prcticas
Productos

Optimizado
Esquemas Fsicos de
Datos
Asignacin esquemas
Fsicos de Datos a
Nodos.
Reglas de Obtencin
del Modelo Fsico a
Partir del Lgico
Reglas de
Transformacin
Clculo de Accesos
Fsicos.
Caminos de Acceso.
Optimizacin
Participantes
Equipo de
Arquitectura
Equipo del Proyecto
Administradores de
Bases de Datos
Equipo del Proyecto.
Equipo de
Arquitectura
Administradores de
Bases de Datos.
Matricial
Equipo de
Arquitectura.
Equipo de Soporte
Tcnico.
59

1. Diseo del Modelo Fsico de Datos.
El objetivo de esta tarea es realizar el diseo del modelo fsico de datos a partir
del modelo lgico de datos normalizado o del modelo de clases, en el caso de
diseo orientado a objetos.
Como paso previo al diseo de la estructura fsica de datos, se analizan las
peculiaridades tcnicas del gestor de bases de datos o sistema de ficheros a
utilizar, y las estimaciones sobre la utilizacin y volumen de las ocurrencias de
cada entidad / clase del modelo lgico de datos normalizado o modelo de
clases. Adems, si se ha establecido la necesidad de llevar a cabo una
migracin de datos, se deben tener en cuenta tambin los volmenes de las
estructuras de datos implicadas en la conversin. Esta informacin sirve para
decidir la mejor implementacin del modelo lgico de datos/modelo de clases,
as como para hacer una estimacin del espacio de almacenamiento.
De acuerdo al anlisis anterior, se determina cmo se van a convertir las
entidades/clases en tablas, considerando las relaciones existentes entre ellas y
los identificadores, definiendo sus claves primarias, ajenas, alternativas u otros
medios de acceso en general.
Tambin se definen aquellos elementos que, en funcin del gestor o sistemas
de ficheros a utilizar, se considere necesario implementar. Entre estos
elementos podemos citar los siguientes:
Bloqueo y comprensin de datos.
Agrupamientos (clster).
Punteros. Otros.
Productos.
De entrada
Caractersticas Especficas
del SGBD o Sistemas de
Ficheros a Utilizar (externo)
En Anlisis Estructurado:
Normalizado.
Inicial de Datos.
En Anlisis Orientado a
Objetos:
Modelo de Clases de
Diseo y Migracion de
datos.
De salida.
Modelo Fsico de Datos.
Tcnicas.
Reglas de Obtencin del
Modelo Fsico a partir del
Lgico.
Reglas de Transformacin.
Participantes
Administradores de Bases
de Datos.
60

2. Especificacin de los Caminos de Acceso a los Datos.
El objetivo de esta tarea es determinar los caminos de acceso a los datos
persistentes del sistema, utilizados por los principales mdulos/clases de
acuerdo al modelo fsico de datos, con el fin de optimizar el rendimiento de los
gestores de datos o sistemas de ficheros y el consumo de recursos, as como
disminuir los tiempos de respuesta.
Se recomienda realizar esta tarea para aquellos mdulos/clases que renan,
entre otras, alguna de las siguientes caractersticas:
Tratamiento crtico.
Concurrencia.
Accesos complejos a datos.
Para el inicio de esta tarea, se toma como referencia el Diseo Detallado de los
Subsistemas de Soporte y el Diseo de la Arquitectura Modular o Diseo de
Clases de los subsistemas especficos, productos que se estn generando en
paralelo a esta actividad.
Para cada mdulo / clase se identifican las tablas o ficheros y el tipo de acceso
realizado, as como el orden que debe seguirse para la obtencin de los datos.
Asimismo, se efecta una estimacin del nmero de accesos que deben
realizarse teniendo en cuenta, a su vez, la frecuencia y la prioridad del acceso.
La informacin obtenida sirve para identificar accesos excesivamente costosos
o redundantes que pueden comprometer el rendimiento final del sistema y que,
por lo tanto, exigen la optimizacin del modelo fsico de datos, mediante la
creacin de nuevos accesos, posibles desnormalizaciones o particiones del
modelo fsico de datos.
Productos.
De entrada.
Diseo Detallado de
Subsistemas de Soporte.
En Diseo Estructurado:
Modular del Sistema.
Objetos:
Modelo de Clases de Diseo.
De salida.
Especificacin de los Caminos
de Acceso a los Datos.
Prcticas.
Reglas de Obtencin
del Modelo Fsico a
partir del Lgico.
Reglas de
Transformacin.
Participantes
61

3. Optimizacin del Modelo Fsico de Datos.
En esta tarea se optimiza el diseo fsico de datos, con el objetivo de mejorar el
tiempo de respuesta en el acceso a datos persistentes, hacer una adecuada
utilizacin de los recursos del sistema y, en consecuencia, garantizar que el
diseo satisface las necesidades de tratamiento establecidas para el sistema
de informacin en cuanto a que se ajusta a los requisitos de rendimiento
exigidos.
A partir de la especificacin de la secuencia de accesos de aquellos
mdulos/clases identificados como crticos, obtenida en la tarea anterior, se
detectan las posibles mejoras con el fin de conseguir los niveles de rendimiento
establecidos y, por lo tanto, una mayor eficiencia del sistema. Como resultado,
puede ser necesaria una desnormalizacin controlada que se aplica para
reducir o simplificar el nmero de accesos a los sistemas de almacenamiento
de datos. La desnormalizacin puede obligar a:
Introducir elementos redundantes (campos, campos derivados, etc.).
Definir nuevos caminos de acceso.
Redefinir relaciones.
Dividir o unir tablas.
En la revisin de la estructura fsica de datos se deben tener en cuenta criterios
relacionados con:
Mdulos / clases identificados como crticos.
Estimacin de volmenes.
Frecuencia y tipo de acceso.
Estimaciones de crecimiento por periodo.
Requisitos relativos al rendimiento, seguridad,
disponibilidad, entre otros, considerados relevantes.
confidencialidad
Es importante que la desnormalizacin se lleve a cabo de una forma

controlada, para evitar anomalas en el tratamiento de los datos.
62

Productos.
De entrada
Caractersticas Especficas
del SGBD o Sistemas de
Ficheros a Utilizar
(externo)
En Anlisis Estructurado:
Normalizado.
Inicial de Datos.
En Anlisis Orientado a
Objetos:
Modelo de Clases de
Diseo y Migracion de
datos.
De salida.
Tcnicas.
Optimizacin.
Participantes
Equipo de
Arquitectura.
Administradores de
Bases de Datos.
Especificacin de la Distribucin de Datos.

En esta tarea se determina el modelo de distribucin de datos, teniendo en
cuenta los requisitos de diseo establecidos. Se establece la ubicacin de los
gestores de bases de datos o sistemas de ficheros, as como de los distintos
elementos de la estructura fsica de datos, en los nodos correspondientes, de
acuerdo al particionamiento fsico del sistema de informacin especificado en la
actividad Diseo de la Arquitectura del Sistema.
El resultado de esta actividad es la especificacin de los modelos fsicos
particulares de cada nodo, esquemas fsicos de datos, as como su asignacin
a los nodos.
63

Productos.
De entrada.
Diseo de la
Arquitectura del
Sistema o
Particionamiento Fsico
del Sistema de
Informacin Catlogo
de Requisitos Modelo
Fsico de Datos
Optimizado.
De salida.
Esquemas Fsicos de
Datos.
Asignacin Esquemas
Fsicos de Datos a
Nodos
Tcnicas.
Matricial.
Participantes
Equipo de
Arquitectura.
Equipo de Soporte
Tcnico.
Verificacin y aceptacin de la arquitectura del sistema.

El objetivo de esta actividad es garantizar la calidad de las especificaciones del
diseo del sistema de informacin y la viabilidad del mismo, como paso previo
a la generacin de las especificaciones de construccin. Para cumplir dicho
objetivo, se llevan a cabo las siguientes acciones:
Verificacin de la calidad tcnica de cada modelo o especificacin
Aseguramiento de la coherencia entre los distintos modelos
Aceptacin del diseo de la arquitectura por parte de Explotacin y
Sistemas.
Esta actividad es compleja, por lo que es aconsejable utilizar herramientas de
apoyo para la realizacin de sus tareas.
Tarea
DSI
Verificacin de las
Especificaciones de
Diseo
Productos
Tcnicas y
Prcticas

Sistema
Diseo de la
Arquitectura del Sistema
Diseo Detallado de
Subsistemas de Soporte
Optimizado
Esquemas Fsicos de
Datos
Asignacin de Esquemas
Fsicos de Datos a Nodos
Participantes
Equipo de
Arquitectura
Equipo del
Proyecto
64
DSI
Anlisis de
Consistencia de las
Especificaciones de
Diseo
DSI
Aceptacin de la
Arquitectura del
Sistema
Usuario
Estructurado:
Diseo de la
Orientacin a Objetos:
Diseo de la Realizacin
de los Casos de Uso.
Modelo de Clases de
Diseo.
Comportamiento de
Clases de Diseo.
Entorno Tecnolgico
del Sistema.
Diseo de la
Arquitectura del
Sistema
Diseo Detallado de
Subsistemas de
Soporte.
Optimizado
Esquemas Fsicos de
Datos
Asignacin de
Esquemas Fsicos de
Datos a Nodos.
Usuario Estructurado:
Diseo de la
Orientacin a Objetos:
Diseo de la
Realizacin de los
Casos de Uso
Modelo de Clases de
Diseo
Comportamiento de
Clases de Diseo
Matricial
Aceptacin Tcnica del

Diseo
Equipo de
Arquitectura.
Equipo del
Proyecto.
Jefe de Proyecto
Responsable de
Operacin
Responsable de
Sistemas
1. Verificacin de las Especificaciones de Diseo.

El objetivo de esta tarea es asegurar la calidad formal de los distintos modelos,
conforme a la tcnica seguida para la elaboracin de cada producto y a las
normas y estndares especificados en el catlogo de normas.
2. Anlisis de Consistencia de las Especificaciones de Diseo.
El objetivo de esta tarea es asegurar que las especificaciones del diseo son
coherentes entre s, comprobando la falta de ambigedades o duplicacin de
65

informacin. Esta consistencia se asegura entre especificaciones de diseo, y
con respecto a los modelos del anlisis.
Las diferentes comprobaciones se fundamentan generalmente en tcnicas
matriciales o de revisin entre los elementos comunes de los distintos modelos.
El anlisis de consistencia relativo a la arquitectura del sistema es comn para
desarrollo estructurado y orientado a objetos, aunque respecto a los productos
del diseo detallado es especfico para cada uno de los enfoques. Las
verificaciones que se hacen son las siguientes:
Arquitectura del Sistema / Subsistemas.
Cada subsistema de diseo est asociado al menos con un nodo del
particionamiento fsico del sistema de informacin.
Arquitectura del Sistema / Modelo Fsico de Datos.
Todos los elementos definidos en el Modelo Fsico de Datos Optimizado se
incorporan, al menos, en un esquema fsico de datos.
Cada esquema del Modelo Fsico de Datos est asociado con un nodo del
particionamiento fsico del sistema de informacin.
Arquitectura del Sistema / Entorno Tecnolgico del Sistema de Informacin:
Cada nodo del particionamiento del sistema de informacin est soportado por
el entorno tecnolgico.
Se da soporte a todas las necesidades de comunicaciones entre nodos.
Arquitectura del Sistema / Diseo Detallado de Subsistemas:
Cada mdulo o clase del diseo detallado pertenece al menos a un
subsistema.
La interfaz del subsistema est proporcionada por interfaces de mdulos o
clases internas al subsistema.
La especificacin de dependencias mediante el estudio de las interfaces
entre subsistemas, ya que la existencia de interfaz implica el establecimiento
de una dependencia.
Catlogo de Excepciones / Diseo Detallado de Subsistemas:
Cada excepcin del catlogo es tratada en el diseo de detalle del sistema
de informacin, segn los criterios establecidos en la creacin del catlogo.
Los anlisis de consistencia especficos para el Diseo Estructurado son:
Diseo Detallado de Subsistemas / Modelo Fsico de Datos:
Los elementos del modelo fsico de datos corresponden con los elementos
utilizados por los mdulos del diseo detallado, tanto de los subsistemas
especficos como de los de soporte.
66

Diseo Detallado de Subsistemas / Interfaz de Usuario:
Los datos o formatos de mensajes necesarios en el diseo de la interfaz de
usuario corresponden con los datos o formatos de mensajes de los
correspondientes mdulos.
Para cada evento / accin solicitado por el usuario existe un mdulo que le
da respuesta.
Los anlisis de consistencia especficos para el
Diseo Orientado a Objetos son:
Modelo de Clases / Modelo Fsico de Datos:
Los elementos del modelo fsico de datos corresponden con los elementos
utilizados por las clases del diseo detallado, tanto de los subsistemas
especficos como de soporte.
Modelo de Clases / Diagramas Dinmicos.
Cada mensaje entre objetos se corresponde con una operacin de una
clase, y todos los mensajes se envan a las clases correctas, incluyendo las
clases de interfaz y la navegacin entre ventanas.
Cada mensaje entre subsistemas se corresponde con una operacin de una
clase del subsistema destino.
La clase que recibe un mensaje con peticin de datos tiene capacidad para
proporcionar esos datos.
Cada objeto del diagrama de interaccin de objetos tiene una
correspondencia en el modelo de clases.
Todas las clases, atributos y mtodos identificados en la interfaz de usuario
tienen su correspondencia con algn atributo, mtodo o clase en el modelo
de clases.
En el caso de haber elaborado diagramas de transicin de estados para clases
significativas:
Se comprueba que para cada uno de ellos, todo evento se corresponde con
una operacin de la clase. Tambin se tendr que establecer si las acciones
y actividades de los diagramas de transicin de estado se corresponden con
operaciones de la clase. Opcionalmente, se propone obtener para el anlisis
de consistencia en un diseo orientado a objetos:
Matriz de mensajes del diagrama de interaccin de objetos / operaciones del
modelo de clases.
Matriz de mensajes del diagrama de interaccin de objetos / operaciones y
atributos del modelo de clases.
Matriz de objetos del diagrama de interaccin de objetos / clases, atributos
del modelo de clases.
Matriz (evento, accin, actividad de clase) / operaciones de clase.
Matriz clases / elementos del modelo fsico de datos.
67
Productos.
De entrada
Catlogo de Requisitos
Diseo Detallado de
los Subsistemas de
Soporte
Catlogo de
Excepciones
Catlogo de Normas
Entorno Tecnolgico
del Sistema
Diseo de la
Arquitectura del
Sistema
3. Aceptacin de la Arquitectura del Sistema.

El objetivo de esta tarea es obtener la aceptacin, por parte de las reas de
explotacin y sistemas, de la arquitectura del sistema de informacin y de los
requisitos de operacin y seguridad, con el fin de poder valorar su impacto en
la instalacin.
Generacin de especificaciones de construccin.

En esta actividad se generan las especificaciones para la construccin del
sistema de informacin, a partir del diseo detallado.
Estas especificaciones definen la construccin del sistema de informacin a
partir de las unidades bsicas de construccin (en adelante, componentes),
entendiendo como tales unidades independientes y coherentes de construccin
y ejecucin, que se corresponden con un empaquetamiento fsico de los
elementos del diseo de detalle, como pueden ser mdulos, clases o
especificaciones de interfaz.
La divisin del sistema de informacin en subsistemas de diseo proporciona,
por continuidad, una primera divisin en subsistemas de construccin,
definiendo para cada uno de ellos los componentes que lo integran. Si se
considera necesario, un subsistema de diseo se podr dividir a su vez en
sucesivos niveles para mayor claridad de las especificaciones de construccin.
Las dependencias entre subsistemas de diseo proporcionan informacin para
establecer las dependencias entre los subsistemas de construccin y, por lo
tanto, definir el orden o secuencia que se debe seguir en la construccin y en la
realizacin de las pruebas.
68

Tambin se generan las especificaciones necesarias para la creacin de las
estructuras de datos en los gestores de bases de datos o sistemas de ficheros.
El producto resultante de esta actividad es el conjunto de las especificaciones
de construccin del sistema de informacin, que comprende:
Especificacin del entorno de construccin.
Descripcin de subsistemas de construccin y dependencias.
Descripcin de componentes.
Plan de integracin del sistema de informacin.
Especificacin detallada de componentes.
Especificacin de la estructura fsica de datos.
Tarea
Tcnicas y
Productos
Especificaciones de
DSI
8.1
Especificacin del
Entorno de
Construccin
Participantes
Prcticas
Construccin del Sistema de

Informacin: o
Equipo de Soporte
Tcnico.
Especificacin del Entorno
Equipo de Sistemas.
Equipo del Proyecto
Equipo del Proyecto
Informacin o
Administradores de la
de Construccin
Especificaciones de
Definicin de
DSI
8.2
Componentes y
Subsistemas de
Construccin
Diagrama de
Informacin: o Descripcin
Estructura
de Subsistemas de
Matricial.
Construccin y
Diagrama de
Dependencias o Descripcin
Componentes.
de Componentes o Plan de
Diagrama de
Integracin del Sistema de
Despliegue.
Informacin
Especificaciones de
DSI
8.3
Elaboracin de
Especificaciones de
Construccin

Informacin: o
Especificacin Detallada de
Diagrama de
Componentes
Componentes
Elaboracin de
DSI
8.4
Especificaciones del
Modelo Fsico de
Datos
Especificaciones de
Especificacin de la
Base de Datos
Estructura Fsica de Datos.
1. Especificacin del Entorno de Construccin.

El objetivo de esta tarea es la definicin detallada y completa del entorno
necesario para la construccin de los componentes del sistema de informacin.
69

Se propone que la especificacin del entorno se realice segn los siguientes
conceptos:
Entorno tecnolgico: hardware, software y comunicaciones.
Herramientas de construccin, generadores de cdigo, compiladores, etc.
Restricciones tcnicas del entorno.
Planificacin de capacidades previstas, o la informacin que estime oportuno
el departamento de sistemas para efectuar dicha planificacin.
Requisitos de operacin y seguridad del entorno de construccin.
Productos.
De entrada.
Diseo de la Arquitectura del Sistema.
Entorno Tecnolgico del Sistema.
De salida
Especificaciones de Construccin del Sistema de Informacin o Especificacin.
del Entorno de Construccin.
Participantes
Equipo de Sistemas.
2. Definicin de Componentes y Subsistemas de Construccin.
La especificacin de los subsistemas de construccin se realiza a partir de los
subsistemas de diseo, con una continuidad directa, permitindose a su vez un
mayor nivel de detalle agrupando componentes en subsistemas dentro de un
subsistema de construccin.
Los componentes se definen mediante la agrupacin de elementos del diseo
de detalle de cada subsistema de diseo. En principio, cada mdulo o clase y
cada formato individual de interfaz se corresponden con un componente,
aunque se pueden agrupar o redistribuir mdulos o clases en componentes,
siguiendo otros criterios ms oportunos, como pueden ser:
Optimizacin de recursos.
Caractersticas comunes de funcionalidad o de acceso a datos.
Necesidades especiales de ejecucin: elementos crticos, accesos costosos
a datos, etc.
70

Los subsistemas de construccin y las dependencias entre subsistemas y entre
componentes de un subsistema recogen aspectos prcticos relativos a la
plataforma concreta de construccin y ejecucin. Entre estos aspectos se
pueden citar, por ejemplo:
Secuencia de compilacin entre componentes.
Agrupacin de elementos en libreras o packages (por ejemplo, DLL en el
entorno Windows, packages en Java).
La asignacin de subsistemas de construccin a nodos, por continuidad con el
diseo, determina la distribucin de los componentes que lo integran.
Opcionalmente, se propone la realizacin de un plan de integracin del sistema
de informacin, especificando la secuencia y organizacin de la construccin y
prueba de los subsistemas de construccin y de los componentes, desde un
punto de vista tcnico.
3. Elaboracin de Especificaciones de Construccin.
Se realiza una especificacin detallada de cada componente, en pseudocdigo
o lenguaje natural, completando la informacin que se considere necesaria
segn el entorno tecnolgico.
Asimismo, se determinan y especifican todos los elementos o parmetros
complementarios a la propia definicin de componentes que, en funcin del
entorno tecnolgico, completan las especificaciones de construccin. Como
ejemplos, es posible citar las tablas de definicin de programas y transacciones
en monitores de teleproceso, etc.
4. Elaboracin de Especificaciones del Modelo Fsico de Datos.
En esta tarea se generan las especificaciones necesarias para la definicin y
creacin de los elementos del modelo fsico de datos, mediante el lenguaje de
definicin de datos del correspondiente gestor de base de datos o sistema de
ficheros, teniendo en cuenta el entorno tecnolgico, las normas y estndares
de la organizacin y caractersticas intrnsecas del gestor o sistema de ficheros
a utilizar.
Diseo de la migracin y carga inicial de datos.

Esta actividad slo se lleva a cabo cuando es necesaria una carga inicial de
informacin, o una migracin de datos de otros sistemas, cuyo alcance y
estrategia a seguir se habr establecido previamente.
Para ello, se toma como referencia el plan de migracin y carga inicial de
datos, que recoge las estructuras fsicas de datos del sistema o sistemas
origen implicadas en la conversin, la prioridad en las cargas y secuencia a
seguir, las necesidades previas de depuracin de la informacin, as como los
71

requisitos necesarios para garantizar la correcta implementacin de los
procedimientos de migracin sin comprometer el funcionamiento de los
sistemas actuales.
A partir de dicho plan, y de acuerdo a la estructura fsica de los datos del nuevo
sistema, obtenida en la actividad Diseo Fsico de Datos, y a las caractersticas
de la arquitectura y del entorno tecnolgico propuesto en la actividad Definicin
de la Arquitectura del Sistema, se procede a definir y disear en detalle los
procedimientos y procesos necesarios para realizar la migracin.
Se completa el plan de pruebas especfico establecido en el plan de migracin
y carga inicial, detallando las pruebas a realizar, los criterios de aceptacin o
rechazo de la prueba y los responsables de la organizacin, realizacin y
evaluacin de resultados.
Asimismo, se determinan las necesidades adicionales de infraestructura, tanto
para la implementacin de los procesos como para la realizacin de las
pruebas.
Como resultado de esta actividad, se actualiza el plan de migracin y carga
inicial de datos con la informacin siguiente:
Especificacin del entorno de migracin.
Definicin de procedimientos de migracin.
Diseo detallado de mdulos.
Especificacin tcnica de las pruebas.
Planificacin de la migracin y carga inicial.
Es importante considerar que una carga inicial de informacin no tiene el
mismo alcance y complejidad que una migracin de datos, de modo que las
tareas de esta actividad se deben llevar a cabo en mayor o menor medida en
funcin de las caractersticas de los datos a cargar.
Tarea
Especificacin del
DSI
Entorno de
Migracin
Diseo de
DSI
Productos
Tcnicas y
Prcticas

Inicial de Datos: o
Especificacin del Entorno de
Migracin y Carga Inicial
Participantes
Equipo de
Arquitectura
Equipo de Soporte
Tcnico
Equipo de
Arquitectura
Procedimientos de
Inicial de Datos: o Definicin
Migracin y Carga
de Procedimientos de
Equipo del Proyecto
Migracin y Carga Inicial
Equipo de Seguridad
Inicial
72

Diseo Detallado
DSI
de Componentes
de Migracin y
Carga Inicial
Inicial de Datos: o Diseo

Detallado de Mdulos de
Migracin y Carga Inicial o
Equipo del Proyecto
Especificacin Tcnica de las

Pruebas de Migracin y Carga
Inicial
Revisin de la
DSI
Planificacin de la
Migracin

Inicial de Datos: o
Planificacin de la Migracin
Jefe de Proyecto.
y Carga Inicial
1. Especificacin del Entorno de Migracin.

El objetivo de esta tarea es definir el entorno tecnolgico propio de los
procesos de migracin y carga inicial, adecuando al mismo las necesidades y
requisitos reflejados en el plan de migracin y carga inicial de datos. En la
descripcin del entorno tecnolgico, hay que tener en cuenta las herramientas
o utilidades software especficas de estos procesos.
Se realiza una estimacin de capacidades (capacity planning) para este
entorno que permita evaluar las necesidades de infraestructura, principalmente
relacionadas con el espacio de almacenamiento y las comunicaciones.
2. Diseo de Procedimientos de Migracin y Carga Inicial.
El objetivo de esta tarea es la definicin de los procedimientos necesarios para
llevar a cabo la migracin y carga inicial de datos del sistema.
Como punto de partida se tiene en cuenta, junto con los requisitos y
especificaciones de migracin y carga inicial, el modelo fsico de datos
optimizado y su localizacin en los nodos, as como la definicin del entorno
tecnolgico del sistema de informacin.
Los procedimientos asociados a la migracin y carga inicial de datos son,
principalmente, los relacionados con la preparacin, la realizacin y la posterior
verificacin del proceso. Entre ellos se encuentran los siguientes:
Procedimientos de seguridad, relativos a Control de acceso a la informacin.

Copias de seguridad de los procesos.
Recuperacin de la informacin.
Tratamiento de las posibles contingencias durante la conversin.
Procedimientos de carga de datos, relativos a:
Depuraciones previas de informacin.
73
Procesos de validacin.
Procesos de importacin.
Procesos de carga y prioridades.
Procedimientos de verificacin de los procesos y comprobacin de la
integridad de la informacin resultante al finalizar la conversin, conforme a
la estructura fsica de los datos destino.
3. Diseo Detallado de Componentes de Migracin y Carga Inicial.

El objetivo de esta tarea es el diseo detallado, en sucesivos niveles de detalle,
de los mdulos de migracin y carga inicial, indicando la jerarqua y orden de
ejecucin.
El diseo de los mdulos necesarios para la migracin y carga inicial no es
conceptualmente distinto del diseo de cualquier otro mdulo del sistema de
informacin, por lo que se recomienda utilizar pautas similares. Se debe tener
en cuenta el modelo fsico de datos del sistema de informacin, as como las
estructuras de datos del sistema o sistemas origen recogidas en el plan de
migracin y carga inicial de datos.
Finalmente, se complementa el plan de migracin y carga inicial con la
definicin de los distintos tipos de prueba a realizar.
4. Revisin de la Planificacin de la Migracin.
El objetivo de esta tarea es completar la especificacin del plan de migracin y
carga inicial, concretando el plan de trabajo de acuerdo a los procedimientos y
procesos de migracin y carga inicial definidos.
Especificacin tcnica del plan de pruebas.
En esta actividad se realiza la especificacin de detalle del plan de pruebas del
sistema de informacin para cada uno de los niveles de prueba establecidos en
el proceso Anlisis del Sistema de Informacin:
Pruebas unitarias.
Pruebas de integracin.
Pruebas del sistema.
Pruebas de implantacin.
Pruebas de aceptacin.
Para ello se toma como referencia el plan de pruebas, que recoge los objetivos
de la prueba de un sistema, establece y coordina una estrategia de trabajo, y
provee del marco adecuado para planificar paso a paso las actividades de
prueba. Tambin puede ser una referencia el plan de integracin del sistema
74

de informacin propuesto, opcionalmente,
Componentes y Subsistemas de Construccin.
en
la tarea Definicin de
El catlogo de requisitos, el catlogo de excepciones y el diseo detallado del

sistema de informacin, permiten la definicin de las verificaciones que deben
realizarse en cada nivel de prueba para comprobar que el sistema responde a
los requisitos planteados. La asociacin de las distintas verificaciones a
componentes, grupos de componentes y subsistemas, o al sistema de
informacin completo, determina las distintas verificaciones de cada nivel de
prueba establecido.
Las pruebas unitarias comprenden las verificaciones asociadas a cada
componente del sistema de informacin. Su realizacin tiene como objetivo
verificar la funcionalidad y estructura de cada componente individual.
Las pruebas de integracin comprenden verificaciones asociadas a grupos de
componentes, generalmente reflejados en la definicin de subsistemas de
construccin o en el plan de integracin del sistema de informacin. Tienen por
objetivo verificar el correcto ensamblaje entre los distintos componentes.
Las pruebas del sistema, de implantacin y de aceptacin corresponden a
verificaciones asociadas al sistema de informacin, y reflejan distintos
propsitos en cada tipo de prueba:
Las pruebas del sistema son pruebas de integracin del sistema de
informacin completo. Permiten probar el sistema en su conjunto y con otros
sistemas con los que se relaciona para verificar que las especificaciones
funcionales y tcnicas se cumplen.
Las pruebas de implantacin incluyen las verificaciones necesarias para
asegurar que el sistema funcionar correctamente en el entorno de
operacin al responder satisfactoriamente a los requisitos de rendimiento,
seguridad y operacin, y coexistencia con el resto de los sistemas de la
instalacin, y conseguir la aceptacin del sistema por parte del usuario de
operacin.
Las pruebas de aceptacin van dirigidas a validar que el sistema cumple los
requisitos de funcionamiento esperado, recogidos en el catlogo de
requisitos y en los criterios de aceptacin del sistema de informacin, y
conseguir la aceptacin final del sistema por parte del usuario.
Las pruebas unitarias, de integracin y del sistema se llevan a cabo en el
proceso Construccin del Sistema de Informacin (CSI), mientras que las
pruebas de implantacin y aceptacin se realizan en el proceso Implantacin y
Aceptacin del Sistema (IAS).
75

Como resultado de esta actividad se actualiza el plan de pruebas con la
informacin siguiente:
Especificacin del entorno de pruebas.
Especificacin tcnica de niveles de prueba.
Planificacin de las pruebas.
Tarea
Productos
Tcnicas y
Prcticas
Participantes
DSI
Especificacin del
Plan de Pruebas: o
Entorno de
Especificacin del
Pruebas
Entorno de Pruebas.
Equipo de Soporte
Tcnico
Equipo del Proyecto
Equipo de Seguridad
Especificacin
DSI
Tcnica de Niveles
de Prueba
Revisin de la
DSI
Planificacin de
Pruebas
Plan de Pruebas: o
Jefe de Proyecto
Especificacin Tcnica de
Analistas
Niveles de Prueba.
Usuarios Expertos
Plan de Pruebas: o
Planificacin de las
Jefe de Proyecto
Pruebas
1. Especificacin del Entorno de Pruebas.

El objetivo de esta tarea es la definicin detallada y completa del entorno
necesario para la realizacin de las pruebas del sistema: unitarias, de
integracin, de implantacin y de aceptacin.
Se propone considerar los siguientes conceptos en la especificacin del
entorno:
Entorno tecnolgico: hardware, software y comunicaciones.
Restricciones tcnicas del entorno.
Requisitos de operacin y seguridad del entorno de pruebas.
Herramientas de prueba relacionadas con la extraccin de juegos de
ensayo, anlisis de resultados, utilidades de gestin del entorno, etc.
Planificacin de capacidades previstas, o la informacin que estime oportuno
el departamento tcnico para efectuar dicha planificacin.
Procedimientos de promocin de elementos entre entornos (desarrollo,
pruebas, explotacin, etc.).
Procedimientos de emergencia y de recuperacin, as como de vuelta atrs.
2. Especificacin Tcnica de Niveles de Prueba.
El objetivo de esta tarea es el diseo detallado de los distintos niveles de
prueba, especificados en el plan de pruebas elaborado en el proceso Anlisis
del Sistema de Informacin.
76

El plan de integracin del sistema de informacin, si se ha definido en la
actividad Definicin de Componentes y Subsistemas de Construccin, va a
servir de referencia para la elaboracin detallada del plan de pruebas,
principalmente las pruebas de integracin y del sistema. En cualquier caso se
hay que especificar la estrategia de integracin de dichas pruebas.
De acuerdo a la arquitectura del sistema propuesta y a las caractersticas
intrnsecas del diseo del sistema de informacin, se definen en detalle las
distintas verificaciones a realizar sobre el sistema, conforme a los niveles de
prueba establecidos, teniendo en cuenta que una verificacin puede ser
aplicable a varios componentes o grupos de componentes.
Estas verificaciones deben cubrir aspectos funcionales y no funcionales,
considerando las excepciones que puedan producirse, as como las soluciones
de diseo adoptadas, tanto del propio diseo de detalle del sistema de
informacin, como de la utilizacin de subsistemas de soporte propios de la
instalacin.
Las verificaciones a realizar se especifican detallando:
mbito de aplicacin (prueba unitaria, de integracin, del sistema, de
implantacin o aceptacin) y objetivo.
Casos de prueba asociados: se definen en detalle los casos de prueba y se
detalla cmo proceder en la ejecucin de dichos casos, describiendo todas
las entradas necesarias para ejecutar la prueba, y las relaciones de
secuencialidad existentes entre las entradas, as como todas aquellas
salidas que se espera obtener una vez ejecutado el caso de prueba, y las
caractersticas especiales requeridas, como por ejemplo, tiempo de
respuesta.
Procedimientos de prueba: se determina el conjunto de pasos a seguir para
asegurar que los casos de prueba se ejecutan adecuadamente,
especificando:
Casos de prueba a los que se aplica el procedimiento.
Recursos hardware y software necesarios para ejecutar el procedimiento.
Requisitos especiales o acciones necesarias para iniciar la ejecucin.
Requisitos especiales o acciones necesarias a realizar durante la ejecucin
del procedimiento.
Entorno de prueba: herramientas adicionales, condicionantes especiales de
ejecucin, etc.
Criterios de aceptacin de la prueba.
Anlisis y evaluacin de resultados.
Como resultado final, se obtiene la relacin de verificaciones que permiten
comprobar:
77

- El correcto funcionamiento de cada componente (pruebas unitarias), cada
subsistema de construccin o conjunto de componentes (pruebas de
integracin).
- La integracin del sistema de informacin en su totalidad (pruebas del
sistema).
- El ajuste del sistema a las necesidades para las que fue creado, de
acuerdo a las caractersticas del entorno en el que se va a implantar
(pruebas de implantacin).
- La respuesta satisfactoria del sistema a los requisitos especificados por el
usuario (pruebas de aceptacin).
3. Revisin de la Planificacin de Pruebas
En esta tarea se completa y especifica la planificacin de las pruebas,
determinando los distintos perfiles implicados en la preparacin y ejecucin de
las pruebas y en la evaluacin de los resultados, as como el tiempo estimado
para la realizacin de cada uno de los niveles de prueba, de acuerdo a la
estrategia de integracin establecida.
Productos: De entrada, Plan de Pruebas, De salida, Plan de Pruebas o
Planificacin de las Pruebas.
Participantes: Jefe de Proyecto
Establecimiento de requisitos de implantacin.
En esta actividad se completa el catlogo de requisitos con aqullos
relacionados con la documentacin que el usuario requiere para operar con el
nuevo sistema, y los relativos a la propia implantacin del sistema en el entorno
de operacin.
La incorporacin de estos requisitos permite ir preparando, en los procesos de
Construccin del Sistema de Informacin (CSI) e Implantacin y Aceptacin del
Sistema (IAS), los medios y recursos necesarios para que los usuarios, tanto
finales como de operacin, sean capaces de utilizar el nueva sistema de forma
satisfactoria.
Tarea
DSI
Especificacin de
Requisitos de
Documentacin de
Usuario
Productos
Tcnicas y Prcticas
Catalogacin
Sesiones de
Trabajo
Participantes
Jefe de Proyecto.
Analistas.
Usuarios
Expertos.
Responsable de
Operacin.
Responsable de
Sistemas.
78
DSI
Especificacin de
Requisitos de
Implantacin
Catalogacin
Sesiones de
Trabajo
Jefe de Proyecto.
Directores de
Usuarios.
Equipo de.
Soporte Tcnico.
1. Especificacin de Requisitos de Documentacin de Usuario.

En esta tarea se recoge toda la informacin necesaria para la especificacin de
la documentacin a entregar al usuario, que incluir los manuales de usuario y,
cuando proceda, los manuales de explotacin. Para ello, es necesario definir,
entre otros, los siguientes aspectos:
Tipo de documentos y estndares a seguir en la elaboracin de los mismos.
Formato en el que se desarrollarn.
Estructura.
Soporte en el que se van a generar.
Distribucin y mantenimiento de la documentacin y copias a editar.
Control de versiones.
2. Especificacin de Requisitos de Implantacin.
En esta tarea se especifican de forma detallada los requisitos de implantacin,
generalmente relacionados con la formacin, infraestructura e instalacin, con
el fin de preparar y organizar, con la antelacin suficiente, todos los recursos
necesarios para la implantacin e instalacin del sistema de informacin.
Teniendo en cuenta las particularidades del sistema de informacin, se
determinan los conocimientos o aptitudes adicionales que requieren los
usuarios finales para operar con el nuevo sistema, al margen de la
funcionalidad soportada por el mismo. Como consecuencia, se pueden
establecer requisitos de formacin indispensables, como condicin previa, para
el desarrollo del plan de formacin que se elaborar en el proceso Implantacin
y Aceptacin del Sistema (IAS).
Los requisitos de infraestructura e instalacin hacen referencia a las
necesidades especiales de equipamiento software, hardware y comunicaciones
exigidos por el nuevo sistema, as como a los tipos de elementos implicados en
la instalacin, que deben tenerse en cuenta al especificar la estrategia de
implantacin, en el proceso Implantacin y Aceptacin del Sistema (IAS).
79

Aprobacin del diseo del sistema de informacin.
Tarea
Presentacin y
DSI
Aprobacin del
Diseo del Sistema
de Informacin
Productos
Tcnicas y
Prcticas
Aprobacin del
Diseo del Sistema de
Participantes
Comit de
Jefe de Proyecto
Presentacin
Informacin
Direccin
1. Presentacin y Aprobacin del Diseo del Sistema de Informacin.

En esta tarea se realiza la presentacin del diseo del sistema de informacin
al Comit de Direccin para la aprobacin final del mismo.
80

TAREA 03: DEFINIR EL CICLO DE VIDA DE DESARROLLO DE SISTEMA.

Entender las actividades generadas para el desarrollo de software.

Sistema operativo Windows.
Acceso a internet.
Software de maquetacin.
INFORMACIN TECNOLGICA:
Identificacin de un conjunto de tareas.
Se tiene que entender que cada accin de la ingeniera de software (por
ejemplo, obtencin, asociada a la actividad de comunicacin) se representa por
cierto nmero de distintos conjuntos de tareas, cada uno de los cuales es una
coleccin de tareas de trabajo de la ingeniera de software, relacionadas con
productos del trabajo, puntos de aseguramiento de la calidad y puntos de
referencia del proyecto. Debe escogerse el conjunto de tareas que se adapte
mejor a las necesidades del proyecto y a las caractersticas del equipo. Esto
implica que una accin de la ingeniera de software puede adaptarse a las
necesidades especficas del proyecto de software y a las caractersticas del
equipo del proyecto.
Patrones del proceso.
Cada equipo de software se enfrenta a problemas conforme avanza en el
proceso del software.
Si se demostrara que existen soluciones fciles para dichos problemas, sera
til para el equipo abordarlos y resolverlos rpidamente. Un patrn del
proceso1 describe un problema relacionado con el proceso que se encuentra
durante el trabajo de ingeniera de software, identifica el ambiente en el que
surge el problema y sugiere una o ms soluciones para el mismo. Dicho de
manera general, un patrn de proceso da un formato: un mtodo consistente
para describir soluciones del problema en el contexto del proceso del software.
Al combinar patrones, un equipo de software resuelve problemas y construye el
proceso que mejor satisfaga las necesidades de un proyecto.
81

Los patrones se definen en cualquier nivel de abstraccin. En ciertos casos, un
patrn puede usarse para describir un problema asociado con un modelo
completo del proceso. En otras situaciones, los patrones se utilizan para
describir un problema asociado con una actividad estructural (por ejemplo,
planeacin) o una accin dentro de una actividad estructural (estimacin de
proyectos).En estos casos se propone un formato para describir un patrn del
proceso:
Nombre del patrn. El patrn recibe un nombre significativo que lo describe en
el contexto del proceso del software (por ejemplo, Revisiones Tcnicas).
Fuerzas. El ambiente en el que se encuentra el patrn y los aspectos que
hacen visible el problema y afectan su solucin.
Tipo. Se especifica el tipo de patrn, sugiere tres tipos:
1. Patrn de etapa: define un problema asociado con una actividad estructural
para el proceso. Como una actividad estructural incluye mltiples acciones y
tareas del trabajo, un patrn de la etapa incorpora mltiples patrones de la
tarea que son relevantes para la etapa (actividad estructural). Un ejemplo de
patrn de etapa sera Establecer Comunicacin. Este patrn incorporara el
patrn de tarea Recabar Requerimientos y otros ms.
2. Patrn de tarea: define un problema asociado con una accin o tarea de
trabajo de la ingeniera de software y que es relevante para el xito de la
prctica de ingeniera de software (por ejemplo, Recabar Requerimientos es
un patrn de tarea). Patrn de fase: define la secuencia de las actividades
estructurales que ocurren dentro del proceso, aun cuando el flujo general de
las actividades sea de naturaleza iterativa. Un ejemplo de patrn de fase es
Modelo Espiral o Prototipos.
3. Contexto inicial. Describe las condiciones en las que se aplica el patrn.
Antes de iniciar el patrn: 1) Qu actividades organizacionales o
relacionadas con el equipo han ocurrido? 2) Cul es el estado de entrada
para el proceso? 3) Qu informacin de ingeniera de software o del
proyecto ya existe? Por ejemplo, el patrn Planeacin (patrn de etapa)
requiere que: 1) los clientes y los ingenieros de software hayan establecido
una comunicacin colaboradora; 2) haya terminado con xito cierto nmero
de patrones de tarea [especificado] para el patrn Comunicacin; y 3) se
conozcan el alcance del proyecto, los requerimientos bsicos del negocio y
las restricciones del proyecto. Problema. El problema especfico que debe
resolver el patrn. Solucin. Describe cmo implementar con xito el patrn.
Esta seccin describe la forma en la que se modifica el estado inicial del
proceso (que existe antes de implementar el patrn) como consecuencia de
la iniciacin del patrn. Tambin describe cmo se transforma la informacin
sobre la ingeniera de software o sobre el proyecto, disponible antes de que
82

inicie el patrn, como consecuencia de la ejecucin exitosa del patrn.
Contexto resultante. Describe las condiciones que resultarn una vez que se
haya implementado con xito el patrn: 1) Qu actividades
organizacionales o relacionadas con el equipo deben haber ocurrido? 2)
Cul es el estado de salida del proceso? 3) Qu informacin sobre la
ingeniera de software o sobre el proyecto se ha desarrollado?
Patrones relacionados. Proporciona una lista de todos los patrones de proceso
directamente relacionados con ste. Puede representarse como una jerarqua o
en alguna forma de diagrama. Por ejemplo, el patrn de etapa Comunicacin
incluye los patrones de tarea:
Equipo Del Proyecto, Lineamientos De Colaboracin, Definicin De Alcances,
Recabar Requerimientos, Descripcin De Restricciones y Creacin De
Escenarios.
Usos y ejemplos conocidos. Indica las instancias especficas en las que es
aplicable el patrn. Por ejemplo, Comunicacin es obligatoria al principio de
todo proyecto de software, es recomendable a lo largo del proyecto y de nuevo
obligatoria una vez alcanzada la actividad de despliegue.
Los patrones de proceso dan un mecanismo efectivo para enfrentar problemas
asociados con cualquier proceso del software. Los patrones permiten
desarrollar una descripcin jerrquica del proceso, que comienza en un nivel
alto de abstraccin (un patrn de fase). Despus se mejora la descripcin como
un conjunto de patrones de etapa que describe las actividades estructurales y
se mejora an ms en forma jerrquica en patrones de tarea ms detallados
para cada patrn de etapa. Una vez desarrollados los patrones de proceso,
pueden reutilizarse para la definicin de variantes del proceso, es decir, un
equipo de software puede definir un modelo de proceso especfico con el
empleo de los patrones como bloques constituyentes del modelo del proceso.
Evaluacin y mejora del proceso.

La existencia de un proceso del software no es garanta de que el software se
entregue a tiempo, que satisfaga las necesidades de los consumidores o que
tenga las caractersticas tcnicas que conducirn a caractersticas de calidad
de largo plazo. Los patrones de proceso deben acoplarse con una prctica
slida de ingeniera de software. Adems, el proceso en s puede evaluarse
para garantizar que cumple con ciertos criterios de proceso bsicos que se
haya demostrado que son esenciales para el xito de la ingeniera de software.
En las ltimas dcadas se han propuesto numerosos enfoques para la
evaluacin y mejora de un proceso del software:
83

Mtodo de evaluacin del estndar CMMI para el proceso de mejora,
proporciona un modelo de cinco fases para evaluar el proceso: inicio,
diagnstico, establecimiento, actuacin y aprendizaje. En pocas palabras el
CMMI como la base de la evaluacin.
Evaluacin basada en CMM para la mejora del proceso interno proporciona
una tcnica de diagnstico para evaluar la madurez relativa de una
organizacin de software; usa el SEI CMM como la base de la evaluacin.
SPICE (ISO/IEC 15504): estndar que define un conjunto de requerimientos
para la evaluacin del proceso del software. El objetivo del estndar es ayudar
a las organizaciones a desarrollar una evaluacin objetiva de cualquier proceso
del software definido.
ISO9001:2000 para software: estndar genrico que se aplica a cualquier
organizacin que desee mejorar la calidad general de los productos, sistemas o
servicios que proporciona.
Por tanto, el estndar es directamente aplicable a las organizaciones y
compaas de software.
84

TAREA 04: DEFINIR LA TECNOLOGA DE OBJETOS.

Entender el ciclo de vida del software.
Comprender las fases y las interacciones.
Implementar los artefactos y UML en el proceso unificado.

Acceso a internet.
FUNDAMENTO TERICO:
Entender el ciclo de vida del software y comprender las fases y las

interacciones.
Modelos de proceso prescriptivo.

Los modelos de proceso prescriptivo fueron propuestos originalmente para
poner orden en el caos del desarrollo de software. La historia indica que estos
modelos tradicionales han dado cierta estructura til al trabajo de ingeniera de
software y que constituyen un mapa razonablemente eficaz para los equipos de
software. Sin embargo, el trabajo de ingeniera de software y el producto que
genera sigue al borde del caos.
En un artculo intrigante sobre la extraa relacin entre el orden y el caos en el
mundo del software, Nogueira y sus colegas afirman lo siguiente:
El borde del caos se define como el estado natural entre el orden y el caos, un
compromiso grande entre la estructura y la sorpresa. El borde del caos se
visualiza como un estado inestable y parcialmente estructurado Es inestable
debido a que se ve atrado constantemente hacia el caos o hacia el orden
absoluto. Tenemos la tendencia de pensar que el orden es el estado ideal de la
naturaleza. Esto podra ser un error las investigaciones apoyan la teora de que
la operacin que se aleja del equilibrio genera creatividad, procesos auto
organizados y rendimientos crecientes. El orden absoluto significa ausencia de
85

variabilidad, que podra ser una ventaja en los ambientes impredecibles. El
cambio ocurre cuando hay cierta estructura que permita que el cambio pueda
organizarse, pero que no sea tan rgida como para que no pueda suceder. Por
otro lado, demasiado caos hace imposible la coordinacin y la coherencia. La
falta de estructura no siempre significa desorden.
Las implicaciones filosficas de este argumento son significativas para la
ingeniera de software.
Si los modelos de proceso prescriptivo buscan generar estructura y orden,
son inapropiados para el mundo del software, que se basa en el cambio?
Pero si rechazamos los modelos de proceso tradicional (y el orden que
implican) y los reemplazamos con algo menos estructurado, hacemos
imposible la coordinacin y coherencia en el trabajo de software?
No hay respuestas fciles para estas preguntas, pero existen alternativas
disponibles para los ingenieros de software. En las secciones que siguen se
estudia el enfoque de proceso prescriptivo en el que los temas dominantes son
el orden y la consistencia del proyecto. El autor los llama prescriptivos porque
prescriben un conjunto de elementos del proceso: actividades estructurales,
acciones de ingeniera de software, tareas, productos del trabajo,
aseguramiento de la calidad y mecanismos de control del cambio para cada
proyecto. Cada modelo del proceso tambin prescribe un flujo del proceso
(tambin llamado flujo de trabajo), es decir, la manera en la que los elementos
del proceso se relacionan entre s.
Todos los modelos del proceso del software pueden incluir las actividades
estructurales generales descritas en el captulo 1, pero cada una pone distinto
nfasis en ellas y define en forma diferente el flujo de proceso que invoca cada
actividad estructural (as como acciones y tareas de ingeniera de software).
1. Modelo de la cascada.
Hay veces en las que los requerimientos para cierto problema se comprenden
bien: cuando el trabajo desde la comunicacin hasta el despliegue fluye en
forma razonablemente lineal. Esta situacin se encuentra en ocasiones cuando
deben hacerse adaptaciones o mejoras bien definidas a un sistema ya
existente (por ejemplo, una adaptacin para software de contabilidad que es
obligatorio hacer debido a cambios en las regulaciones gubernamentales).
Tambin ocurre en cierto nmero limitado de nuevos esfuerzos de desarrollo,
pero slo cuando los requerimientos estn bien definidos y tienen una
estabilidad razonable.
86

El modelo de la cascada, a veces llamado ciclo de vida clsico, sugiere un
enfoque sistemtico y secuencial6 para el desarrollo del software, que
comienza con la especificacin de los requerimientos por parte del cliente y
avanza a travs de planeacin, modelado, construccin y despliegue, para
concluir con el apoyo del software terminado.
Una variante de la representacin del modelo de la cascada se denomina
modelo en V. Se ilustra el modelo en V, donde se aprecia la relacin entre las
acciones para el aseguramiento de la calidad y aquellas asociadas con la
comunicacin, modelado y construccin temprana. A medida que el equipo de
software avanza hacia abajo desde el lado izquierdo de la V, los requerimientos
bsicos del problema mejoran hacia representaciones tcnicas cada vez ms
detalladas del problema y de su solucin. Una vez que se ha generado el
cdigo, el equipo sube por el lado derecho de la V, y en esencia ejecuta una
serie de pruebas (acciones para asegurar la calidad) que validan cada uno de
los modelos creados cuando el equipo fue hacia abajo por el lado izquierdo. En
realidad, no hay diferencias fundamentales entre el ciclo de vida clsico y el
modelo en V. Este ltimo proporciona una forma de visualizar el modo de
aplicacin de las acciones de verificacin y validacin al trabajo de ingeniera
inicial. El modelo de la cascada es el paradigma ms antiguo de la ingeniera
de software. Es raro que los proyectos reales sigan el flujo secuencial
propuesto por el modelo. Aunque el modelo lineal acepta repeticiones, lo hace
en forma indirecta. Como resultado, los cambios generan confusin conforme
el equipo del proyecto avanza.
A menudo, es difcil para el cliente enunciar en forma explcita todos los
requerimientos.
El modelo de la cascada necesita que se haga y tiene dificultades para
aceptar la incertidumbre natural que existe al principio de muchos proyectos.
El cliente debe tener paciencia. No se dispondr de una versin funcional de
los programas hasta que el proyecto est muy avanzado. Un error grande
sera desastroso si se detectara hasta revisar el programa en
funcionamiento.
Hoy en da, el trabajo de software es acelerado y est sujeto a una corriente sin
fin de cambios. El modelo de la cascada suele ser inapropiado para ese tipo de
labor.
87
2. Modelos de proceso incremental.

Hay muchas situaciones en las que los requerimientos iniciales del software
estn razonablemente bien definidos, pero el alcance general del esfuerzo de
desarrollo imposibilita un proceso lineal. Adems, tal vez haya una necesidad
imperiosa de dar rpidamente cierta funcionalidad limitada de software a los
usuarios y aumentarla en las entregas posteriores de software. En tales casos,
se elige un modelo de proceso diseado para producir el software en
incrementos.
El modelo incremental combina elementos de los flujos de proceso lineal. En
relacin el modelo incremental aplica secuencias lineales en forma escalonada
a medida que avanza el calendario de actividades. Cada secuencia lineal
produce incrementos de software susceptibles de entregarse de manera
parecida a los incrementos producidos en un flujo de proceso evolutivo.
Por ejemplo, un software para procesar textos que se elabore con el paradigma
incremental quiz entregue en el primer incremento las funciones bsicas de
administracin de archivos, edicin y produccin del documento; en el segundo
dar herramientas ms sofisticadas de edicin y produccin de documentos; en
el tercero habr separacin de palabras y revisin de la ortografa; y en el
cuarto se proporcionar la capacidad para dar formato avanzado a las pginas.
Debe observarse que el flujo de proceso para cualquier incremento puede
incorporar el paradigma del prototipo.
Cuando se utiliza un modelo incremental, es frecuente que el primer
incremento sea el producto fundamental. Es decir, se abordan los
requerimientos bsicos, pero no se proporcionan muchas caractersticas
88

suplementarias (algunas conocidas y otras no). El cliente usa el producto
fundamental (o lo somete a una evaluacin detallada). Como resultado del uso
y/o evaluacin, se desarrolla un plan para el incremento que sigue. El plan
incluye la modificacin del producto fundamental para cumplir mejor las
necesidades de la organizacin, as como la entrega de caractersticas
adicionales y ms funcionalidad. Este proceso se repite despus de entregar
cada incremento, hasta terminar el producto final.
El modelo de proceso incremental se centra en que en cada incremento se
entrega un producto que ya opera. Los primeros incrementos son versiones
desnudas del producto final, pero proporcionan capacidad que sirve al usuario
y tambin le dan una plataforma de evaluacin.
El desarrollo incremental es til en particular cuando no se dispone de personal
para la implementacin completa del proyecto en el plazo establecido por el
negocio. Los primeros incrementos se desarrollan con pocos trabajadores. Si el
producto bsico es bien recibido, entonces se agrega ms personal (si se
requiere) para que labore en el siguiente incremento. Adems, los incrementos
se planean para administrar riesgos tcnicos. Por ejemplo, un sistema grande
tal vez requiera que se disponga de hardware nuevo que se encuentre en
desarrollo y cuya fecha de entrega sea incierta. En este caso, tal vez sea
posible planear los primeros incrementos de forma que eviten el uso de dicho
hardware, y as proporcionar una funcionalidad parcial a los usuarios finales sin
un retraso importante. Modelos de proceso evolutivo
El software, como todos los sistemas complejos, evoluciona en el tiempo. Es
frecuente que los requerimientos del negocio y del producto cambien conforme
avanza el desarrollo, lo que hace que no sea realista trazar una trayectoria
rectilnea hacia el producto final; los plazos apretados del mercado hacen que
sea imposible la terminacin de un software perfecto, pero debe lanzarse una
versin limitada a fin de aliviar la presin de la competencia o del negocio; se
comprende bien el conjunto de requerimientos o el producto bsico, pero los
detalles del producto o extensiones del sistema an estn por definirse. En
estas situaciones y otras parecidas se necesita un modelo de proceso diseado
explcitamente para adaptarse a un producto que evoluciona con el tiempo.
Los modelos evolutivos son iterativos. Se caracterizan por la manera en la que
permiten desarrollar versiones cada vez ms completas del software. En los
prrafos que siguen se presentan dos modelos comunes de proceso evolutivo.
89
3. Hacer prototipos.
Es frecuente que un cliente defina un conjunto de objetivos generales para el
software, pero que no identifique los requerimientos detallados para las
funciones y caractersticas. En otros casos, el desarrollador tal vez no est
seguro de la eficiencia de un algoritmo, de la adaptabilidad de un sistema
operativo o de la forma que debe adoptar la interaccin entre el humano y la
mquina. En estas situaciones, y muchas otras, el paradigma de hacer
prototipos tal vez ofrezca el mejor enfoque.
Aunque es posible hacer prototipos como un modelo de proceso aislado, es
ms comn usarlo como una tcnica que puede implementarse en el contexto
de cualquiera de los modelos de proceso descritos en este captulo. Sin
importar la manera en la que se aplique, el paradigma de hacer prototipos le
ayudar a usted y a otros participantes a mejorar la comprensin de lo que hay
que elaborar cuando los requerimientos no estn claros.
El paradigma de hacer prototipos comienza con comunicacin. Usted se rene
con otros participantes para definir los objetivos generales del software,
identifica cualesquiera requerimientos que conozca y detecta las reas en las
que es imprescindible una mayor definicin. Se planea rpidamente una
iteracin para hacer el prototipo, y se lleva a cabo el modelado (en forma de un
diseo rpido). ste se centra en la representacin de aquellos aspectos del
software que sern visibles para los usuarios finales (por ejemplo, disposicin
de la interfaz humana o formatos de la pantalla de salida). El diseo rpido
lleva a la construccin de un prototipo. ste se entrega y es evaluado por los
participantes, que dan retroalimentacin para mejorar los requerimientos. La
iteracin ocurre a medida de que el prototipo es afinado para satisfacer las
90

necesidades de distintos participantes, y al mismo tiempo le permite a usted
entender mejor lo que se necesita hacer.
El ideal es que el prototipo sirva como mecanismo para identificar los
requerimientos del software. Si va a construirse un prototipo, pueden utilizarse
fragmentos de programas existentes o aplicar herramientas (por ejemplo,
generadores de reportes y administradores de ventanas) que permitan generar
rpidamente programas que funcionen.
Pero, qu hacer con el prototipo cuando ya sirvi para el propsito descrito?
En la mayora de proyectos es raro que el primer sistema elaborado sea
utilizable. Tal vez sea muy lento, muy grande, difcil de usar o todo a la vez. No
hay ms alternativa que comenzar de nuevo, con ms inteligencia, y construir
una versin rediseada en la que se resuelvan los problemas.
El prototipo sirve como el primer sistema. Lo que se recomienda es
desecharlo. Pero esto quiz sea un punto de vista idealizado. Aunque algunos
prototipos se construyen para ser desechables, otros son evolutivos; es decir,
poco a poco se transforman en el sistema real.
Tanto a los participantes como a los ingenieros de software les gusta el
paradigma de hacer prototipos. Los usuarios adquieren la sensacin del
sistema real, y los desarrolladores logran construir algo de inmediato. No
obstante, hacer prototipos llega a ser problemtico por las siguientes razones:
Los participantes ven lo que parece ser una versin funcional del software,
sin darse cuenta de que el prototipo se obtuvo de manera caprichosa; no
perciben que en la prisa por hacer que funcionara, usted no consider la
calidad general del software o la facilidad de darle mantenimiento a largo
plazo. Cuando se les informa que el producto debe rehacerse a fin de
obtener altos niveles de calidad, los participantes ponen el grito al cielo.
Despus de un tiempo, quiz se sienta cmodo con esas elecciones y olvide
todas las razones por las que eran inadecuadas. La eleccin de algo menos
que lo ideal ahora ha pasado a formar parte del sistema.
Aunque puede haber problemas, hacer prototipos es un paradigma eficaz para
la ingeniera de software. La clave es definir desde el principio las reglas del
juego; es decir, todos los participantes deben estar de acuerdo en que el
prototipo sirva como el mecanismo para definir los requerimientos. Despus se
descartar (al menos en parte) y se har la ingeniera del software real con la
mirada puesta en la calidad.
91
4. El modelo espiral.
El modelo espiral es un modelo evolutivo del proceso del software y se acopla
con la naturaleza iterativa de hacer prototipos con los aspectos controlados y
sistmicos del modelo de cascada. Tiene el potencial para hacer un desarrollo
rpido de versiones cada vez ms completas.
El modelo de desarrollo espiral es un generador de modelo de proceso
impulsado por el riesgo, que se usa para guiar la ingeniera concurrente con
participantes mltiples de sistemas intensivos en software.
Tiene dos caractersticas distintivas principales. La primera es el enfoque
cclico para el crecimiento incremental del grado de definicin de un sistema y
su implementacin, mientras que disminuye su grado de riesgo. La otra es un
conjunto de puntos de referencia de anclaje puntual para asegurar el
compromiso del participante con soluciones factibles y mutuamente
satisfactorias.
Con el empleo del modelo espiral, el software se desarrolla en una serie de
entregas evolutivas.
Durante las primeras iteraciones, lo que se entrega puede ser un modelo o
prototipo. En las iteraciones posteriores se producen versiones cada vez ms
completas del sistema cuya ingeniera se est haciendo.
Un modelo en espiral es dividido por el equipo de software en un conjunto de
actividades estructurales. Para fines ilustrativos, se utilizan las actividades
estructurales generales ya analizadas.
Cada una de ellas representa un segmento de la trayectoria espiral ilustrada. Al
comenzar el proceso evolutivo, el equipo de software realiza actividades
implcitas en un circuito alrededor de la espiral en el sentido horario, partiendo
del centro. El riesgo se considera conforme se desarrolla cada revolucin. En
92

cada paso evolutivo se marcan puntos de referencia puntuales: combinacin de
productos del trabajo y condiciones que se encuentran a lo largo de la
trayectoria de la espiral.
El primer circuito alrededor de la espiral da como resultado el desarrollo de una
especificacin del producto; las vueltas sucesivas se usan para desarrollar un
prototipo y, luego, versiones cada vez ms sofisticadas del software. Cada
paso por la regin de planeacin da como resultado ajustes en el plan del
proyecto. El costo y la programacin de actividades se ajustan con base en la
retroalimentacin obtenida del cliente despus de la entrega. Adems, el
gerente del proyecto ajusta el nmero planeado de iteraciones que se
requieren para terminar el software.
A diferencia de otros modelos del proceso que finalizan cuando se entrega el
software, el modelo espiral puede adaptarse para aplicarse a lo largo de toda la
vida del software de cmputo. Entonces, el primer circuito alrededor de la
espiral quiz represente un proyecto de desarrollo del concepto que comienza
en el centro de la espiral y contina por iteraciones mltiples10 hasta que
queda terminado el desarrollo del concepto. Si el concepto va a desarrollarse
en un producto real, el proceso sigue hacia fuera de la espiral y comienza un
proyecto de desarrollo de producto nuevo. El nuevo producto evolucionar a
travs de cierto nmero de iteraciones alrededor de la espiral. Ms adelante
puede usarse un circuito alrededor de la espiral para que represente un
proyecto de mejora del producto. En esencia, la espiral, cuando se caracteriza
de este modo, sigue operativa hasta que el software se retira. Hay ocasiones
en las que el proceso est inmvil, pero siempre que se inicia un cambio
comienza en el punto de entrada apropiado (por ejemplo, mejora del producto).
El modelo espiral es un enfoque realista para el desarrollo de sistemas y de
software a gran escala. Como el software evoluciona a medida que el proceso
avanza, el desarrollador y cliente comprenden y reaccionan mejor ante los
riesgos en cada nivel de evolucin. El modelo espiral usa los prototipos como
mecanismo de reduccin de riesgos, pero, ms importante, permite aplicar el
enfoque de hacer prototipos en cualquier etapa de la evolucin del producto.
Mantiene el enfoque de escaln sistemtico sugerido por el ciclo de vida
clsico, pero lo incorpora en una estructura iterativa que refleja al mundo real
en una forma ms realista. El modelo espiral demanda una consideracin
directa de los riesgos tcnicos en todas las etapas del proyecto y, si se aplica
de manera apropiada, debe reducir los riesgos antes de que se vuelvan un
problema.
Pero, como otros paradigmas, el modelo espiral no es una panacea. Es difcil
convencer a los clientes (en particular en situaciones bajo contrato) de que el
enfoque evolutivo es controlable.
93
Demanda mucha experiencia en la evaluacin del riesgo y se basa en ella para

llegar al xito.
No hay duda de que habr problemas si algn riesgo importante no se
descubre y administra.
5. Modelos concurrentes.
El modelo de desarrollo concurrente, en ocasiones llamado ingeniera
concurrente, permite que un equipo de software represente elementos
iterativos y concurrentes de cualquiera de los modelos de proceso descritos en
este captulo. Por ejemplo, la actividad de modelado definida para el modelo
espiral se logra por medio de invocar una o ms de las siguientes acciones de
software: hacer prototipos, anlisis y diseo. Muestra la representacin
esquemtica de una actividad de ingeniera de software dentro de la actividad
de modelado con el uso del enfoque de modelado concurrente. La actividad
modelado puede estar en cualquiera de los estados mencionados en un
momento dado. En forma similar, es posible representar de manera anloga
otras actividades, acciones o tareas (por ejemplo, comunicacin o
construccin). Todas las actividades de ingeniera de software existen de
manera concurrente, pero se hallan en diferentes estados.
Por ejemplo, la actividad de comunicacin (no se muestra en la figura) termina
su primera iteracin al principio de un proyecto y existe en el estado de
cambios en espera. La actividad de modelado (que exista en estado inactivo
mientras conclua la comunicacin inicial, ahora hace una transicin al estado
en desarrollo. Sin embargo, si el cliente indica que deben hacerse cambios en
los requerimientos, la actividad de modelado pasa del estado en desarrollo al
de cambios en espera.
94

El modelado concurrente define una serie de eventos que desencadenan
transiciones de un estado a otro para cada una de las actividades, acciones o
tareas de la ingeniera de software.
Por ejemplo, durante las primeras etapas del diseo (accin importante de la
ingeniera de software que ocurre durante la actividad de modelado), no se
detecta una inconsistencia en el modelo de requerimientos. Esto genera el
evento correccin del modelo de anlisis, que disparar la accin de anlisis de
requerimientos del estado terminado al de cambios en espera.
El modelado concurrente es aplicable a todos los tipos de desarrollo de
software y proporciona un panorama apropiado del estado actual del proyecto.
En lugar de confinar las actividades, acciones y tareas de la ingeniera de
software a una secuencia de eventos, define una red del proceso. Cada
actividad, accin o tarea de la red existe simultneamente con otras
actividades, acciones o tareas. Los eventos generados en cierto punto de la red
del proceso desencadenan transiciones entre los estados.
Implementar los artefactos y UML en el proceso unificado.

En los tiempos que corren, el software tiene la tendencia de ser grande y
complejo. Los usuarios demandan interfaces cada vez ms completas y
funcionalidades ms elaboradas, todo ello influyendo en el tamao y la
complejidad del producto final. Por ello, los programas deben ser estructurados
de manera que puedan ser revisados, corregidos y mantenidos, rpida y
eficazmente, por gente que no necesariamente ha colaborado en su diseo y
construccin, permitiendo acomodar nueva funcionalidad, mayor seguridad y
robustez, funcionando en todas las situaciones que puedan surgir, de manera
previsible y reproducible.
Ante problemas de gran complejidad, la mejor forma de abordar la solucin es
modelar. Modelar es disear y estructurar el software antes de lanzarse a
programar y es la nica forma de visualizar un diseo y comprobar que cumple
todos los requisitos para l estipulados, antes de que la flotilla de
programadores comience a generar cdigo. Modelando, los responsables del
xito del producto pueden estar seguros de que su funcionalidad es completa y
correcta, que todas las expectativas de los usuarios finales se cumplen, que las
posibles futuras ampliaciones pueden ser acomodadas, todo ello mucho antes
de que la implementacin haga que los cambios sean difciles o imposibles de
acomodar. Modelando, se abstraen los detalles esenciales de un problema
complejo y se obtiene diseos estructurados que, adems, permiten la
reutilizacin de cdigo, reduciendo los tiempos de produccin y minimizando
las posibilidades de introducir errores.
95

UML es un lenguaje grfico que sirve para modelar, disear, estructurar,
visualizar, especificar, construir y documentar software. UML proporciona un
vocabulario comn para toda la cadena de produccin, desde quien recaba los
requisitos de los usuarios, hasta el ltimo programador responsable del
mantenimiento. Es un lenguaje estndar para crear los planos de un sistema de
forma completa y no ambigua. Fue creado por el Object Management Group,
OMG, un consorcio internacional sin nimo de lucro, que asienta estndares en
el rea de computacin distribuida orientada a objetos, y actualmente revisa y
actualiza peridicamente las especificaciones del lenguaje, para adaptarlo a las
necesidades que surgen. El prestigio de este consorcio es un aval ms para
UML, considerando que cuenta con socios tan conocidos como la NASA, la
Agencia Europea del Espacio ESA, el Instituto Europeo de Bioinformtica EBI,
Boeing, Borland, Motorla y el W3C, por mencionar algunos.
La Orientacin a Objetos (OO).
Aunque UML puede emplearse en cualquier paradigma, como la programacin
estructurada o la lgica, est especialmente cerca del paradigma de la
orientacin a objetos. Por tanto, es precisa una familiarizacin con algunos
detalles de este paradigma antes de continuar con UML.
Qu es un Objeto.
De manera intuitiva, la tendencia general es asociar el trmino objeto con todo
aquello a lo que se puede atribuir la propiedad fsica de masa, como una
tostadora de pan, aunque es posible encontrar objetos de ndole no tangible,
como por ejemplo una direccin postal. En el mbito de la informtica, un
objeto define una representacin abstracta de las entidades del mundo,
tangibles o no, con la intencin de emularlas. Existe pues, una relacin directa
entre los objetos del mundo y los objetos informticos, de modo que puede
emplearse el trmino objeto de manera indistinta.
Los objetos tienen dos caractersticas, que son su estado y su comportamiento.
El estado es una situacin en la que se encuentra el objeto, tal que cumple con
alguna condicin o condiciones particulares, realiza alguna actividad o espera
que suceda un acontecimiento. Una tostadora puede estar encendida y
cargada de pan y, en cuanto a su comportamiento, lo normal en este estado es
tostar pan.
Los objetos mantienen su estado en uno o ms atributos, que son simplemente
datos identificados por un nombre, y exhiben su comportamiento a travs de
mtodos, que son trozos de funcionalidad asociados al objeto. En este sentido,
un objeto es realmente un conjunto de atributos y mtodos. Pero un objeto slo
revela su verdadera utilidad cuando es integrado en un contexto de
96

comunicacin con otros objetos, a travs del envo de mensajes, para
componer un sistema mucho mayor y demostrar un comportamiento ms
complejo. Una tostadora en un armario resulta de poca utilidad, pero cuando
interacta con otro objeto, como un ser humano, se convierte en una
herramienta til para tostar pan. El humano intercambiara con la tostadora el
mensaje tuesta el pan que tienes en la bandeja a travs de la pulsacin del
botn de tostar.
A partir del ejemplo anterior, es fcil deducir que el envo de mensajes es la
forma en que se invocan los mtodos de un objeto y que la invocacin de
mtodos es el mecanismo a travs del cual un objeto puede cambiar su estado
o el de otro objeto. Los atributos y los mtodos de un objeto pueden tener un
menor o mayor grado de visibilidad, desde privado hasta pblico, lo que
hace que aparezca un concepto nuevo, la encapsulacin. La encapsulacin
oculta los detalles del funcionamiento interno del objeto, exponiendo slo
aquello que pueda ser de inters.
Qu es una Clase
Los objetos no son entidades que existan de modo nico. Hay muchos tipos de
tostadoras e, igualmente, muchas tostadoras del mismo tipo. Se puede
entender fcilmente el concepto de clase si nos permitimos emplear el trmino
tipo como equivalente. As, todos los objetos que son del mismo tipo,
comparten el mismo juego de atributos y mtodos (aunque cada objeto pueda
tener un valor distinto asociado a cada atributo) y por tanto pertenecen a una
misma clase. Las clases son como patrones que definen qu atributos y qu
mtodos son comunes a todos los objetos de un mismo tipo.
Cada objeto tiene sus atributos y su comportamiento, creados empleando una
clase a modo de patrn. Una vez creado el objeto, pasa a ser una instancia
particular de la clase a la que pertenece y sus atributos tienen unos valores
concretos, que podrn variar de un objeto a otro (dos objetos distintos
pertenecientes a la misma clase, pueden tener exactamente los mismos
valores en todos sus atributos). A estos atributos, que pueden variar de un
objeto a otro, se les conoce tambin como variables de instancia.
Hay atributos que, sin embargo, no varan de un objeto a otro, es decir todas
las instancias de la clase a la que pertenecen, tienen el mismo valor para ese
atributo. Todas las tostadoras del mismo tipo consumen los mismos Watios y
sus resistencias son de los mismos Ohmios. A estos atributos se les conoce
como variables de clase y son compartidos por todas y cada una de las
instancias de la clase. De manera anloga al caso de los atributos,
encontramos mtodos de instancia y mtodos de clase.
97

Qu es la Herencia.
Los objetos se definen en funcin de clases, es decir, tomando una clase como
patrn. Se puede saber mucho acerca de un objeto sabiendo la clase a la que
pertenece. Por ejemplo, con decir que la Russell Hobbs 10243 Kudos es un
tipo de tostadora, inmediatamente se sabe que se trata de una mquina para
tostar pan, probablemente elctrica y con por lo menos una ranura en la que
insertar una rebanada de pan y un botn para activar su funcionamiento.
Las clases llegan un paso ms lejos, permitiendo su definicin en funcin de
otras clases, de modo que es posible establecer una jerarqua de
especializacin. Una clase que se define en funcin de otra, hereda todos los
atributos y mtodos de aquella y permite el aadido de nuevos o la sobre
escritura de los heredados. La clase patrn se conoce con el nombre de
superclase o clase padre, mientas que la que hereda se conoce como clase
hija. La herencia no est limitada simplemente a padre-hija(s), la jerarqua
puede ser todo lo profunda que sea necesario, hablando en trminos de nietas,
biznietas, etc. De la misma manera, una clase puede heredar de varias clases
a la vez.
En la siguiente figura se puede ver una jerarqua de especializacin de dos
niveles. La clase Animal es la raz, la clase padre en la jerarqua. Especifica
que los animales comen, como caracterstica ms significativa de stos. En el
primer nivel de especializacin encontramos las clases Carnvoro y
Herbvoro, ambas son sendos tipos de animal y por tanto comen, slo que en
el caso de los carnvoros se ha especializado el tipo de comida que comen
para indicar que se trata de carne. Aparece una nueva caracterstica de este
tipo de animal, que es el hecho de que los carnvoros cazan. En el caso de los
herbvoros, encontramos que comen plantas y pacen. En el segundo nivel de
especializacin, encontramos un animal que es a la vez Herbvoro y
Carnvoro y, como cabe esperar, este nuevo tipo de animal puede hacer todo
lo que pueden hacer sus ancestros, comer carne, comer plantas, cazar y pacer,
no encontrando ninguna caracterstica adicional en los Omnvoros.
Qu es una Interfaz.
Una interfaz es un mecanismo que emplean dos objetos para interactuar. En
nuestro ejemplo de la tostadora, el humano emplea el botn de tostar a modo
de interfaz para pasar el mensaje tuesta el pan que tienes en la bandeja.
Las interfaces definen un conjunto de mtodos para establecer el protocolo en
base al cual interactan dos objetos. En este sentido, existe una analoga entre
interfaces y protocolos. Para que el humano pueda tostar, debe seguir el
protocolo establecido por la interfaz botn de tostar, consistente en pulsar dicho
botn. Las interfaces capturan las similitudes entre clases no relacionaras, sin
necesidad de forzar una interrelacin y son a su vez clases.
98

TAREA 05: IMPLEMENTAR DIAGRAMAS CONFORME UML.
Entender la importancia de utilizar UML para el diseo del sistema.
Realizar la configuracin del software.

Acceso a internet.
OPERACIONES.
DIAGRAMA DE CASO DE USO EN RATIONAL ROSE.

3. Ubicar el cursos de mouse en el rea de navegacin y haga clic en la
opcin Use Case View.
4. Haga doble clic en Main.
y por ultimo ingrese el nombre Clientes.
6. Elija el botn Use Case y haga clic en el rea de diseo y por ultimo ingrese
el texto Ganar Dinero.
7. Repita la accin elija el botn Use Case y haga clic en el rea de diseo y
por ultimo ingrese el texto Usar Internet.
el texto Identificar Identidad.
99

desde el actor Cliente hacia el use case Ganar Dinero.
10. Elija el botn Dependency or Instantiates y realice un arrastre desde el
Use Case Usar Internet hacia el actor Cliente.
11. Haga doble clic en la lnea punteada agregada recientemente y del campo
Stereotype seleccione la opcin extend.
12. Elija el botn Dependency or Instantiates y realice un arrastre desde el
Use Case Ganar Dinero hacia el use case Identificar Identidad.
13. Haga doble clic en la lnea punteada agregada recientemente y del campo
Stereotype seleccione la opcin include.
14. Elija el men File y luego la opcin Save As.

15. Ingrese el nombre Ganar dinero Jugando y seleccione una ubicacin,
luego haga clic en Guardar.
DIAGRAMA DE CASO DE USO AUTENTIFICACIN AL SISTEMA.

1. Elija el men File y luego la opcin New.
100

y por ultimo ingrese el nombre Administrador.
6. Repita la accin, elija el botn Actor y haga clic en el rea de diseo para
ingresar la entidad y por ultimo ingrese el nombre Usuario.
7. Agregue tres actores ms con el nombre Invitado, sistema y base de
datos.
el texto Realizar Logueo.
desde el actor Administrador hacia el use case Realizar Logueo.
10. Repetir la misma accin con los tres primeros actores.

desde el use case Realizar loqueo hacia el actor Sistema.
101

el texto Autorizar Ingreso.
desde el actor Sistema hacia el use case Autorizar Ingreso.
11. Repita la accin agregando un use case con el nombre Consultar
Identidad y otro con el nombre Devolver una respuesta.
desde el actor Sistema hacia el use case Consultar Identidad.
13. Elija en el botn Unidirectional Association y realice un arrastre desde el
use case Consultar Identidad hacia actor base de datos.
desde el actor Base de datos hacia el use case Devolver una respuesta.
Repetir la misma accin hacia el actor sistema, quedando el diseo de la
siguiente forma:
8. Elija el botn Use Case e ingrese el texto Verificar Identidad.

9. Haga clic en el botn Unidirectional Association y realice un arrastre desde el
actor Base de datos hacia el use case Verificar Identidad.
10. Elija el men File y luego la opcin Save As.
11. Ingrese el nombre Autentificacin al sistema y seleccione una ubicacin,
luego haga clic en Guardar.
Diagrama de caso de uso de Trmite documentario.

102

y por ultimo ingrese el nombre Cliente.
6. Repita la accin, elija el botn Actor y haga clic en el rea de diseo para
ingresar la entidad y por ultimo ingrese el nombre Secretaria. Agregue dos
actores ms con el nombre Sistema, y Base de datos.
7. Elija el botn Use Case e ingrese el texto Elabora Documento.

desde el actor Cliente hacia el use case Elabora Documento.
el texto Entrega Documento.
10. Ubique el botn Unidirectional Association y realice un arrastre desde el
actor Cliente hacia el use case Entrega Documento.
11. Vuelva a repetir la accin con el botn Unidirectional Association y
realice un arrastre desde el use case Entrega Documento hacia el actor
secretaria.
12. Elija el botn Use Case e ingrese el texto Recepcionar Documento.
desde el actor Secretaria hacia el use case Recepcionar Documento.
14. Elija el botn Use Case y haga clic en el rea de diseo y por ultimo
ingrese el texto Registrar los datos.
15. Vuelva a repetir la accin con el botn Unidirectional Association y
realice un arrastre desde el actor secretaria hacia el use case Registrar
los datos.
16. Elija el botn Use Case e ingrese el texto Sellar el cargo.
103

desde el actor Secretaria hacia el use case Sellar el cargo.
18. Elija el botn Use Case y haga clic en el rea de diseo y por ultimo
ingrese el texto Ingresar datos.
desde el actor Secretaria hacia el use case Ingresar datos y luego de la
misma hacia Sistema.
20. Complete la operacin hasta que el diseo quede de la siguiente forma:
DIAGRAMA DE SECUENCIA Y COLABORACIN.

opcin Logical View y luego en la opcin New y por ltimo en Squense
Diagrama.
104

4. Ingrese el nombre para el diagrama, en este caso para la operacin ser
Ejemplo de Secuencia.
5. Elija el botn object y haga clic en el rea de diseo y por ultimo ingrese el
texto Persona1.
6. Vuelva a repetir la accin con el botn object y haga clic en el rea de
diseo e ingrese el texto Persona2.
7. Haga clic en el botn Object Message y realice un arrastre desde el object
Persona 1 hacia el object Persona 2
El nmero 1 simboliza la
primera accin.
El rectngulo
La lnea
punteada es el
tiempo de vida
vertical indica el
tiempo de vida
de la accin.
de los objetos.
8. Haga doble clic en el nmero uno del diseo e ingrese el siguiente texto
Mensaje 1().
9. Seleccione el botn Return Message y realice un arrastre desde el object
Persona 2 hacia el object Persona 1 y por ultimo haga doble clic en el
nmero dos del diseo e ingrese el siguiente texto Respuesta ().
10. Elija el botn Object Message y realice un arrastre desde el object
Persona 2 hacia el object Persona 1
11. Haga doble clic en el nmero dos del diseo e ingrese el siguiente texto
Mensaje 2().
12. Seleccione el botn Return Message y realice un arrastre desde el object
Persona 1 hacia el object Persona 2 y por ultimo haga doble clic en el
nmero cuatro del diseo e ingrese el siguiente texto Respuesta ().
105
EJEMPLO DE DIAGRAMA DE SECUENCIA Y COLABORACIN PARA LA

GENERACIN DE UNA TARJETA.
3. Ubicar el cursos de mouse en el rea de navegacin y haga clic derecho
Use Case View. Del men contextual seleccione la opcin New y por ultimo
Package. El nombre del paquete ser Actores del sistema
El nombre del
paquete
ser
Actores
del
sistema
4. Haga clic derecho en el package Actores del Sistema y del men

contextual seleccione la opcin New y por ultimo Actor e ingrese el siguiente
nombre: Cajero.
5. Repita la accin de crear un nuevos actores para el package Actores del
Sistema con los siguientes nombres; Especialista en Apertura de cuentas,
Gerente de Agencias, Jefe de turno, Usuario.
106
Actores creados
para el package
Actores del
Sistema
6. Haga clic en el actor Especialista en Apertura de Cuentas y haga clic en

el rea de diseo.
7. Elija el botn object e insertarlo al costado del objeto agregado
anteriormente y por ultimo ingrese el texto Interfaz Principal.
8. Repita la accin de crear un nuevos object para el diseo con los siguientes
nombres; Interfaz Generar Tarjeta; Controlador generar tarjeta; Entidad
Tarjeta; Entidad Cuenta de Ahorro.
9. Elija el botn Object Message y realice un arrastre desde el Especialista

en Apertura de cuentas hacia la Interfaz Principal.
10. Haga doble clic en el nmero uno del diseo e ingrese el siguiente texto
Mensaje 1().
107

11. Seleccione el botn Object Message y realice un arrastre desde el object
Interfaz Principal hacia la Interfaz Generar tarjeta.
12. Haga doble clic en el nmero dos del diseo e ingrese el siguiente texto
Cargar Interfaz.
13. Seleccione el botn Object Message y realice un arrastre desde el actor

Especialista en Apertura de cuentas hacia la Interfaz Generar
tarjeta.
14. Haga doble clic en el nmero tres del diseo e ingrese el siguiente texto
Ingresar nmero de cuenta de ahorro.
15. Repita la accin y elija el botn Object Message y realice un arrastre
desde el actor Especialista en Apertura de cuentas hacia la Interfaz
Generar tarjeta, e ingrese el texto Hacer clic en Generar Tarjeta.
16. Seleccione el botn Object Message y realice un arrastre desde la

Interfaz Generar tarjeta hacia la Controlador Generar tarjeta, e
ingrese el texto Generar Tarjeta.
17. Repita la accin y elija el botn Object Message y realice un arrastre
desde el object Controlador generar tarjeta hacia la Entidad cuenta
de Ahorro, e ingrese el texto Buscar cuenta de Ahorro.
18. Haga clic en el botn Message to Selft y ubicarlo en el Controlador
generar tarjeta e ingrese el nombre Verificar cuenta de Ahorro
108

19. Seleccione el botn Object Message y realice un arrastre desde la
Controlador generar tarjeta hacia la Entidad Tarjeta, e ingrese el
texto Registrar tarjeta.
20. Haga clic en el men Browse y luego en la opcin Go to Collaboration

Diagram
21. Ordene los objetos hasta quedar conforme con el diagrama.
109
FUNDAMENTO TERICO:
Modelos.
Un modelo representa a un sistema software desde una perspectiva especfica.
Al igual que la planta y el alzado de una figura en dibujo tcnico nos muestran
la misma figura vista desde distintos ngulos, cada modelo nos permite fijarnos
en un aspecto distinto del sistema.
Los modelos de UML que se tratan en esta parte son los siguientes:
Diagrama de
Estructura
Esttica.
Diagrama de
Casos de Uso.
Diagrama de
Secuencia.
Diagrama de
Colaboracin.
Diagrama de
Estados.
110

Elementos Comunes a Todos los Diagramas
Notas.
Una nota sirve para aadir cualquier tipo de comentario a un diagrama o a un
elemento de un diagrama. Es un modo de indicar informacin en un formato
libre, cuando la notacin del diagrama en cuestin no nos permite expresar
dicha informacin de manera adecuada.
Una nota se representa como un rectngulo con una esquina doblada con texto
en su interior.
Usuario puede ser cualquiera de

Los actores definidos en el sistema
Dependencias.
La relacin de dependencia entre dos elementos de un diagrama significa que
un cambio en el elemento destino puede implicar un cambio en el elemento
origen (por tanto, si cambia el elemento destino habra que revisar el elemento
origen).
Una dependencia se representa por medio de una lnea de trazo discontinuo
entre los dos elementos con una flecha en su extremo.
Pueden existir
Dependencias entre dos
Elementos cualesquiera
Clase dependiente
Clase de la que depende
Diagramas de Estructura Esttica

Con el nombre de Diagramas de Estructura se engloba tanto al Modelo
Conceptual de la fase de Anlisis como al Diagrama de Clases de la fase de
Diseo. Ambos son distintos conceptualmente, mientras el primero modela
elementos del dominio el segundo presenta los elementos de la solucin
software. Sin embargo, ambos comparten la misma notacin para los
111

elementos que los forman (clases y objetos) y las relaciones que existen entre
los mismos (asociaciones).
Clases.
Una clase se representa mediante una caja subdividida en tres partes: En la
superior se muestra el nombre de la clase, en la media los atributos y en la
inferior las operaciones. Una clase puede representarse de forma esquemtica
(plegada), con los detalles como atributos y operaciones suprimidos, siendo
entonces tan solo un rectngulo con el nombre de la clase. En la Figura 5 se ve
cmo una misma clase puede representarse a distinto nivel de detalle segn
interese, y segn la fase en la que se est.
Objetos.
Un objeto se representa de la misma forma que una clase. En el compartimento
superior aparece el nombre del objeto junto con el nombre de la clase
subrayados, segn la siguiente sintaxis:
nombre_del_objeto: nombre_de_la_clase
Puede representarse un objeto sin un nombre especfico, entonces slo
aparece el nombre de la clase.
Asociaciones
Las asociaciones entre dos clases se representan mediante una lnea que las
une. La lnea puede tener una serie de elementos grficos que expresan
caractersticas particulares de la asociacin. A continuacin se vern los ms
importantes de entre dichos elementos grficos.
Nombre de la Asociacin y Direccin. El nombre de la asociacin es opcional
y se muestra como un texto que est prximo a la lnea. Se puede aadir un
pequeo tringulo negro slido que indique la direccin en la cual leer el
nombre de la asociacin.. Los nombres de las asociaciones normalmente
se incluyen en los modelos para aumentar la legibilidad. Sin embargo, en
ocasiones pueden hacer demasiado abundante la informacin que se
presenta, con el consiguiente riesgo de saturacin. En ese caso se puede
suprimir el nombre de las asociaciones consideradas como suficientemente
conocidas. En las asociaciones de tipo agregacin y de herencia no se
suele poner el nombre.
Multiplicidad a multiplicidad es una restriccin que se pone a una asociacin,
que limita el nmero de instancias de una clase que pueden tener esa
asociacin con una instancia de la otra clase. Puede expresarse de las
siguientes formas:
Con un nmero fijo: 1.
Con un intervalo de valores: 2..5.
112
Con un rango en el cual uno de los extremos es un asterisco. Significa que

es un intervalo abierto. Por ejemplo, 2..* significa 2 o ms.
Con una combinacin de elementos como los anteriores separados por
comas: 1, 3..5, 7, 15..*.
Con un asterisco: * . En este caso indica que puede tomar cualquier valor
(cero o ms).
Roles. Para indicar el papel que juega una clase en una asociacin se puede
especificar un nombre de rol. Se representa en el extremo de la asociacin
junto a la clase que desempea dicho rol.
Agregacin: El smbolo de agregacin es un diamante colocado en el
extremo en el que est la clase que representa el todo.
Clases Asociacin. Cuando una asociacin tiene propiedades propias se
representa como una clase unida a la lnea de la asociacin por medio de
una lnea a trazos. Tanto la lnea como el rectngulo de clase representan el
mismo elemento conceptual: la asociacin. Por tanto ambos tienen el mismo
nombre, el de la asociacin. Cuando la clase asociacin slo tiene atributos
el nombre suele ponerse sobre la lnea (como ocurre en el ejemplo de la
Figura 11). Por el contrario, cuando la clase asociacin tiene alguna
operacin o asociacin propia, entonces se pone el nombre en la clase
asociacin y se puede quitar de la lnea.
Asociaciones N-Arias En el caso de una asociacin en la que participan ms
de dos clases, las clases se unen con una lnea a un diamante central. Si se
muestra multiplicidad en un rol, representa el nmero potencial de tuplas de
instancias en la asociacin cuando el resto de los N-1 valores estn fijos. En
la Figura 12 se ha impuesto la restriccin de que un jugador no puede jugar
en dos equipos distintos a lo largo de una temporada, porque la multiplicidad
de Equipo es 1 en la asociacin ternaria.
Navegabilidad En un extremo de una asociacin se puede indicar la
navegabilidad mediante una flecha. Significa que es posible "navegar" desde
el objeto de la clase origen hasta el objeto de la clase destino. Se trata de un
concepto de diseo, que indica que un objeto de la clase origen conoce al
(los) objeto(s) de la clase destino, y por tanto puede llamar a alguna de sus
operaciones.
Herencia.
La relacin de herencia se representa mediante un tringulo en el extremo de
la relacin que corresponde a la clase ms general o clase padre.
Si se tiene una relacin de herencia con varias clases subordinadas, pero en
un diagrama concreto no se quieren poner todas, esto se representa mediante
puntos suspensivos.
Un elemento derivado es aquel cuyo valor se puede calcular a partir de otros
elementos presentes en el modelo, pero que se incluye en el modelo por
113

motivos de claridad o como decisin de diseo. Se representa con una barra /
precediendo al nombre del elemento derivado.
Diagrama de Casos de Uso.

Un Diagrama de Casos de Uso muestra la relacin entre los actores y los
casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en
lo que se refiere a su interaccin externa.
Los elementos que pueden aparecer en un Diagrama de Casos de Uso son:
actores, casos de uso y relaciones entre casos de uso.
Actores.
Un actor es una entidad externa al sistema que realiza algn tipo de interaccin
con el mismo. Se representa mediante una figura humana dibujada con
palotes. Esta representacin sirve tanto para actores que son personas como
para otro tipo de actores (otros sistemas, sensores, etc.).
Casos de Uso.
Un caso de uso es una descripcin de la secuencia de interacciones que se
producen entre un actor y el sistema, cuando el actor usa el sistema para llevar
a cabo una tarea especfica. Expresa una unidad coherente de funcionalidad, y
se representa en el Diagrama de Casos de Uso mediante una elipse con el
nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar
la tarea especfica que el actor desea llevar a cabo usando el sistema.
Relaciones entre Casos de Uso.
Entre dos casos de uso puede haber las siguientes relaciones:
Extiende: Cuando un caso de uso especializa a otro extendiendo su
funcionalidad.
Usa: Cuando un caso de uso utiliza a otro.
Se representan como una lnea que une a los dos casos de uso relacionados,
con una flecha en forma de tringulo y con una etiqueta <<extiende>> o
<<usa>> segn sea el tipo de relacin.
En el diagrama de casos de uso se representa tambin el sistema como una
caja rectangular con el nombre en su interior. Los casos de uso estn en el
interior de la caja del sistema, y los actores fuera, y cada actor est unido a los
casos de uso en los que participa mediante una lnea.
114

Diagramas de Interaccin.
En los diagramas de interaccin se muestra un patrn de interaccin entre
objetos. Hay dos tipos de diagrama de interaccin, ambos basados en la
misma informacin, pero cada uno enfatizando un aspecto particular:
Diagramas de Secuencia y Diagramas de Colaboracin.
Diagrama de Secuencia.
Un diagrama de Secuencia muestra una interaccin ordenada segn la
secuencia temporal de eventos. En particular, muestra los objetos participantes
en la interaccin y los mensajes que intercambian ordenados segn su
secuencia en el tiempo.
El eje vertical representa el tiempo, y en el eje horizontal se colocan los objetos
y actores participantes en la interaccin, sin un orden prefijado. Cada objeto o
actor tiene una lnea vertical, y los mensajes se representan mediante flechas
entre los distintos objetos. El tiempo fluye de arriba abajo.
Se pueden colocar etiquetas (como restricciones de tiempo, descripciones de
acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones o
activaciones a las que se refieren.
Diagrama de Colaboracin.
Un Diagrama de Colaboracin muestra una interaccin organizada basndose
en los objetos que toman parte en la interaccin y los enlaces entre los mismos
(en cuanto a la interaccin se refiere). A diferencia de los Diagramas de
Secuencia, los Diagramas de Colaboracin muestran las relaciones entre los
roles de los objetos. La secuencia de los mensajes y los flujos de ejecucin
concurrentes deben determinarse explcitamente mediante nmeros de
secuencia.
En cuanto a la representacin, un Diagrama de Colaboracin muestra a una
serie de objetos con los enlaces entre los mismos, y con los mensajes que se
intercambian dichos objetos. Los Mensajes son flechas que van junto al enlace
por el que circulan, y con el nombre del mensaje y los parmetros (si los
tiene) entre parntesis.
Cada mensaje lleva un nmero de secuencia que denota cul es el mensaje
que le precede, excepto el mensaje que inicia el diagrama, que no lleva nmero
de secuencia. Se pueden indicar alternativas con condiciones entre corchetes
(por ejemplo 3 [condicin_de_test] : nombre_de_mtodo() ).
115

Diagrama de Estados.
Un Diagrama de Estados muestra la secuencia de estados por los que pasa un
caso de uso o un objeto a lo largo de su vida, indicando qu eventos hacen que
se pase de un estado a otro y cules son las respuestas y acciones que
genera. En cuanto a la representacin, un diagrama de estados es un grafo
cuyos nodos son estados y cuyos arcos dirigidos son transiciones etiquetadas
con los nombres de los eventos.
Un estado se representa como una caja redondeada con el nombre del estado
en su interior. Una transicin se representa como una flecha desde el estado
origen al estado destino. La caja de un estado puede tener 1 o 2
compartimentos. En el primer compartimento aparece el nombre del estado. El
segundo compartimento es opcional, y en l pueden aparecer acciones de
entrada, de salida y acciones internas.
Una accin de entrada aparece en la forma entrada/accin asociada donde
accin asociada es el nombre de la accin que se realiza al entrar en ese
estado. Cada vez que se entra al estado por medio de una transicin la accin
de entrada se ejecuta.
Una accin de salida aparece en la forma salida/accin asociada. Cada vez
que se sale del estado por una transicin de salida la accin de salida se
ejecuta.
Una accin interna es una accin que se ejecuta cuando se recibe un
determinado evento en ese estado, pero que no causa una transicin a otro
estado. Se indica en la forma nombre_de_evento/accin asociada.
Un diagrama de estados puede representar ciclos continuos o bien una vida
finita, en la que hay un estado inicial de creacin y un estado final de
destruccin (del caso de uso o del objeto). El estado inicial se muestra como un
crculo slido y el estado final como un crculo slido rodeado de otro crculo.
En realidad, los estados inicial y final son pseudoestados, pues un Objeto no
puede estar en esos estados, pero nos sirven para saber cules son las
transiciones iniciales y final(es).
Desarrollo Orientado a Objetos.
Proceso de Desarrollo.
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,
116

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.
Para este curso se va a seguir el mtodo de desarrollo orientado a objetos que
propone Craig Larman [Larman99]. Este proceso no fija una metodologa
estricta, sino que define una serie de actividades que pueden realizarse en
cada fase, las cuales deben adaptarse segn las condiciones del proyecto que
se est llevando a cabo. Se ha escogido seguir este proceso debido a que
aplica los ltimos avances en Ingeniera del Software, y a que adopta un
enfoque eminentemente prctico, aportando soluciones a las principales dudas
y/o problemas con los que se enfrenta el desarrollador. Su mayor aportacin
consiste en atar los cabos sueltos que anteriores mtodos dejan.
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 medio-alto. El proceso est formado por
una serie de actividades y subactividades, cuya realizacin se va repitiendo en
el tiempo aplicado a distintos elementos.
117

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:
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.
Instalacin: La puesta en marcha del sistema en el entorno previsto de uso.
De ellas, la fase de Construir es la que va a consumir la mayor parte del
esfuerzo y del tiempo en un proyecto de desarrollo. Para llevarla a cabo se va
adoptar un enfoque iterativo, tomando en cada iteracin un subconjunto de los
requisitos (agrupados segn casos de uso) y llevndolo a travs del anlisis y
diseo hasta la implementacin y pruebas.
Fase de Planificacin y Especificacin de Requisitos
Esta fase se corresponde con la Especificacin de Requisitos tradicional
ampliada con un Borrador de Modelo Conceptual y con una definicin de Casos
de Uso de alto nivel. En esta fase se decidira si se aborda la construccin del
sistema mediante desarrollo orientado a objetos o no, por lo que, en principio,
es independiente del paradigma empleado posteriormente.
1. Actividades.
Las actividades de esta fase son las siguientes:
Definir el Plan-Borrador.
118

Crear el Informe de Investigacin Preliminar.
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).
Definir la Arquitectura del Sistema-Borrador. (Puede retrasarse hasta una
fase posterior)
Refinar el Plan.
El orden propuesto es el que parece ms lgico. De todos modos, el orden
no es estricto, lo normal es que las distintas actividades se solapen en el
tiempo. Esto sucede tambin en las actividades de las fases de Anlisis y de
Diseo, que se vern ms adelante.
De estas actividades no se va a entrar en las que corresponden al campo de
la planificacin de proyectos software, como las correspondientes a creacin
de planes e informes preliminares.
Tan solo se va a ver por encima la actividad de Definicin de Requisitos en
cuanto est relacionada con los Casos de Uso, pues son stos los que van a
servir de punto de partida en el Anlisis Orientado a Objetos.
2. 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.
119

Para refinar los requisitos y mejorar la comprensin de los mismos la tcnica
de casos de uso constituye una valiosa ayuda.
3. 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 [Jacobson92]. 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.
En la pgina 9 se defini la notacin de UML para los Diagramas de Casos
de Uso. Ntese que UML no define un formato para describir un caso de
uso. Tan slo define la manera de representar la relacin entre actores y
casos de uso en un diagrama (Diagrama de Casos de Uso). El formato
textual que se va a usar en este texto para definir los casos 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.
Fase de Construccin: 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.
120

1. Actividades.
Las actividades de la fase de Anlisis son las siguientes:
Definir Casos de Uso Esenciales en formato expandido. (Si no estn
definidos).
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).
2. 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. Para identificar conceptos hay que
basarse en el documento de Especificacin de Requisitos y en el
conocimiento general acerca del dominio del problema.
En la Tabla se muestran algunas categoras tpicas, junto con ejemplos
pertenecientes al dominio de los supermercados y al de la reserva de billetes
de avin:
Tipo de Concepto
Objetos fsicos o tangibles
Especificaciones, diseos o descripciones de cosas
Lugares
Transacciones
Lneas de una transaccin
Roles de una persona
Ejemplos
Avin
Terminal_de_Caja
Especificacin_de_Producto
Descripcin_de_Vuelo
Supermercado Aeropuerto
Venta, Pago
Reserva
Artculo_de_Venta
Cajero
121

Piloto
Supermercado, Cesta
Contenedores de otras cosas
Avin
Artculo Pasajero
Cosas en un contenedor
Otros ordenadores o sistemas electromecnicos
externos a nuestro sistema
Sistema_de_Autorizacin_de_Tarjetas_de
Crdito
Sistema_Controlador_de_Trfico_Areo
Departamento_de_Ventas
Organizaciones
Compaa_Area_Toto
Venta, Robo, Reunin
Eventos
Vuelo, Accidente, Aterrizaje

Poltica_de_Devoluciones
Reglas y polticas
Poltica_de_Cancelaciones
Catlogo_de_Productos
Catlogos
Catlogo_de_Piezas
Archivos financieros, de trabajo, de contratos, de

asuntos legales
Instrumentos y servicios financieros
Manuales, libros
Recibo,
Contrato_de_Empleo
Registro_de_Revisiones
Lnea_de_Crdito
Stock
Manual_del_Empleado
Manual_de_Reparaciones
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:
Categora
Ejemplos
A es una parte fsica de B
Ala Avin
A es una parte lgica de B
Artculo_en_Venta Venta
A est fsicamente contenido en B
Artculo Estantera
A est 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
A es registrado/archivado/capturado en B
Trabajo_de_Reparacin Registro_de_Reparaciones
Venta Terminal_de_Caja
122
A es un miembro de B
A es una subunidad organizativa de B
A usa o gestiona B
A comunica con B
A est relacionado con una transaccin B
Cajero Supermercado
Piloto Compaa_Aerea
Seccin Supermercado
Mantenimiento Compaa_Aerea
Cajero Terminal_de_Caja
Piloto Avin
Cliente Cajero
Empleado_de_Agencia_de_Viajes Pasajero
Cliente Pago
Pasajero Billete
A es una transaccin relacionada con otra
Pago Venta
transaccin B
Reserva Cancelacin
A est junto a B
Ciudad Ciudad
A posee B
Supermercado Terminal_de_Caja
Compaa_Area Avin
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
pesetas 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.
123

Glosario.
En el glosario debe aparecer una descripcin textual de cualquier elemento de
cualquier modelo, para eliminar toda posible ambigedad.
Un formato tipo para el glosario es el que se muestra en la Tabla 3.
Formato tipo de Glosario.
Trmino
Categora
Realizar Reintegro
caso de uso
Banco
concepto
Descripcin
Descripcin del proceso por el que un Cliente realiza un
reintegro en un cajero automtico.
Entidad que ofrece servicios financieros a sus clientes.
3. 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.
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.
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:
Representar el sistema como un objeto con una lnea debajo.
Identificar los actores que directamente operan con el sistema, y dibujar una
lnea para cada uno de ellos.
124

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.
Opcionalmente, incluir el texto del caso de uso en el margen del diagrama.
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 que 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:
La descripcin de cada apartado de un contrato es como sigue:
Nombre:
Nombre de la operacin y parmetros.
Responsabilidades:
Una descripcin informal de las responsabilidades que la operacin debe

desempear.
Referencias
Cruzadas:
Nmeros de referencia en los requisitos de funciones del sistema, casos de uso,

etc.
Notas:
Comentarios de diseo, algoritmos, etc.
Excepciones:
Casos excepcionales. Situaciones que debemos tener en cuenta que pueden

pasar. Se indica tambin qu se hace cuando ocurre la excepcin.
125
Salida:
Salidas que no corresponden a la interfaz de usuario, como mensajes o registros

que se envan fuera del sistema. (En la mayor parte de las operaciones del
sistema este apartado queda vaco)
Pre-condiciones:
Asunciones acerca del estado del sistema antes de ejecutar la operacin.

Algo que no tenemos en cuenta que pueda ocurrir cuando se llama a esta
operacin del sistema.
Post-condiciones:
El estado del sistema despus de completar la operacin.
Los pasos a seguir para construir un contrato son los siguientes:

Identificar las operaciones del sistema a partir de los Diagramas de Secuencia
del Sistema.
Para cada operacin del sistema construir un contrato.
Empezar escribiendo el apartado de Responsabilidades, describiendo
informalmente el propsito de la operacin. Este es el apartado ms importante
del contrato.
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).
Para describir las post-condiciones, usar las siguientes categoras:
Creacin y borrado de instancias.
Modificacin de atributos.
Asociaciones formadas y retiradas.
Completar el resto de apartados en su caso.
4. Diagramas de Estados.
Para modelar el comportamiento del sistema pueden usarse los Diagramas de
Estados que define UML (ver pgina 12).
Se puede aplicar un Diagrama de Estados al comportamiento de los siguientes
elementos:
Una clase software.
Un concepto.
Un caso de uso.
126

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.
Fase de Construccin: 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:
Definir los Casos de Uso Reales.
Definir Informes e Interfase de Usurio.
Refinar la Arquitectura del Sistema.
Definir los Diagramas de Interaccin.
Definir el Diagrama de Clases de Diseo. (en paralelo con los Diagramas de
Interaccin)
Definir el Esquema de Base de Datos.

El paso de Refinar la Arquitectura del Sistema 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
127

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:
Diagramas de Colaboracin.
Diagramas de Secuencia.
La notacin en UML para ambos es la definida en la pgina 10.
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.
128

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.
Booch, Rumbaugh y Jacobson definen responsabilidad como un contrato u
obligacin de una clase o tipo[BJR97]. 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:
Hacer algo l mismo. Iniciar una accin en otros objetos.
Controlar y coordinar actividades en otros objetos.
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.
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.
Relaciones de Dependencia para Representar Visibilidad entre Clases.
129

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:
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 <<parmetro>> (<<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>>.
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.
Construccin de un Diagrama de Clases de Diseo.
Para crear un Diagrama de Clases de Diseo se puede seguir la siguiente
estrategia:
- Identificar todas las clases participantes en la solucin software. Esto se
lleva a cabo analizando los Diagramas de Interaccin.
- Representarlas en un diagrama de clases.
- 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.
130

- 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.
- Aadir relaciones de dependencia para indicar visibilidad no correspondiente
a atributos.
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.
Como se vio en la parte II, 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:
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:
131

+ 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 (ver seccin III.2.5). 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.
132

TAREA 06: DIAGRAMAR UTILIZANDO EL PROCESO DE DESARROLLO
DE SOFTWARE (RUP)

Reconocer los requisitos para el diagrama de caso de uso.
Definir e identificar el caso de uso y sus relaciones.

Acceso a internet.
FUNDAMENTO TECNOLGICO:
RUP es una metodologa slida, con documentacin que apoya el ciclo de vida
evolutivo incremental, adems de orientarse al desarrollo de componentes
secundando el desarrollo orientado a objetos RUP es un proceso de ingeniera
de software que provee un enfoque disciplinado para la asignacin de tareas y
responsabilidades dentro de una organizacin. Su principal objetivo es
asegurar la produccin de software de alta calidad que satisfaga las
necesidades de sus usuarios finales dentro de un presupuesto y tiempo
predecibles.
Debido a las caractersticas que posee de ser una herramienta flexible, le
permite un marco de trabajo ms amplio el cual puede ser adaptado tanto a
empresas grandes como pequeas y puede ser modificada para ajustarse a la
forma de trabajo de una compaa.
El Proceso Unificado tiene dos dimensiones:
Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo
de vida del proceso a lo largo de su desenvolvimiento.
Un eje vertical que representa las disciplinas, las cuales agrupan actividades
de una manera lgica de acuerdo a su naturaleza.
La primera dimensin representa el aspecto dinmico del proceso conforme se
va desarrollando, se expresa en trminos de fases, iteraciones e hitos.
133

La segunda dimensin representa el aspecto esttico del proceso: cmo es
descrito en trminos de componentes del proceso, disciplinas, actividades,
flujos de trabajo, artefactos y roles.
Caractersticas de RUP.
Interactivo. Refinamiento sucesivo.

Controlado. Gestin de requisitos y control de cambios
Construccin de modelos.
Centrado en arquitectura.
Desarrollo de software basado en componentes.
Conducido por los casos de uso.
Soporta tcnicas OO (Orientadas a objetos) uso del UML.
Configurable.
Fomenta al control de calidad del software.
Soportado por herramientas.
Reconoce que las necesidades del usuario y sus requerimientos no se pueden

definir completamente al principio.
Permite evaluar tempranamente los riesgos en lugar de descubrir problemas en
la integracin final del sistema. Reduce el costo del riesgo a los costos de un
solo incremento.
Acelera el ritmo del esfuerzo de desarrollo en su totalidad debido a que los
desarrolladores trabajan para obtener resultados claros a corto plazo.
Distribuye la carga de trabajo a lo largo del tiempo del proyecto ya que todas
las disciplinas colaboran en cada iteracin. Facilita la reutilizacin del cdigo
teniendo en cuenta que se realizan revisiones en las primeras iteraciones lo
cual adems permite que se aprecien oportunidades de mejoras en el diseo.
El proceso de desarrollo est dividido en Fases a lo largo del tiempo cada una
de las cuales tiene objetivos especficos y un conjunto de artefactos definidos
que deben alcanzarse. La duracin de cada fase depende del equipo y del
producto a generar. A su vez, cada fase puede tener una o ms iteraciones y
cada iteracin sigue el modelo en cascada pasando por las distintas disciplinas.
Cada iteracin termina con una liberacin del producto.
Principio de desarrollo:
Adaptar el Proceso:
El proceso deber adaptarse a las caractersticas propias del proyecto u
organizacin, El tamao del mismo, as como su tipo o las regulaciones que lo
134

condicionen, influirn en su diseo especfico. Tambin se deber tener en
cuenta el alcance del proyecto.
Balancear prioridades:
Los requerimientos de los diversos participantes pueden ser diferentes,
contradictorios o disputarse recursos limitados. Debe encontrarse un balance
que satisfaga los deseos de todos.
Demostrar valor iterativamente:
Los proyectos se entregan, aunque sea de un modo interno, en etapas
iteradas. En cada iteracin se analiza la opinin de los inversores, la estabilidad
y calidad del producto, y se refina la direccin del proyecto as como tambin
los riesgos involucrados.
Elevar el nivel de abstraccin:
Este principio dominante motiva el uso de conceptos reutilizables tales como
patrn del software, lenguajes 4GL1 o marcos de referencia (frameworks) por
nombrar algunos. Esto evita que los ingenieros de software vayan directamente
de los requisitos a la codificacin de software a la medida del cliente, sin saber
con certeza qu codificar para satisfacer de la mejor manera los requerimientos
y sin comenzar desde un principio pensando en la reutilizacin del cdigo. Un
alto nivel de abstraccin tambin permite discusiones sobre diversos niveles y
soluciones arquitectnicas. stas se pueden acompaar por las
representaciones visuales de la arquitectura, por ejemplo con el lenguaje UML.
Enfocarse en la Calidad:
El control de calidad no debe realizarse al final de cada iteracin, sino en todos
los aspectos de la produccin. El aseguramiento de la calidad forma parte del
proceso de desarrollo y no de un grupo independiente
Ciclo de vida de RUP.
El ciclo de vida RUP es una implementacin del Desarrollo en espiral. El ciclo
de vida organiza las tareas en fases e iteraciones.
135
Deterninar Objetivos
Analisis de Riesgo
Planificacin
Desarrollo y Probar
Fases RUP.
La metodologa RUP, llamada as por sus siglas en ingls Rational Unified
Process, divide en 4 fases el desarrollo del software. Cada Fase tiene definido
un conjunto de objetivos y un punto de control especfico.
Fase
Objetivos
Definir el alcance del proyecto
Inicio
Elaboracin
Construccin
Puntos de Control
Objetivo del proyecto
Entender que se va a construir

Construir una versin ejecutable de
la arquitectura de la aplicacin
Arquitectura
Aplicacin
de
la
Entender cmo se va a construir
Completar el esqueleto de la
Aplicacin con la funcionalidad
Versin Operativa Inicial de

la Aplicacin
Construir una versin Beta

Transicin
Poner a disposicin la aplicacin

para los usuarios finales
Liberacin de la versin de
la Aplicacin
Construir la versin Final
136

Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la
cual consiste en reproducir el ciclo de vida en cascada a menor escala. Los
Objetivos de una iteracin se establecen en funcin de la evaluacin de las
iteraciones precedentes.
Fase de Inicio:
Durante la fase reinicio se desarrolla una descripcin del producto final, y se
presenta el anlisis del negocio. Esta fase responde las siguientes preguntas:
Cules son las principales funciones del sistema para los usuarios ms
importantes? Cules podra ser la mejor arquitectura del sistema?
En estas fases se identifican y priorizan los riesgos ms importantes.
Artefactos que tpicamente sobreviven en esta fase.
Un enunciado de los mayores requerimientos planteados generalmente como
casos de uso.
137
5
4
3
2
1
Boceto inicial
de la
arquitectura
Descripcin de
los objetivos
del proyecto
Versin
preliminar del
plan del
proyecto.
Caso de
negocio y
alcance de
proyecto
Modelo de
negocio
10
9
8
7
6
Plan de proyecto
Modelo inicial de
casos de uso
Identificacin
inicial de riesgos
Uno o ms
prototipos
Documento de
visin general
SE ESTABLECE EL ALCANCE Y LA ESTIMACIN DE TIEMPO Y COSTO.

Fase de elaboracin:
Durante la fase de elaboracin se especifican en detalle la mayora de los
casos de uso del producto y se disea la arquitectura.
Las iteraciones en la fase de elaboracin.
Establecen una firme compresin del problema a solucionar.
Establece la fundacin arquitectural para el software.
Establece un plan detallado para las siguientes iteraciones.
Elimina los mayores riesgos.
El resultado de esta fase es la lnea base de la arquitectura.
En esta fase se construyen tpicamente los siguientes artefactos.
138
5
4
3
2
1
Prototipo
arquitectural
Casos de
prueba.
casos de uso
que describen
la
funcionalidad
del sistema.
Analizar el
dominio del
problema
Eliminar los
elementos de
mayor riesgo
10
9
8
7
6
Se realizan
pruebas de
riesgos.
Analizar el
dominio del
problema .
Eliminar los
elementos de
mayor riesgo
Marca de
Arquitectura.
Se realizan
pruebas de
riesgos
Un plan detallado para las siguientes iteraciones:

La fase de elaboracin finaliza con el hito de la arquitectura del ciclo de vida,
este hito se alcanza cuando el equipo de desarrollo y los stakeholders llegan a
un acuerdo sobre:
Los casos de uso que describen la funcionalidad del sistema.
La lnea base de la arquitectura.
Los mayores riesgos han sido mitigados.
El plan de proyecto.
Fase de construccin:
Durante la fase de construccin se crea el producto. La lnea base de la
arquitectura crece hasta convertirse en el sistema completo
139

Al final de esta fase, el producto contiene todos los casos de uso
implementados, sin embargo puede que no est libre de defectos Los
artefactos producidos en esta fase son:
El sistema
software
Los
componente
s se
desarrollan
e incorporan
al producto
Los casos
de prueba
5
Todo es
probado
para
eliminar
posibles
errores y
riesgos
Los
manuales
de usuario
6
Marca de
Capacidad.
Se obtiene un producto Beta que debe ser puesto en ejecucin para que los
usuarios den retroalimentacin.
La fase de construccin finaliza con el hito de capacidad operativa inicial, este
hito se alcanza cuando el equipo de desarrollo y los stakeholders llagan a un
acuerdo sobre:
El producto es estable para ser usado.
El producto provee alguna funcionalidad de valor.
Todas las partes estn listas para comenzar la transicin.
Fase de transicin.
La fase de transicin cubre el perodo durante el cual el producto se convierte
en la versin beta.
Sin embargo, las caractersticas se agregan a un sistema que el usuario se
encuentra utilizando activamente (ambiente de desarrollo).
Los artefactos construidos en esta fase son el mismo que en la fase de
construccin. El equipo se encuentra ocupando fundamentalmente en corregir
y extender la funcionalidad del sistema desarrollado en la fase anterior.
140

El objetivo es realizar el lanzamiento del software desarrollado a los usuarios.
Pruebas Beta para validar el producto con la retroalimentacin del usuario.
Conversin de bases de datos.
Enviar el producto a otros lados donde tambin se va a usar el producto.
Marca de Producto.
Usuarios satisfechos.
Verificacin de gastos.
La fase de transicin finaliza con el hito de lanzamiento del producto.
Elementos de rup.
Actividades, Son los procesos que se llegan a determinar en cada iteracin.
Trabajadores, Vienen hacer las personas o entes involucrados en cada
proceso.
Artefactos, Un artefacto puede ser un documento, un modelo, o un
elemento de modelo.
Disciplinas primarias y secundarias o de apoyo: Una disciplina es una
coleccin de actividades relacionadas con un rea de atencin dentro de
todo el proyecto.
Actividad:
Los trabajadores realizan actividades. Una actividad es algo que se realiza
para proveer un resultado de valor en el contexto de un proyecto.
Trabajador (ROL):
Un trabajador o rol, define un comportamiento o responsabilidades de un
individuo o grupo de individuos trabajando en equipo, en el contexto de una
organizacin de ingeniera de software.
Sugerencias para identificar adecuadamente los trabajadores del negocio: Son
roles (Humanos, software o hardware) no personas con nombres propios.
Se encuentran dentro de las fronteras del negocio o campo de accin.
No deben representar reas, departamentos o parte de una organizacin sino
roles de ejecucin.
Cada trabajador debe participar en al menos un caso de uso del negocio. Si no
participa en ningn proceso debe ser eliminado del modelo.
141

Artefactos:
Las actividades tienen artefactos de entrada y de salida, un artefacto es un
producto de trabajo de un proceso: los trabajadores utilizan artefactos para
realizar actividades y producen artefactos como resultado de sus actividades.
Los artefactos son responsabilidad de un nico trabajador y promueven la
idea de que toda pieza de informacin en el proceso debe ser responsabilidad
de un rol especifico, un trabajador es el propietario de un artefacto, pero otros
trabajadores pueden usarlo y tal vez modificarlo si tienen permisos para ello.
Actividades Primarias y secundarias o de (apoyo):
Una disciplina es una coleccin de actividades relacionadas con un rea de
atencin dentro de todo el proyecto. El grupo de actividades que se encuentran
dentro de una disciplina principalmente son una ayuda para entender el
proyecto desde la perspectiva clsica de cascada.
Las disciplinas son:
Modelado de
Negocios,
Requerimientos,
Anlisis y Diseo,
Implementacin,
Pruebas, Transicin,
Actividades de poyo y
Diseo,
Configuracin y Administracin
del Cambio,
Administracin de Proyectos y
Ambiente.
142

TAREA 07: IMPLEMENTAR
COLABORACIN.
DIAGRAMAS
DE
SECUENCIAS

Reconocer los requisitos para el diagrama de secuencia y colaboracin.
Identificar la representacin grfica de los elementos.

Acceso a internet.
OPERACIONES:
DIAGRAMA DE SECUENCIA EN ArgoUML.
2. Haga clic en la derecho opcin Modelo sin ttulo ubicado en el panel de
navegacin (lado izquierdo), luego elija la opcin Crear elemento del
modelo y por ultimo Crear Paquete.
3. Ingrese el nombre Sistemas en el rea de propiedades, ubicado en la parte

inferior (Como lo muestra la imagen).
143
4. Haga clic en la derecho opcin paquete Sistemas ubicado en el panel de

navegacin (lado izquierdo), luego elija la opcin Crear elemento del
modelo y por ultimo Actor Nuevo.
5. Ingrese el nombre Cliente en el rea de propiedades, ubicado en la parte
inferior.
6. Repita la accin e ingrese los siguientes elementos: Sitio Web de
Ventas, DNCustomer Server, DNKitchenServer, Autorizacin de Pago.
7. Haga clic en la derecho opcin paquete Sistemas y luego elija la opcin
Crear diagrama y por ultimo Diagrama de secuencia.
8. Ingrese el siguiente nombre para el diagrama Ecommerce en el rea de

propiedades, ubicado en la parte inferior.
9. Elija el elemento cliente y realice un arrastre hacia el rea de diseo.
144
10. Repita la accin, elija los elementos Sitio Web de Ventas, DNCustomer
Server, DNKitchen Server, Autorizacin de Pago y agregarlos al rea de
diseo.
11. Elija el siguiente botn.
Y realice el arrastre del acto Cliente hacia Sitio Web de Ventas. Luego
haga doble clic en la lnea e ingrese el texto Agregar elemento del carro
de compra.
12. Repetir la accin hasta que el diseo quede de la siguiente manera.
145
DIAGRAMA DE COLABORACIN EN StarUML.

2. Haga clic derecho en la opcin UseCaseModel y luego en la opcin Add
Diagram y por ltimo en Collaboration Diagram.
3. Haga clic en el botn objetc y haga clic en el rea de diseo.
146
Seleccione el botn Link y realice

un arrastre desde el objeto
Formulario hacia Lista de
Candidato.
4. Haga doble clic en la lnea recin insertada e ingrese el nombre Buscar

Candidato.
5. Realizar el diagrama hasta que termine de la siguiente forma:
147

FUNDAMENTO TERICO.
Diagrama de Secuencia.
Este diagrama muestra la interaccin de los objetos entre ellos. Es importante
comentar que hasta este momento no se han considerado objetos tcnicos. En
UML, durante el Anlisis de los requerimientos y el Anlisis, no se consideran
objetos tcnicos que definan detalles y soluciones en el sistema de software,
tales como objetos para interfaces de usuario, bases de datos,
comunicaciones, etc. Todos esos objetos se consideran hasta el diseo del
sistema.
En este diagrama se observa que slo se consideran algunos objetos y es
importante aclarar que estos no sern todos los objetos a considerar dentro del
sistema, ya que todava es posible agregar nuevos objetos que no se haban
considerado en el dominio del anlisis as como los objetos tcnicos, como se
mencion anteriormente. Los objetos considerados se representan en
rectngulos con el nombre subrayado y cada uno cuenta con su lnea de vida
vertical que muestra la vida del objeto.
Diagrama de colaboracin.
As mismo, se cuenta con el diagrama de colaboracin se centra tanto en las
interacciones y las ligas entre un conjunto de objetos colaborando entre ellos
(una liga es una instancia de una asociacin). Ambos, el diagrama de
secuencia y el diagrama de colaboracin, muestran interacciones, pero el
diagrama de secuencia se centra en el tiempo mientras que el diagrama de
colaboracin se centra en el espacio. Las ligas muestran los objetos actuales y
cmo ellos se relacionan unos con otros. As como los diagramas de
secuencia, los diagramas de colaboracin pueden ser utilizados para ilustrar la
ejecucin de una operacin, una ejecucin de un use-case o simplemente un
escenario de interaccin dentro del sistema. En este diagrama tambin se
representa a los objetos en cajas rectangulares y con el nombre subrayado.
Las ligas se dibujan con lneas y se puede agregar una etiqueta para un
mensaje y un nmero que define la secuencia de las ligas.
148

TAREA 08: IMPLEMENTAR DIAGRAMAS DE CLASE Y OBJETOS,
ESTADOS Y ACTIVIDAD.

Realizar la representacin grfica.
Identificar el comportamiento, relaciones entre las clases y los casos
particulares.

Acceso a internet.
OPERACIONES.
DIAGRAMA DE CLASE EN ArgoUML.

2. Haga clic en la opcin Modelo sin ttulo ubicado en el panel de navegacin
(lado izquierdo), de esta forma se ingresara un nuevo nombre para el
proyecto.
3. Ingrese el nombre Publicaciones en el rea de propiedades, ubicado en la
parte inferior (Como lo muestra la imagen).
4. Active la visibilidad Pblica.
Ingresar
los
datos
correspondientes.
5. Haga clic en el icono de Diagrama de Clase.
149
6. Ingrese el nombre para el nuevo diagrama, para la prctica ser Diagrama

de Clases.
7. Haga clic en el botn Clase Nueva.
8. Haga un clic en el Panel de Edicin para agregar el objeto seleccionado.
Clase
Agregada
9. Teniendo seleccionada la clase, se podr agregar un nombre. En el rea de

propiedades, en la seccin nombre, ingrese el texto Publicacin.
150
10. Elija el botn Atributo nuevo.
11. Teniendo agregado el atributo, se podr agregar un nombre. En el rea de

propiedades, en la seccin nombre, ingrese el texto Editor.
12. En la opcin Tipo, seleccin String.
151

13. Haga clic en el botn Atributo nuevo.
propiedades, en la seccin nombre, ingrese el texto Fecha.
15. En la opcin Tipo, seleccione String.
16. Agregar una operacin, para ello haga clic en el botn Agregar operacin.
17. En el campo nombre Ingresar el texto Publicacin, que terminara siendo el

constructor por defecto.
18. Se repite la accin de agregar una operacin, para ello haga clic en el
botn Agregar operacin.
19. En el campo nombre Ingresar el texto Publicacin.
20. Haga clic en el botn + de Parmetro, para agregar uno. Y seleccione la
opcin Agregar parmetro.
152
21. En el campo nombre Ingresar el texto Editor.

23. Se repite la accin de agregar un nuevo parmetro, para ello haga clic en el
botn Agregar parmetro.
24. En el campo nombre Ingresar el texto Fecha.
26. Se repite la accin de agregar una operacin, para ello haga clic en el
botn Agregar operacin.
27. Se proceder agregar los getters y setters.
Los Setters & Getters son mtodos de acceso lo que indica

que son siempre declarados pblicos.
Setters: Sirve para asignar un valor inicial a un atributo, pero de forma

explcita, adems el Setter nunca retorna nada, y solo permite dar
acceso pblico a ciertos atributos que se desea, adems el usuario
pueda modificar.
153

Getters: sirve para obtener (recuperar o acceder) el valor ya asignado a
un atributo y utilizarlo para cierto mtodo.
28. En el campo nombre Ingresar el texto getEditor y luego especifique que
tipo de datos devolver, para el ejemplo. Haga doble clic en return y luego
seleccione el tipo de datos String.
29. Haga clic en el botn retornar.
30. Haga clic en el botn Agregar operacin y en el campo nombre Ingresar

el texto getFeha y luego especifique que tipo de datos devolver, para el
ejemplo. Haga doble clic en return y luego seleccione el tipo de datos
String.
31. Haga clic en el botn retornar y luego en el botn Agregar operacin.
32. En el campo nombre ingrese el texto setEditor y luego haga clic en el
33. En el campo nombre Ingresar el texto Editor y seleccione el tipo de datos
String.
34. Haga clic en el botn retornar y luego en el botn Agregar operacin.
35. En el campo nombre ingrese el texto setFecha y luego haga clic en el
36. En el campo nombre Ingresar el texto Fecha y seleccione el tipo de datos
String.
154

CREAR UNA NUEVA CLASE CON EL NOMBRE LIBRO.

3. Ingrese el nombre Libro en el rea de propiedades, ubicado en la parte
Ingresar
los
datos
correspondientes.

propiedades, en la seccin nombre, ingrese el texto ISBN.
7. En la opcin Tipo, seleccin String.
8. En el campo de Visibilidad, active la opcin privado.
155

propiedades, en la seccin nombre, ingrese el texto autor.
el texto Libro.
14. Repita la accin de Agregar operacin y en el campo nombre Ingresar el
texto Libro (una vez ms).
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
En el campo nombre Ingresar el texto ISBN.

En la opcin Tipo, seleccione String.
Repita la accin para agregar un nuevo parmetro.
En el campo nombre Ingresar el texto Autor.
Haga clic en el botn retornar y luego en el botn Agregar operacin.
En el campo nombre ingrese el texto getISBN.
Haga doble clic en la opcin return.
En el campo nombre ingrese el texto getAutor.
En el campo nombre ingrese el texto setISBN.
Haga clic en el botn + de Parmetro, para agregar uno. Y seleccione la
En el campo nombre ingrese el texto ISBN.
En el campo nombre ingrese el texto setAutor.
En el campo nombre ingrese el texto Autor.
156

CREAR UNA NUEVA CLASE CON EL NOMBRE LIBRO.

3. Ingrese el nombre Revista en el rea de propiedades, ubicado en la parte
Ingresar
los
datos
correspondientes.

propiedades, en la seccin nombre, ingrese el texto NumerosporAo.
7. En la opcin Tipo, seleccin Integer.

propiedades, en la seccin nombre, ingrese el texto NumerosVentasAo.
157

11. En la opcin Tipo, seleccione Integer.
el texto Revista.
14. Repita la accin de Agregar operacin y en el campo nombre Ingresar el
texto Revista (una vez ms).
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
En el campo nombre Ingresar el texto NumerosporAo.

En la opcin Tipo, seleccione Integer.
Repita la accin para agregar un nuevo parmetro.
En el campo nombre Ingresar el texto NumerosVentasAo.
En el campo nombre ingrese el texto getNumerosporAo.
En el campo nombre ingrese el texto getNumerosVentasAo.
En el campo nombre ingrese el texto setNumerosporAo.
En el campo nombre ingrese el texto NumerosporAo.
En el campo nombre ingrese el texto setNumerosVentasAo.
En el campo nombre ingrese el texto NumerosVentasAo.
158

CREAR LAS RELACIONES ENTRE LAS DISTINTAS CLASES.
1. Haga clic en el botn Crear Generalizacin.
2. Haga un clic sostenido desde la clase Libro y arrastre hasta la clase

Publicacin, quedando de la siguiente forma.
3. Mantener la seleccin activa y en el rea de propiedades ingrese un nombre

e identificador a la relacin.
159

4. Haga clic en el botn Crear Generalizacin.
5. Haga un clic sostenido desde la clase Revista y arrastre hasta la clase
Publicacin, quedando de la siguiente forma.
6. Mantener la seleccin activa y en el rea de propiedades ingrese un nombre

e identificador a la relacin.
7. Haga clic en el men Archivo y luego en la opcin Guardar Proyecto.

GENERAR EL CDIGO JAVA DE LA CLASE.
1. Haga clic en el botn seleccionar y con dicha herramienta genere el arrastre
para seleccionar todas las clases.
2. Elija el men Generar y luego la opcin Generar clases escogidas.

3. Activar las opciones de Java.
160
Haga clic en Buscar y

luego seleccionar la
opcin Desktop.
4. Haga clic en Generar.

DIAGRAMA DE ESTADO EN RATIONAL ROSE.
Es empleado para diagramar los estados por los cuales pasara el sistema,
tambin muestra lo que podra suceder despus de un determinado evento.
3. Ubicar el cursos de mouse en el rea de navegacin y haga clic derecho en
la opcin Logical View y luego en new.
4. Haga clic en la opcin Statechart Diagram.
Haga clic en la opcin

Statechart Diagram.
5. Ingrese el nombre para el diagrama; Ejemplo de diagrama de estados,

luego haga clic en el botn Start State para iniciar el diagrama.
161
Haga clic en el botn

Start State.
6. Elija el botn State e ingrese el texto descolgar sin marcar.
7. Haga clic derecho en el state ingresado hace unos instantes y luego

seleccionar la opcin Open Specification.
8. Elija la pestaa Action y en el espacio en blanco, haga clic en Insert, se
podr observar que se ha agregado el texto Entry, en resumen esto quiere
decir que es una accin de entrada.
9. Haga clic derecho en el texto Entry y seleccione la opcin Specification.

10. En el campo Name ingrese el texto Sonar_tono_de_llamada y luego haga
clic en Ok.
11. Haga clic en el botn State Transition y realice un clic sostenido desde el
objeto start state hacia el state descolgar sin marcar. Esto quiere decir que
se tiene un estado iniciar con una accin de entrada.
12. Elija el botn State e ingrese el texto Marcar.
162

13. Haga clic derecho en el state ingresado hace unos instantes y luego
seleccionar la opcin Open Specification.
14. Elija la pestaa Action y en el espacio en blanco, haga clic en Insert, se
podr observar que se ha agregado el texto Entry, en resumen esto quiere
decir que es una accin de entrada.
15. Haga clic derecho en el texto Entry y seleccione la opcin Specification.
16. En el campo When seleccione la opcin On Entry y luego en el campo
name ingrese el texto Aadir_digito(0)
17. Haga clic en Apply y luego en Ok.
objeto Descolgar sin marcar hacia el state Marcar.
19. Elija el botn text box y haga clic en la lnea de transition.
20. Ingrese en el campo Event el texto digito()
21. Haga clic en el botn End State y ubicarlo encima del state Marcar.
objeto Marcar hacia el state End.
23. Elija el botn text box y haga clic al costado de la lnea de transition e
ingresar el texto Numero.Es_Valido.
DIAGRAMA DE ACTIVIDAD EN RATIONAL ROSE.
En un diagrama de actividades se muestra un proceso de negocio o un proceso
de software como un flujo de trabajo a travs de una serie de acciones. Estas
acciones las pueden llevar a cabo personas, componentes de software o
equipos.
la opcin Logical View y luego en new.
4. Haga clic en la opcin Activity Diagram.
Haga clic en la opcin

Activity Diagram.
163

5. Ingrese el nombre para el diagrama; Ejemplo de diagrama de actividad,
luego haga clic en el botn Start State para iniciar el diagrama.
Haga clic en el
botn Start State.
6. Elija el botn Activity e ingrese el texto Pedir Contrasea.
Ingrese el texto
Pedir Contrasea
7. Haga clic en el botn Activity e ingrese el texto Permitir acceso.

8. Elija el botn Decisin y dibuje la figura entro las dos actividades agregadas
recientemente.
9. Haga clic en el botn End State y ubicarlo por debajo de la actividad
Permitir acceso.
Botn Decisin
164

10. Haga clic en el botn State transition y realizar el arrastre sostenido desde
el objeto Start State hacia la actividad Pedir contrasea.
11. Elije el botn State transition y realizar el arrastre sostenido desde el
objeto actividad Pedir contrasea hacia el objeto decisin.
12. Haga clic en el botn State transition y realizar el arrastre sostenido desde
el objeto decisin hacia la actividad Permitir acceso.
objeto actividad Permitir acceso hacia el objeto End state.

objeto decisin hacia la actividad Pedir contrasea.
15. Haga clic en el medio de las flechas y realice un arrastre hacia la derecha.
16. Haga doble clic en la flecha creada recientemente y luego elija la ficha
Detail.
17. En la opcin Guard Gondition, ingrese el texto Contrasea incorrecta.
Ingrese el texto
Contrasea
incorrecta.
Haga clic en Apply y

luego en la opcin OK
165

18. Haga doble clic en la flecha que une el objeto decisin y la actividad
Permitir acceso y luego elija la ficha Detail.
19. En la opcin Guard Gondition, ingrese el texto Contrasea correcta.
FUNDAMENTO TERICO:
DIAGRAMAS DE CLASE Y OBJETOS, ESTADOS Y ACTIVIDAD.
Los diagramas de estado tienen las caractersticas de exponer un conjunto
de estados por los cuales pasa un objeto durante el tiempo que permita cumplir
su funcin en la aplicacin. Es comn encontrar en el diagrama estados y
transiciones. Como los estados y las transiciones incluyen, a su vez, eventos,
acciones y actividades, vamos a ver primero sus definiciones.
Por ltimo es necesario recordar que el diagrama de estado como cualquier
otro diagrama permite los comentarios.
Los elementos que son propios del diagrama son:
Los eventos. Es la accin que genera una transicin de un estado a otro.
Las acciones. Son reconocidas como una operacin atmica, que no se
puede interrumpir por un evento y que tiene la peculiaridad que se ejecuta
hasta su finalizacin.
Estados. Cuando se trabaj con los estados es para por identificar una
condicin o una situacin en la vida de un objeto
En el caso de los diagramas de clase se podra decir que son la base del
anlisis y diseo orientado a objetos. Ya que dichos diagramas muestran las
clases del sistema, sus interrelaciones (incluyendo herencia, agregacin y
166

asociacin), y las operaciones y atributos de las clases. Los diagramas de
clases se utilizan para una amplia variedad de propsitos, incluyendo tanto el
modelado conceptual y el modelado de diseo.
Las Clases. Son objetos que pueden ser representados por personas, lugar,
cosa, concepto, acontecimiento del monitor, o el informe correspondiente al
sistema. Tambin se tiene que tener en cuenta que estas clases tienen
atributos y que originan los mtodos. Esto quiere decir que una clase es una
representacin de un objeto y, en muchos sentidos, es simplemente una
plantilla a partir de la cual se crean objetos. Las clases forman los bloques
de construccin principales de una aplicacin orientada a objetos.
Responsabilidades. Las clases se modelan normalmente como rectngulos
con tres secciones: la seccin superior para el nombre de la clase, la seccin
central de los atributos de la clase, y la seccin inferior de los mtodos de la
clase. Los atributos son la informacin almacenada acerca de un objeto (o,
al menos, informacin que se mantiene temporalmente sobre un objeto),
mientras que los mtodos son las cosas que un objeto o clase hacen. De
formas ms didctica se podra decir que los estudiantes tienen un cdigo
de estudiantes, nombres, direcciones y nmeros de telfono, todo ello
vendra hacer los atributos de un estudiante. Pero estos mismo estudiantes
son los que terminar por inscribirse en determinados cursos o solicitar algn
tipo de informacin acadmica, esto se conoce como mtodo.
Asociaciones. Est relacionado a la asociacin o relacin que puede tener
un objeto con otro objeto dentro del diseo.
El Diagrama de actividad es empleado normalmente para el modelado de
procesos de negocios, porque de esta forma permite capturar un solo caso de
uso o escenario de uso, o para modelar la lgica detallada de una regla de
negocio. Aunque los diagramas de actividad potencialmente podran modelar la
lgica interna de una operacin compleja que sera mucho mejor simplemente
reescribir la operacin por lo que es bastante simple que no necesita un
diagrama de actividades. En muchos sentidos, los diagramas de actividad son
el equivalente a orientado a objetos de diagramas de flujo y diagramas de flujo
de datos de desarrollo estructurado.
Nodo inicial. El llenado el crculo es el punto de partida del diagrama. Un
nodo inicial no es necesaria, aunque s lo hace mucho ms fcil de leer el
diagrama.
167

Actividad nodo final. El crculo lleno de una frontera es el punto final. Un
diagrama de actividades puede tener cero o ms nodos de actividad
definitiva.
Actividad. Los rectngulos redondeados representan las actividades que
ocurran. Una actividad puede ser fsica, como Inspeccione las formas, o
electrnica, tales como pantalla Crear pantalla de estudiante.
Flujo o borde. Las flechas en el diagrama. Aunque hay una sutil diferencia
entre los flujos y los bordes nunca he visto a un propsito prctico de la
diferencia, aunque no tengo ninguna duda de que exista. Usar el trmino
flujo.
Tenedor. Una barra de color negro con un flujo de entrar en ella y varios de
abandonarlo. Esto denota el comienzo de la actividad paralelo.
Unirse. Una barra de color negro con varios flujos de entrar en ella y uno de
abandonarlo. Todos los flujos de entrar en la unin debe llegar a l antes de
su procesamiento puede continuar. Esta denota el final del procesamiento
paralelo.
Condicin. Texto como [Forma incorrecta] en un flujo, la definicin de un
guardia que debe evaluar a verdadero para poder atravesar el nodo.
Decisin. Un diamante con un flujo que entra y varios de salir. Los flujos
salientes incluyen condiciones aunque algunos modeladores no se indican
las condiciones si es obvio.
Combinar. Un diamante con varios flujos de entrada y una salida. La
implicacin es que uno o ms flujos de entrada deben llegar a este punto
hasta que el proceso contina.
168

TAREA 09:
IMPLEMENTAR
INTERFACES Y DESPLIEGUE.
DIAGRAMAS
DE
COMPONENTES,

Identificar los componentes en el diagrama.
Identificar los nodos en funcin de sus tipos y conexiones.

Acceso a internet.
OPERACIONES:
DIAGRAMA DE COMPONENTES EN Rational Rose.
la opcin Component View y luego en new.
4. Haga clic en la opcin Component Diagram.
Haga clic en la
opcin
Component
Diagram.
5. Ingrese el nombre para el diagrama; Ejemplo de diagrama de

componentes, luego haga clic en el botn Componet para iniciar el
diagrama e ingrese el nombre Cliente.
169
Ingrese el
nombre Cliente
para el
Component.
6. Haga clic en el botn Componet para iniciar el diagrama e ingrese el

nombre Servidor.
7. Haga clic en el botn Package e ingrese el nombre Emisor. Luego repetir

la accin e ingrese un nuevo nombre Receptor
8. Haga clic en el botn Package e ingrese el nombre Receptor. Luego

repetir la accin e ingrese un nuevo nombre Work Thread y por ultimo un
package de Emisor.
170

Si al crear Package repetidos la aplicacin muestra un mensaje, haga clic en la
opcin No.
9. Haga clic en el botn Dependency y haga un clic sostenido desde el

Emisor del Cliente hasta el Receptor del Servidor.
10. Elegir el botn Text Box y haga clic en la dependencia recin creada y
agregue el texto Peticin.
Receptor del Servidor hasta el Work Thread del Servidor.
12. Elige el botn Dependency y haga un clic sostenido desde el Work
Thread del Servidor hasta el Emisor del Servidor.
Emisor del Servidor hasta el Receptor del Cliente.
14. Elegir el botn Text Box y haga clic en la dependencia recin creada y
agregue el texto Respuesta.
171

DIAGRAMA DE DESPLIEGUE EN StarUML.
1. Ingrese a la siguiente direccin web http://staruml.sourceforge.net/en/.
2. Haga clic en la opcin Downloads.
3. Haga doble clic en el icono staruml-5.0-with-cm, para iniciar la instalacin.

4. En la pantalla de bienvenida elegir el botn Next, luego acepte la licencia
para la aplicacin.
5. Haga doble clic en el acceso directo StarUML, para iniciar la aplicacin.
6. Ubicar el cursos del mouse en el rea de exploracin de modelos y haga clic
en el botn + de la opcin DeploymentModel y luego doble clic en la
opcin Main.
Haga doble clic

en la opcin
Main
7. En la barra de herramientas, haga clic en la herramienta Node y luego un

clic en el rea de diseo.
8. Ingrese el nombre computadora.
172

9. Repetir la accin de trabajar con la herramienta Node e ingresar el nombre
de impresora, luego de ello insertar un node con el nombre router.
10. Haga clic en el botn Association y haga un clic sostenido desde el node
Router hasta el node Computadora. Repita la accin del node
Computadora hasta el node impresora.
FUNDAMENTO TERICO:
Diagrama de componentes.
Dentro de esta etapa se crea el diagrama de componentes que describe
componentes de software y sus dependencias con otros componentes,
representando la estructura del cdigo. Los componentes de software pueden
ser: componentes de cdigo, componentes binarios que son los generados por
la compilacin de los componentes de cdigo y los componentes ejecutables.
En este diagrama se pueden manejar paquetes, que son contenedores de
clases utilizados para mantener el espacio de nombres de clases dividido en
173

compartimentos, de manera que se utilizan para representar subsistemas del
sistema en el mundo fsico. Cada paquete se liga con otros a travs
de dependencias, que se representan con flechas de lneas discontinuas que
van del componente dependiente al componente del cual depende.
Cada paquete debe tener un diagrama de componentes para representar las
clases que contiene internamente, similar a hacer un acercamiento o "zoom" al
interior de cada uno de los paquetes.
Los componentes de software se representan con un rectngulo que contiene
dos pequeos rectngulos en su extremo izquierdo.
Diagrama de despliegue.
Los Diagramas de Despliegue muestran las relaciones fsicas de los distintos
nodos que componen un sistema y el reparto de los componentes sobre dichos
nodos. La vista de despliegue representa la disposicin de las instancias de
componentes de ejecucin en instancias de nodos conectados por enlaces de
comunicacin.
Los nodos se interconectan mediante soportes bidireccionales que pueden a su
vez estereotiparse. Esta vista permite determinar las consecuencias de la
distribucin y la asignacin de recursos. Las instancias de los nodos pueden
contener instancias de ejecucin, como instancias de componentes y objetos.
El modelo puede mostrar dependencias entre las instancias y sus interfaces, y
tambin modelar la migracin de entidades entre nodos u otros contenedores.
Esta vista tiene una forma de descriptor y otra de instancia. La forma de
instancia muestra la localizacin de las instancias de los componentes
especficos en instancias especficas del nodo como parte de una configuracin
del sistema. La forma de descriptor muestra qu tipo de componentes pueden
subsistir en qu tipos de nodos y qu tipo de nodos se pueden conectar, de
forma similar a un diagrama de clases, esta forma es menos comn que la
primera
174

Analisis y Diseño de Sistem As - Senati

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Analisis y Diseño de Sistem As - Senati

Enviado por

Direitos autorais:

Formatos disponíveis

SERVICIO NACIONAL DE ADIESTRAMIENTO EN TRABAJO INDUSTRIAL

ANLISIS Y DISEO DE SISTEMAS

TAREA 01: ENTENDER LA CONCEPTUALIZACIN DE UN

Computadora con microprocesadores core 2 Duo o de mayor capacidad.

Haga clic en la opcin Install

4. Se muestra la pantalla de bienvenida, haga clic en el botn Siguiente.

ANLISIS Y DISEO DE SISTEMAS

5. Seleccione la opcin Desktop installation fron CD imagem y luego haga

6. En el siguiente pantallazo haga clic en Next, y se mostrar un mensaje de

ESCUELA DE TECNOLOGAS DE LA INFORMACIN

ANLISIS Y DISEO DE SISTEMAS

Haga clic en el botn Next.

7. Se mostrar la licencia. Haga clic en el botn Aceptar.

10. Haga clic en Next y por ltimo en el botn Install.

ESCUELA DE TECNOLOGAS DE LA INFORMACIN

ANLISIS Y DISEO DE SISTEMAS

12. Haga clic en Browser para seleccionar el archivo de la licencia.

Interfaz de Rational Rose.

ESCUELA DE TECNOLOGAS DE LA INFORMACIN

ANLISIS Y DISEO DE SISTEMAS

Qu sub-elementos se encuentra en el elemento Use Case View?

ESCUELA DE TECNOLOGAS DE LA INFORMACIN

ANLISIS Y DISEO DE SISTEMAS

3. Luego de generar la descarga. Haga doble clic en el archivo de instalacin.

5. Se mostrar la pantalla de bienvenida. Haga clic en Siguiente.

Activar los dos

7. Elija el lugar de instalacin y luego haga clic en siguiente.

ANLISIS Y DISEO DE SISTEMAS

8. Defina la carpeta del men inicio y haga clic en Instalar.

Asistente de configuracin de ArgoUML.

ESCUELA DE TECNOLOGAS DE LA INFORMACIN

ANLISIS Y DISEO DE SISTEMAS

3. Haga doble clic en el icono staruml-5.0-with-cm, para iniciar la instalacin.

Haga doble clic

Procedimiento para crear nuevo proyecto:

ESCUELA DE TECNOLOGAS DE LA INFORMACIN

ANLISIS Y DISEO DE SISTEMAS

Haga clic en la opcin New Project.

Opciones para administrar el Proyecto

Qu otras opciones tiene el Men File y cules son sus combinaciones de

New Project Approach

ESCUELA DE TECNOLOGAS DE LA INFORMACIN

ANLISIS Y DISEO DE SISTEMAS

Seleccione uno de la lista y

3. Un nuevo proyecto se crea y se inicializa segn el enfoque seleccionado.

Procedimiento para la apertura de un Proyecto.

Procedimiento para guardar el proyecto:

Haga clic en la opcin Import y luego en la

ESCUELA DE TECNOLOGAS DE LA INFORMACIN

ANLISIS Y DISEO DE SISTEMAS

Aparecer el cuadro de dilogo Seleccionar

ESCUELA DE TECNOLOGAS DE LA INFORMACIN

ANLISIS Y DISEO DE SISTEMAS

ESCUELA DE TECNOLOGAS DE LA INFORMACIN

ANLISIS Y DISEO DE SISTEMAS

ESCUELA DE TECNOLOGAS DE LA INFORMACIN

ANLISIS Y DISEO DE SISTEMAS

ESCUELA DE TECNOLOGAS DE LA INFORMACIN

ANLISIS Y DISEO DE SISTEMAS

ESCUELA DE TECNOLOGAS DE LA INFORMACIN

ANLISIS Y DISEO DE SISTEMAS

ANLISIS Y DISEO DE SISTEMAS

ESCUELA DE TECNOLOGAS DE LA INFORMACIN