Libro Rup Uml RMM Tomoi

Construccin de Software O.O.
con el Proceso Unificado y UML, un punto de vista prctico

Ing. Rosa Menndez Mueras
Tomo I
CAPTULO I
METODOLOGA ORIENTADO A OBJETOS
1.1. INTRODUCCIN
La exigencia de software de calidad, que satisfagan los
requerimientos del usuario actual, es todo un reto, ya que
solicitan un alto grado de especializacin
debido al
constante cambio de los diversos factores que influyen en la
organizacin.
La organizacin para hacer frente a las exigencias del
mercado actual, necesitan soluciones informticas integrales,
preparadas para soportar procesos exigidos por la coyuntura.
Estos
requieren
la
construccin
de
sistemas
de
informacin en el menor tiempo posible, que cumplan con
estndares de calidad, flexibilidad, robustez y construidos
en base a los requerimientos de la organizacin.
La interrogante ms famosa es sin duda:
satisfacer a los requerimientos del usuario actual?.
Cmo
Despus de muchos aos de evolucin en la construccin

de software, encontramos la solucin
a la interrogante
anterior al aplicar la Metodologa Orientado a Objetos.
Construccin de Software O.O. con el Proceso Unificado y UML, un punto de vista prctico
Tomo I
Las caractersticas de la Metodologa Orientada a

Objetos
como
la
herencia,
el
polimorfismo
y
el
encapsulamiento
hacen posible la construccin rpida de
software, caracterizado por la
flexibilidad a cambios
futuros, seguro y robusto, logrando as satisfacer las
exigencias del usuario actual.
El American National Standar Institute (ANSI), crea la
organizacin
no gubernamental y sin fines de lucro Object
Management Group (OMG), dicha institucin
se encarga de
definir los lineamientos y polticas para estandarizar a los
procesos, tcnicas, elementos, notaciones, etc., basados en
la metodologa orientada a objetos.
La tcnica
de modelamiento Unified Modeling Language
(UML), el proceso de construccin de software Rational
Unified Process
fueron aceptados por la OMG como
estndares, convirtindose en la tcnica de modelado y el
proceso de construccin de software por excelencia de la
Metodologa Orientada a Objetos.
En este captulo analizaremos la Metodologa Orientada a
Objetos desde
el punto de vista prctico, explicar las
caractersticas y principios de la metodologa de manera
sencilla y precisa sin necesidad de leer textos adicionales
para entender los diferentes tpicos citados en el presente
captulo.
Tomo I
1.2. METODOLOGIA ORIENTADO A OBJETOS

Es un conjunto de mtodos, procesos y tcnicas que guan
la construccin de software; caracterizado por analizar,
disear y ejecutar lo que sucede en la realidad.
Los conceptos
base de la Metodologa
Objetos son los objetos y las clases.
Orientada
Permite el desarrollo rpido de software al utilizar la

reutilizacin de componentes caracterstica principal del
lenguaje de programacin orientado a objetos JAVA.
La Metodologa Orientada a Objetos gua el proceso de
construccin de software al utilizar el RUP adems de
permitir a los profesionales inmiscuidos en el desarrollo del
software expresar su trabajo en trminos de diagramas al
utilizar el UML.
1.3. BASE CONCEPTUAL DE LA METODOLOGIA ORIENTADO A OBJETOS

1.3.1.
OBJETO
Es un ente real conceptual que posee caractersticas

inherentes
(atributos)
y
comportamiento
identificable
(mtodos). El objeto es especfico.
Son requisitos que deben cumplir los objetos.
IDENTIDAD + COMPORTAMIENTO + ESTADO
Mara Gutirrez
Juan Luna
Rosa Paz
Figura 01, Ejemplos de objetos referidos a la clase Persona.
Tomo I
1.3.2. CLASE
Es la coleccin de objetos
funciones y mtodos comunes.
que
comparten
atributos,
Es una abstraccin y no refencia a ningn objeto en

particular.
Estas son genricas, permitiendo modelar el mundo real.
Persona
Universidad
Automvil
Figura 02, Ejemplos de Clases.
1.4. CARACTERISTICAS TERICAS DE LA METODOLOGA ORIENTADO A

OBJETOS.
1.4.1. ABSTRACCIN
Es la representacin de las caractersticas esenciales
de algo, sin incluir detalles irrelevantes.
1.4.2. PERSISTENCIA
Se refiere al tiempo de vida de un objeto. Cuando este
reside en la memoria RAM, se dice que no es persistente, pero
los que se almacenan en un medio permanente, en el disco
duro, por ejemplo, se dice que son persistentes.
Ejemplo:
La informacin de la base de datos son considerados
persistentes por no alterarse con respeto al tiempo, la nica
Tomo I
manera de modificarlos
language (SQL).
es
mediante
el
Structure
Query
1.4.3. ENCAPSULAMIENTO
Consiste en contener en una clase datos y funciones, de
forma que el acceso a los datos se permite slo a travs de
los propios mtodos del objeto.
Ninguna otra parte de la aplicacin orientada a objetos
debe operar directamente sobre los datos de otro objeto.
Empaquetamos en un objeto una pieza de informacin con
comportamiento especfico que acta sobre esta informacin.
Con esta caracterstica podemos limitar
cambios sobre el sistema.
1.4.4.
los efectos de
POLIMORFISMO
Un
mismo
mtodo
puede
presentar
diferentes
comportamientos, en funcin al contexto. Esta caracterstica
permite lograr la simplicidad y el orden en el ambiente de
programacin.
1.4.5.
HERENCIA
Propiedad que permite a la clase o subClase tener acceso

a los atributos y mtodos de otra conocida como clase padre o
superclase.
La herencia permite a los programadores crear nuevas
clases programando solo las diferencias con la clase padre.
Esta caracterstica brinda facilidad de mantenimiento y
hace posible la reutilizacin de componentes.
1.4.6
REUTILIZACIN DE COMPONENTES
Producida gracias a la caracterstica de herencia de la

Metodologa
Orientada
a
Objetos.
La
reutilizacin
de
componentes implica la construccin de software con equipo
lgico que ya existe o que construyen terceros.
Tomo I
La ventaja principal que aporta es la

aplicaciones eficientes y de gran fiabilidad.
1.4.6.1.
generacin
de
COMPONENTES
Son bloques de construccin de aplicaciones. Los

"constructores de soluciones" utilizan muchos componentes
software para la realizacin de sus sistemas.
El concepto de reutilizacin de componentes abarca el
equipo lgico existente para tareas bsicas y genricas como
impresin,
procesadores
de
textos,
hojas
de
clculo,
grficos, diagramas de barras y dibujos. Todas estas piezas
deberan estar disponibles como componentes reutilizables
para todas las soluciones que los necesiten.
1.4.6.2.
OBTENCIN DE COMPONENTES
Si se acepta de forma universal el modelo de objetos

para la construccin de componentes, significa que aparecer
una nueva industria de creacin de componentes genricos.
Las aplicaciones ms habituales (procesadores, grficos,
etc.) se encontrarn disponibles en forma de componentes que
se podrn integrar para conseguir nuevas aplicaciones de gran
flexibilidad y potencia. Lo nico necesario es el lenguaje de
programacin comn para ensamblar los distintos componentes y
construir la aplicacin.
Para construir una aplicacin compleja, se dispondr de
componentes genricos fabricados por terceros y que se
integrarn
junto
con
los
componentes
especficos
desarrollados para la aplicacin concreta. Esto permite
concentrar el esfuerzo del desarrollador en las partes de la
aplicacin que son de su competencia y poder as desarrollar
soluciones potentes de forma muy rpida.
La idea es construir nuestros propios componentes, ello
permite lograr especializacin y obviamente la construccin
rpida de software.
Tomo I
1.4.7
MODELO DE OBJETOS
El modelo de objetos formaliza la estructura y el

comportamiento de los componentes para que puedan trabajar
conjuntamente. El modelo ve a los componentes como objetos y
utiliza los conceptos de orientacin a objetos para definir
el marco de desarrollo de los mismos.
El problema es la falta de uniformidad en el desarrollo
de los componentes para que puedan comunicarse y trabajar
conjuntamente.
La finalidad
a objetos para la
la presencia de
homogenizacin de
1.4.8
del modelo de objetos anlisis orientados

construccin de la base de datos es evitar
nulos y redundancia logrando adems la
los datos en ella.
VENTAJAS DEL ANALISIS ORIENTADOS A OBJETOS EN

LA BASE DE DATOS1
La base de datos est completamente libre de nulos.
La base de datos est libre de redundancia.
La normalizacin de la base de datos es implcita.
La base de datos est preparada para cambios futuros.
Las clases son componentes
El modelamiento orientado a objetos permite:
reutilizables.
o La generacin de cdigo para la programacin, y

o La generacin de scripts SQL para el diseo de la
base de datos.
El modelo de objetos conduce directamente hacia

programacin en la WEB(accesos remotos de BD).
1.4.9.
MENSAJE:
Los objetos se comunican entre si mediante mensajes.

1
Idea original del Magster Amancio Guzmn Rodrguez
la
Tomo I
Cuando un objeto no esta capacitado para realizar una

tarea, y otro lo esta; entonces el primer objeto enva un
mensaje al segundo. Los mensajes resuelven los problemas
derivados del encapsulamiento.
1.4.10.
MTODO
Tambin conocido como operacin

en la etapa
anlisis. Son las diversas acciones (comportamientos)
realizar con las caractersticas de la clase.
de
a
Por ejemplo, para el atributo nombre, podemos considerar

los siguientes mtodos:
agregarNombre()
grabarNombre()
modificarNombre()
eliminarNombre()
1.4.11.
MODELO
Representa el sistema software desde una perspectiva

especfica. Al igual que la planta y el alzado de grficos en
dibujo tcnico nos muestran la misma figura,
vista desde
distintos ngulos, cada modelo nos permite visualizar un
aspecto distinto del sistema.
Un modelo puede ser expresado en los diversos diagramas
propuestos por el UML.
El modelo permite a los profesionales inmiscuidos en la
construccin de software expresar su trabajo en trminos de
diagramas.
Tomo I
CAPITULO II
LENGUAJE DE MODELAMIENTO UNIFICADO
2.1. INTRODUCCIN
La
tcnica
de
modelado
estndar
Modelamiento Unificado), capta cada vez
mundo de desarrollo de software, ya que
especificar y documentar todo el proceso
software de manera clara y sencilla.
UML
(Lenguaje
de
ms inters en el
permite visualizar,
de construccin del
As como los arquitectos utilizan los planos para

planificar las caractersticas de una construccin al
detalle,
los
profesionales
que
participamos
en
la
construccin de software podemos tambin planificar el
proceso
de construccin, obviamente no utilizamos planos
pero si los diferentes diagramas del UML.
Con el uso de los diagramas controlamos los detalles de
construccin del software, que sin el uso del UML sera
complicado por la caracterstica emprica del proceso de
construccin sin previo anlisis.
En este captulo analizaremos el detalle del UML desde
un punto de vista prctico e ilustrativo.
La construccin de software es un arte; como toda expresin

artstica la paciencia y creatividad son habilidades indispensables
conducentes al xito de la construccin del software.
Tomo I
2.2.
CONCEPTO
El UML, es una tcnica de modelado, NO una metodologa el

case de modelamiento Rational Rose, muchas personas tienen
esa confusin, espero despus de esta clara explicacin no
haya lugar a dudas.
El
UML,
aparte
de
permitir
la
especificacin,
visualizacin, construccin y documentacin de los elementos
de un sistema software, tambin se utiliza en el modelado de
procesos de negocio u otros sistemas no-software. UML rene
una coleccin de las mejores prcticas en la ingeniera de
software que han sido utilizadas con xito para modelar
sistemas grandes y complejos. Este lenguaje es una notacin
calificado por la OMG como tcnica de modelado estndar.
El UML incrementa la productividad y la calidad del
sistema, reduciendo incluso el ciclo de vida de construccin
del software al ser utilizado adecuadamente
por un proceso
de construccin de software como el RUP por ejemplo.
UML ser predominante en
siguientes razones:
los prximos aos, debido a las
Fue creado por expertos en metodologa,

informtica y
tecnologas
influyentes,
sobre la base de
las
mejores prcticas en construccin de software de todos
los tiempos.
Muchas empresas lderes en tecnologa patrocinaron su
creacin.
Tiene la aceptacin de la OMG como notacin estndar.
2.3. ANTECEDENTES DEL UML

El UML ha sido creado por Grady Booch, Ivar Jacobson, y
James Rumbaugh, teniendo como principal patrocinador a la
corporacin Rational, utilizando informacin de otros
importantes
expertos
en
metodologas,
vendedores
de
software, y usuarios finales.
El objetivo de su creacin fue unificar los diversos
sistemas que haba y crear un lenguaje de modelado con las
mejores caractersticas de cada uno.
10
Tomo I
Grady
Booch
Figura 03,
Ivar
Jacobson
James
Rumbaugh
Creadores de Lenguaje de Modelamiento Unificado.
Jacobson
Jacobson
Booch
Rumbaugh
Figura 04, Aportes significativos de los mtodos originales

de Grady Booch, Ivar Jacobson, y James Rumbaugh al UML.
El UML nace en el ao 1995, el detalle de su evolucin
lo observamos en la figura N 05.
11
Tomo I
2002
UML 2.0
Planificacin de
una revisin mayor
2001
UML 1.4
Planificacin de una
revisin menor
1999
UML 1.3
Solicitud a una
revisin menor
1997
UML 1.1
Aceptacin por la OMG

Permiso final a la OMG
Permiso inicial a la OMG
Socios del UML
Mtodo Unificado 0.8
1996
1995 OOPSLA 950
Mtodo Unificado 0.8
OOSE
Otros
mtodos
BOOCH
OMT
UML 0.9
Figura 05, Evolucin del UML desde el advenimiento del Mtodo

Unificado 0.8.
2.4. UML AL DETALLE

Los elementos y diagramas
paradigma orientado a objetos.
UML
estn
basados
en
el
Podemos dividir al UML en cuatro partes:
2.4.1.
VISTAS
Muestran los diferentes aspectos del sistema que son

modelados. Una vista no es un grfico, pero es la abstraccin
consistente en un nmero de diagramas.
12
Tomo I
Consideramos las siguientes vistas:
Vista
Vista
Vista
Vista
Vista
de casos de uso.
lgica.
de componentes.
concurrente.
de despliegue.
Las vistas anteriores, son trabajados en el browser del

case de modelamiento Rational Rose, ver figura N 06.
Implementation
View
Logical View
End-user
Functionality
Use Case
View
Process
View
Performance
Scalability
Throughput
Programmers
Software management
Deployment View
System topology
Delivery, installation
Communication
System engineering
Figura 06, Vista del UML, desde 2 puntos de vista.
2.4.2.
DIAGRAMAS
Son los grficos que describen el

vista. UML tiene ocho tipos de diagramas
proveer todas las vistas del sistema.
2.4.3.
contenido en una
que se usan para
ELEMENTOS DE MODELO
Los conceptos usados son elementos del modelo que

representan conceptos orientados a objetos como clases,
objetos,
mensajes
y
relaciones
incluyendo
asociacin
dependencia y generalizacin.
13
Tomo I
2.4.4
MECANISMOS GENERALES
Son smbolos genricos para informacin adicional sobre un

diagrama,
tpicamente
son
los
que
no
pueden
ser
representados. Se tiene los adornos y las notas.
2.5. VISTAS DEL UML

2.5.1.
VISTAS ESTTICAS
Los Diagramas de estructura esttica de UML se van a

utilizar para representar tanto Modelos Conceptuales como
diagramas de clases de diseo, ambos usos son distintos
conceptualmente, mientras los primeros modelan elementos del
dominio los segundos presentan los elementos de la solucin
software.
2.5.2.
VISTAS DINMICAS
Vamos a recordar los diferentes modelos que sirven para

representar el aspecto dinmico de un sistema:
Diagramas
Diagramas
Diagramas
Diagramas
Diagramas
de
de
de
de
de
secuencia
colaboracin
estados
casos de uso
actividades
2.6. DESCRIPCION DE LOS DIAGRAMAS DEL UML

2.6.1.
2.6.2.
DIAGRAMA DE CLASES
CONCEPTO
El diagrama de clases es un entorno esttico, donde se

muestra las clases y sus relaciones, las relaciones pueden
ser: Herencia, Agregacin y Asociacin.
14
Tomo I
2.6.3.
TIPOS DE RELACIONES ENTRE CLASES
2.6.3.1. HERENCIA
La
Herencia
Generalizacin
es
el
proceso
de
identificar las caractersticas comunes y definir relaciones
entre una Superclase (genrico) y Subclases (conceptos
especializados, especficos). Una clase hija puede ser
reconocida mediante las palabras reservadas Es un tipo de.
2.6.3.2. AGREGACIN
La Agregacin indica una relacin de un todo conformado
por partes. Puede ser reconocido mediante las palabras
reservadas Es parte de.
2.6.3.3. ASOCIACIN
Relacin
entre
clases
que
indican
significativa, la asociacin bidireccional
dependencia.
una
NO
conexin
significa
La asociacin est representada con una lnea entre las

clases con un nombre que identifique la relacin. Las
asociaciones unidireccionales significan dependencia.
15
Tomo I
2.6.4.
ELEMENTOS DEL DIAGRAMA DE CLASES
CLASES
Agregacin
Asociacin
Agregacin
Unidireccional
Herencia
Clase
asociativa
Asociacin
Unidireccional
Dependencia
Figura 07, Elementos en un diagrama de clases.
16
Tomo I
Figura 08, Ejemplos de Diagramas de Clase.
2.7. DIAGRAMA DE PAQUETES
2.7.1.
CONCEPTO
Diagrama del tipo esttico, el objetivo es mostrar las

dependencias que existen entre paquetes.
2.7.2.
ELEMENTOS DEL DIAGRAMA DE PAQUETES
PAQUETE
DEPENDENCIA
INSTANCIA
Figura 09, Elementos y Diagrama de paquetes.
17
Tomo I
2.8. DIAGRAMA DE CASOS DE USO
2.8.1.
CONCEPTO
El diagrama de Casos de Uso muestra la relacin entre

los actores y los casos de uso tanto en el negocio como en
el sistema.
Muestran la atomizacin del sistema en fragmentos
funcionales reutilizables, la interaccin de los actores con
la funcionalidad del sistema. Muestra la definicin visual de
los requerimientos del usuario.
El diagrama de casos de uso tambin muestra el
funcionamiento del proceso empresarial en trminos de sus
participantes los actores internos y externos con respecto
a su realizacin en el ambiente de negocio.
18
Tomo I
2.8.2.
ELEMENTOS DEL DIAGRAMA DE CASOS DE USO
Caso de Uso
del Sistema
Caso de Uso
Realizacin
del Sistema
Actor Interno
del Negocio
Caso de Uso
del Negocio
Caso de Uso
Realizacin
del Sistema
Actor Externo
del Negocio
Herencia
Asociacin
Unidireccional
Dependencia
Instancia
Actor
del Sistema
Figura 10, Elementos a utilizar en un Diagrama de Casos de

Uso.
Figura 11, Ejemplos de
Diagramas de Casos de Uso.
19
Tomo I
2.9.
DIAGRAMA
2.9.1.
ACTIVIDADES
CONCEPTO
Muestra las diversas actividades

persona, una organizacin,
incluso
software.
ejecutados por una

el hardware el
Su objetivo es comprender qu actividades son necesarias

y cuales son sus relaciones de dependencia transicin de
estado.
Se utiliza para representar los distintos escenarios que
involucra un Caso de Uso, permite describir las tareas
sincronizadas y responsabilidades, resolviendo factores de
decisin.
2.9.2.
ELEMENTOS DEL DIAGRAMA DE ACTIVIDADES
Inicio
Fin
Swimlane
Actividad
Sincronizacin
Horizontal y
Vertical
Desicion
Transicin
Recursiva
Transicin de
Estado
Figura 12, Elementos del Diagrama de Actividades.
20
Tomo I
Figura 13, Ejemplo de Diagrama de Actividades.
2.10.
DIAGRAMA DE ESTADOS
2.10.1.
CONCEPTO
Muestra la secuencia de estados por los que pasa el caso

de uso, el objeto el sistema a lo largo de todo el tiempo
de vida.
En el diagrama de estados se indica qu eventos realizan
los casos de uso, los objetos y los sistemas en general para
pasar de un estado a otro y cules son las respuestas y
acciones que genera.
21
Tomo I
En cuanto a la representacin, el
diagrama de estados
es un grafo cuyos nodos son estados y cuyos arcos dirigidos
son transiciones etiquetadas con nombres de los eventos.
2.10.2. ELEMENTOS DEL DIAGRAMA DE ESTADOS
Inicio
Transicin de
Estado
Fin
Estado
Sincronizacin
Horizontal y
Vertical
Transicin
Recursiva
Figura 14, Elementos del Diagrama de Estados
Figura 15, Ejemplos del Diagrama de Estados.
22
Desicion
Tomo I
2.11. DIAGRAMA DE OBJETOS

2.11.1.
CONCEPTO
Es el entorno intrnseco de los diagramas del tipo

interactivo, tanto en el diagrama de secuencia como en el
diagrama de colaboracin se realizan los diagrama de objetos,
los elementos necesarios para realizar cualquiera de estos
diagramas tienen la misma consecuencia.
La nica diferencia entre ambos diagramas es la
orientacin, con respecto al tiempo en el diagrama de
secuencia y con respecto al espacio en el diagrama de
colaboracin; incluso el case de modelamiento Rational Rose,
toma como equivalentes a estos diagramas de interaccin.
Convertir el diagrama de secuencia al
diagrama de
colaboracin est a la
altura de un click; obviamente
tambin funciona en el otro sentido.
2.12. DIAGRAMAS DE INTERACCIN

En los diagramas de interaccin se muestra el 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. Son diagramas de
interaccin los ya mencionados diagramas de Secuencia y los
diagramas
de
Colaboracin.
2.12.1. DIAGRAMA DE SECUENCIA
2.12.1.1. CONCEPTO
El diagrama de Secuencia muestra la interaccin ordenada
segn la secuencia temporal de eventos, con respecto al
tiempo. Muestra los objetos participantes en la interaccin y
los
mensajes
que
intercambian
de
manera
ordenada
y
secuencial.
23
Tomo I
2.12.1.2. ELEMENTOS DEL DIAGRAMA DE SECUENCIA
Objeto
Mensaje Objeto
Mensaje Recursivo
Mensaje con Retorno
Marca de Destruccin
Figura 16, Elementos del Diagrama de Secuencia.
24
Tomo I
Figura 17, Ejemplo
2.12.2.
del Diagrama de Secuencia.
DIAGRAMA DE COLABORACION
2.12.2.1. CONCEPTO
Es el diagrama del tipo dinmico, e interactivo, permite
la relacin entre objetos quienes se comunican con otros
objetos y entre s,
mediante la secuencia de mensajes con
respecto al espacio.
25
Tomo I
2.12.2.2. ELEMENTOS DEL DIAGRAMA DE COLABORACION
Objecto Link
Objeto
Objeto Recursivo
Mensaje Link
Mensaje Link
Inverso
Datos tipo
Token
Datos tipo Token

Inverso
Figura 18, Elementos del Diagrama de Colaboracin.
Figura 19, Ejemplo del Diagrama de Colaboracin.
26
Tomo I
2.13.
DIAGRAMA COMPONENTES
2.13.1. CONCEPTO
Los componentes pertenecen al mundo fsico, es decir,
representan el bloque de construccin al modelar aspectos
fsicos del sistema.
La
caracterstica
bsica
del
componente
es
que:
debe definir la abstraccin precisa con la interfaz bien
definida, permitiendo reemplazar fcilmente los componentes
viejos con otros nuevos y compatibles..
En el UML todos los elementos fsicos se modelan como
componentes.
2.13.2. ELEMENTOS DEL DIAGRAMA DE COMPONENTES
Especificacin
de un Subprograma
Especificacin
de la Tarea
Programa
Principal
Cuerpo del
Subprograma
Componente
Especificacin del
Paquete
Cuerpo de la Tarea
Cuerpo
del paquete
Figura 20, Elementos del Diagrama de Componentes.
27
Tomo I
2.14.
DIAGRAMA DE DESPLIEGUE
2.14.1.
CONCEPTO
Al igual que los componentes los nodos pertenecen al

mundo material. Vamos a definir el nodo como un elemento
fsico, que existe en tiempo de ejecucin y representa el
recurso computacional que generalmente tiene alguna memoria
y, a menudo, capacidad de procesamiento. Los nodos sirven
para modelar la topologa del hardware sobre el que se
ejecuta el sistema. Un nodo representa normalmente el
procesador o el dispositivo sobre el que se pueden
desplegar los componentes.
Un nodo debe tener un nombre asignado que lo distinga
del resto de nodos.
2.14.2.
ELEMENTOS DEL DIAGRAMA DEL DESPLIEGUE
DEVICE
PROCESOR
Figura 21, Elementos del Diagrama del Despliegue.
28
Tomo I
Figura 22, Ejemplo
del Diagrama del Despliegue.
29
Tomo I
CAPITULO III
PROCESO UNIFICADO RATIONAL
3.1. INTRODUCCIN
Si no tenemos una gua prototipo que dirija los pasos

para el logro de un objetivo en particular difcilmente
lograremos el xito, el mundo real NO funciona en base a
criterios y procedimiento empricos. Basarse en la suerte,
en lo NO previsto
y en el ojala suceda como pienso,
demuestran la falta de conocimiento e inseguridad, ello
repercute en el fracaso del objetivo trazado.
Los profesionales dedicados a la construccin
de
software,
sabemos que
la combinacin del conocimiento,
experiencia, habilidad y creatividad en la aplicacin de
tcnicas, mtodos y procesos, nos acerca con certeza al xito
en la creacin del software.
Si no contamos con
el plan que gue el proceso de
construccin de software, sin duda caeremos en el fracaso.
Un proceso define quin est haciendo qu, cundo y cmo
para lograr el objetivo previsto. En la ingeniera de
software el objetivo es construir el
software mejorar
alguno existente.
Para lograr el xito del proyecto informtico NO basta
tener la buena administracin del conjunto.
30
Tomo I
Despus de un largo proceso de investigacin y

comparacin puedo establecer con certeza, la importancia del
un proceso que gue la construccin del software, el binomio
administracin del proyecto y proceso de construccin del
software
permite acercarnos al
xito del software en
trminos de tiempo, costo, calidad y alcance.
Debemos
tener cuidado al momento de seleccionar el
proceso de construccin,
se debe poner especial nfasis en
el estudio de los procesos organizacionales y procurar el
respaldado por alguna organizacin estndar.
El advenimiento del Internet, la globalizacin y el
desarrollo agigantado de la tecnologa hace que los usuarios
soliciten software con caractersticas
cada vez ms
sofisticados que les permitan estar a la altura de los
constantes cambios internos como externos para permanecer en
la carrera competitiva exigida por el mercado actual.
Es necesaria la aplicacin del proceso que permita la
centralizacin en los procesos empresariales, adelantarse a
los riesgos, centrarse en la arquitectura de desarrollo,
pasar por una estricta etapa de pruebas y control de calidad,
permitir que cada uno de los integrantes del equipo actu y
piense
como
un
solo
grupo
y
analizar
el
entorno
organizacional para asegurar el xito de la integracin.
El proceso Rational Unified Process (RUP), basado en la
metodologa orientado a objetos y declarado como proceso
estndar por la Object Management Group (OMG) es una
alternativa para solucionar muchos de los problemas que
aquejan constantemente en la construccin del software.
En el presente captulo analizaremos los
aspectos del RUP,
como fruto de ms de
investigacin; abordaremos los principios, fases,
conceptos del RUP desde un punto de vista
didctico.
31
principales
un ao de
elementos y
prctico y
Tomo I
3.2. CONCEPTO
El Proceso Unificado Rational (RUP) es el proceso de
ingeniera de software, cuyo objetivo es producir software de
alta calidad, es decir, que cumpla con los requerimientos de
los usuarios dentro de los mrgenes de la planificacin y
presupuestos establecidos.
El RUP, cubre todo el ciclo de vida de desarrollo de
software, el
propsito es asegurar la
produccin de
software, es decir, que colme las expectativas y exigencias
del usuario actual, entregado en el tiempo previsto, con la
calidad esperada, que se maneje dentro del presupuesto-costo
calculado y que cumpla con los requisitos establecidos en la
definicin del proyecto de construccin del software.
El RUP puede integrar todos los aspectos a tener en
cuenta durante el ciclo de desarrollo del software con el
objetivo de hacer tangibles todo tipo de proyectos sin
interesar su envergadura.
3.3
ANTECEDENTES
Aos atrs nuestros colegas especialistas en las

construccin de software encontraban muchas dificultades en
el proceso de construccin de software, problemas tales como:
mantener el hilo conductor del proceso de desarrollo,
mantener la retroalimentacin constante entre cada una de las
etapas de construccin, falta de conocimiento organizacional
y falencias en la definicin de roles, fueron algunas de las
causas de la falta de calidad y performance en el software
puesto en produccin. Muchas de las dificultades
expuestas
son solucionadas por el proceso RUP.
El proceso RUP, nace a partir de la necesidad de contar
con un proceso, robusto, potente y flexible que permita dar
solucin a los requerimientos cada vez ms sofisticados del
usuario actual donde el punto de entrada ms importante es
el conocimiento de la organizacin en base a procesos y sus
participantes internos externos.
32
Tomo I
El RUP fue creado por

Grady Booch, Ivar Jacobson y
James Rumbaugh se hace presente en el mercado de desarrollo
de software a principios del 1998.
Los orgenes del RUP se remonta desde 1967, fecha en que
el
mtodo
Ericson
era
el
ms
respetable
mtodo
de
construccin de software,
a partir
del modelo Ericson el
proceso RUP tuvo varias influencias como el Rational Approch
y el Objectory Process, entre otros.
Muchas empresas relacionadas con la tecnologa y la
informtica patrocinaron la creacin del proceso RUP,
menciono algunos para alimentar vuestra cultura y evitar el
silencio cuando alguna persona principiante en el apasionado
mundo del RUP, comienza a tener dudas.
Empresas patrocinadoras para la creacin del
proceso
RUP:
IBM, Microsoft, Sun Microsystems, Rational Corporation,
Microsoft, HP, Oracle, Texas Instruments, MCI, SystemHouse,
entre otras.
3.4. IMPORTANCIA PROCESO RUP
Resumo la importancia del RUP en los siguientes puntos:
Permite dar solucin a los exigentes requerimientos de

los usuarios actuales, cada vez ms exigentes, debido a
los constantes cambios que la misma sociedad y
competencias en el mercado exigen.
Permite obtener los requerimientos

documentar
los
requerimientos
de
restricciones, documentar decisiones,
ltimo comunicar los requerimientos del
Permite capturar varias de las mejores prcticas en el

desarrollo moderno de software de forma que sea
aplicable
en
un
amplio
rango
de
proyectos
y
organizaciones.
33
y organizarlos,
funcionalidad
y
captarlas y por
negocio.
Tomo I
Es una gua de cmo utilizar de manera efectiva el UML.

La tcnica de modelado UML, no se utiliza nicamente
para efectos de documentacin, gracias al proceso RUP,
el UML est presente en todas las fases
y etapas
establecidas por RUP, con UML cada uno de los roles
participantes en el proceso de desarrollo de software
pueden expresar su trabajo en trminos de diagramas.
Los analistas, ingenieros, arquitectos de software,
revisores de casos de uso, etc, utilizan los diagramas
para mostrar el detalle del construccin del software.
Provee a cada miembro de equipo el fcil acceso a una

base
de
conocimiento
con
guas,
plantillas
y
herramientas para todas las actividades crticas de
desarrollo.
Crea y mantiene modelos, en lugar de enfocarse en la

produccin de gran cantidad de papeles de documentacin.
Permite que todos los miembros del equipo compartan:

Conocimiento base, el proceso, la visin de
desarrollar software y el lenguaje de modelado.
Permite la verificacin de la calidad

mediante las siguientes actividades:
del
cmo
software,
9 Crea pruebas para cada escenario (casos de

asegurando
que
todos
los
requerimientos
apropiadamente implementados.
uso),
estn
9 Verifica la calidad del software con respecto a los

requerimientos
basados
en
la
confiabilidad,
funcionalidad, desempeo de la aplicacin y del
sistema.
9 Prueba cada iteracin.
9 El proceso de Pruebas, sujeto tambin al modelo
iterativo e incremental, permite que cada caso de uso
que NO cumpla con el control de calidad
pueda
corregirse e implementarse en el momento indicado ya
que la implementacin de la solucin obviamente
34
Tomo I
buena, puede no ser la solucin

implementado en el momento justo.
idnea
si
no
es
Si se desea construir software de calidad,

en un tiempo corto, bajo el
presupuesto
establecido
y
cumpla
con
las
especificaciones definida por el principal
involucrado del proyecto, la alternativa,
sin duda es el proceso RUP.
3.5. PRINCIPIOS DEL RUP

Desarrollo
Iterativo Controlado
Desarrollo basado
en componentes
Dirigido por
casos de uso
Define tcnicas de
modelamiento visual
Gestiona
requerimientos
Centrado en
la arquitectura
Define un
proceso configurable
Figura 23, Principios del Proceso Unificado Rational

Despus de analizar ms de 22 principios citados por
diferentes autores, detallar
7 principios:
Los principios mencionados en la figura N 23, fueron
pautas
importantes que obtuve en la investigacin y
desarrollo en ms de 11 proyectos de construccin de software
con RUP. Constituyen el corazn del proceso, los cuales por
razones que ya expondr son de real utilidad permitiendo el
xito del software si se logra combinar de una manera
inteligente y lgica el proceso de construccin de software
con la administracin del proyecto.
35
Tomo I
Ahora empezamos de describir

los principios del RUP,
conducentes al xito en la construccin de cualquier
software.
3.5.1
GUIADO POR CASOS DE USO
La razn de ser del sistema de software es servir a los

usuarios, ya sean humanos u otros sistemas. El caso de uso
fragmento funcional del sistema, es la facilidad que el
software provee a los actores (personas, software hardware)
que utilizan son utilizados por la plataforma de
informacin del sistema.
Los casos de
uso, son importantes ya que definen el
comportamiento del futuro sistema, los casos de uso NO son
parte de la orientacin a objetos tradicional, pero entienden
su funcionalidad, cada vez ms clara y precisa a medida que
se evoluciona; otros mtodos orientados a objetos usan los
casos de uso como gua pero con nombres diferentes.
Los casos de uso juegan un papel importante en
cuatro
etapas
de los procesos generales del
RUP: Requisitos,
Anlisis-Diseo, Codificacin y Prueba.
El modelo de casos de uso es el resultado del anlisis

en
la
etapa
de
Requisitos
Anlisis
de
Requerimientos, en esta temprana etapa se necesitan a
los casos de uso para conocer que har el software desde
el punto de vista del usuario, los casos de uso
constituyen un concepto importante y fundamental, deben
ser aceptados por el cliente y el grupo desarrollador.
En la segunda etapa Anlisis-Diseo, los casos de uso

son ejecutados en el modelo de diseo, se crea
realizaciones de casos de uso, que describa como los
casos de uso son realizados en trminos de interaccin
de objetos en el modelo de diseo, este modelo describe
en trminos de diseo de objetos las diferentes partes
de
la
implementacin
del
sistema y cmo deben actuar funcionar las partes.
En la tercera etapa Implementacin, el modelo de

diseo es la especificacin de la implementacin, porque
los casos de uso realizados en el modelo de diseo, son
implementados en trminos de diseo de clases.
36
Tomo I
Durante la cuarta etapa Pruebas, los casos del uso

constituyen la base para identificar la prueba de casos
de uso y la prueba de procedimientos, el sistema pasar
el control de calidad y la etapa de pruebas solo si
todos los casos de uso especificados y desarrollados en
etapas anteriores son parte funcional del sistema final.
Al utilizar el modelamiento de negocio se hallan los

diversos procesos empresariales de la organizacin
convirtindolas
en
casos
de
uso
de
negocio,
posteriormente en casos de uso del sistema segn el
alcance del proyecto.
3.5.2.
CENTRADO EN LA ARQUITECTURA
El RUP, enfatiza la construccin de sistemas software

robusto, respetando la arquitectura de construccin,
ello
disminuye
el
reinicio
del
software,
aumentado
la
reutilizacin y facilita el mantenimiento futuro del mismo.
La arquitectura se utiliza para planificar y administrar
el
desarrollo
del
software
teniendo
en
cuenta
la
reutilizacin de sus componentes.
La
arquitectura
involucra
los
elementos
ms
significativos del sistema
y est influenciada entre otros
por plataformas software, sistemas operativos, gestores de
base de datos, protocolos de comunicacin, etc.
El enfoque de iteraciones tempranas, definido con mayor
nfasis en la fase de elaboracin es producir y validar una
arquitectura de software, que el ciclo de desarrollo inicial
toma la forma de un prototipo arquitectnico ejecutable el
cual evoluciona gradualmente para convertirse en un sistema
final en las ltimas iteraciones.
3.5.3.
RESPETA EL MODELO
ITERATIVO E INCREMENTAL
El RUP es un proceso iterativo e incremental, el cual

permite
entender
el
problema
a
travs
de
sucesivos
refinamientos e incrementar la solucin efectiva mediante
mltiples interacciones, este acercamiento brinda la mejor
opcin en acomodar
nuevos requerimientos cambio de
tcticas en los objetivos del negocio y continuar con el
37
Tomo I
proyecto
oportuna.
identificado,
resolviendo
riesgos
de
manera
El RUP es un proceso controlado, la caracterstica

iterativa solo es posible al menos a travs de una cuidadosa
administracin de requerimientos y control de cambios,
asegurando as la comprensin de la funcionalidad del
software en el momento adecuado considerando la calidad
prevista, adems permite
el control de la entrega del
proyecto dentro del tiempo establecido.
Para hacer ms manejable un proyecto se recomienda
dividirlo en ciclos, para cada ciclo se establecen fases de
referencia, cada una de las cuales debe ser considerada como
mini-proyecto cuyo ncleo fundamental est constituido por
una ms iteraciones de las actividades principales bsicas
de cualquier proceso de desarrollo.
La caracterstica iterativa del RUP, permite:
El entendimiento incremental del problema a travs de

refinamientos sucesivos.
Habilitar la fcil retroalimentacin del usuario.
Establecer metas especficas que permiten al equipo de

desarrollo mantener su atencin en producir resultados.
La medicin del
implementaciones.
3.5.4.
progreso
es
conforme
avanzan
las
DIRECCIN O ADMINISTRACIN DE LOS REQUISITOS
Es el acercamiento sistemtico a encontrar resultados,

mientras se documenta, se organiza y
se rastrea los
requisitos de un sistema.
Formalmente es el establecimiento del acuerdo entre los
clientes y el grupo del proyecto para administrar los cambios
de requerimientos en el sistema. Los puntos clave en el
manejo de requisitos son el mantenimiento de una visin clara
de los requisitos en conjunto con los atributos aplicables y
la proyeccin a otros requisitos
y/o
artefactos del
proyecto.
38
Tomo I
Los requerimientos no son fciles de expresar claramente

en palabras.
La abundancia de requerimientos puede ser difcil de
manejar por ende de controlar.
Los requerimientos cambian con mucha frecuencia.
Existen diversos tipos de requerimientos y diferentes
niveles de detalle.
Los requisitos no siempre son obvios y
tienen
diferentes fuentes.
Se debe tener en cuenta las siguientes habilidades para

lograr el
xito aun con las dificultades que pueden
presentar los requisitos:
El anlisis y entendimiento del problema.

Comprender
las
necesidades
de
cada
uno
de
los
involucrados en el proyecto.
Definir claramente el sistema en base a casos de uso.
Definir claramente el alcance del proyecto.
Refinar constantemente la definicin del sistema.
Realizar
el seguimiento y control a los requisitos
cambiantes.
3.5.5.
PROCESO CONFIGURABLE
El Proceso Unificado Rational (RUP), es bastante

general
y
completo,
puede
ser
usado
en
muchas
organizaciones de software (organizaciones proyectizadas2 y
matriciales balanceadas3). En muchas circunstancias, este
proceso de ingeniera de software necesitar ser modificado,
ajustado, extendido y entallado para acomodarse a
las
caractersticas
especficas,
circunstancias,
entorno
cultural, organizacional
y poltico de la organizacin que
lo adopta.
Los elementos del proceso de ingeniera de software que
probablemente sern modificados, personalizados, agregados o
suprimidos son los siguientes:
2
3
Artefactos
Actividades
Organizacin Proyectizada: Organizacin con labores centradas en proyectos.

Organizacin Matricial Balanceada: Organizacin con labores funcionales y proyectizadas, es una mixtura.
39
Tomo I
Flujos de trabajo
Obreros
3.5.6.
TECNICAS DE MODELAMIENTO VISUAL
El RUP, al utilizar diferentes tcnicas de modelamiento

visual, permite:
La
captura
de
la
estructura,
comportamiento
de
arquitecturas y componentes.
Mostrar como encajan de forma conjunta los elementos del
sistema.
Mantener
la
consistencia
entre
un
diseo
y
su
implementacin.
Promover la comunicacin no ambigua.
3.5.7.
DESARROLLO BASADO EN COMPONENTES
Gracias a la propiedad de herencia, adoptado de la

Metodologa Orientada a Objetos, el proceso RUP, permite el
desarrollo de software basado en componentes, el cual brinda
ventajas importantes como:
Permite enfocarse en el pronto desarrollo de una

arquitectura ejecutable robusta.
Es intuitivamente comprensible.
Promueve la reutilizacin ms efectiva de software.
Permite la construccin rpida de software. Si tienes
gran cantidad de componentes reutilizables se puede
finalizar el proyecto
informtico en
un tiempo
realmente corto.
Es derivada a partir de los casos de uso ms
importantes.
3.6. ESTRUCTURA DEL RUP:
El proceso RUP, se divide

dos ejes, ver figura N 24.
en dos dimensiones, a razn
de
El eje horizontal representa al tiempo, detalla el

aspecto dinmico del proceso, expresado en trminos de
ciclos, fases, iteraciones y metas.
40
Tomo I
El eje vertical representa la caracterstica

esttica
del proceso, detalla como est descrito en trminos de
actividades, artefactos, trabajadores y flujos de
trabajo.
Figura 24, Fases y Etapas del Proceso Unificado Rational.

3.7. FASES
3.7.1.
GESTACIN CONCEPCIN
Esta fase permite el establecimiento de los objetivos y

el plan del proyecto al definir su alcance.
El propsito es establecer los casos de uso de negocio
para el nuevo sistema o para alguna actualizacin importante
del sistema existente.
En esta etapa se establece la visin general de los
requerimientos
del
proyecto
y
de
los
requerimientos
principales para la construccin del software, definiendo el
modelo inicial de casos de uso y el modelo del dominio.
Se realiza la evaluacin inicial de riesgos y la
estimacin de los recursos requeridos,
para minimizar los
riesgos evitar que los riesgos se conviertan en problemas.
41
Tomo I
Esta etapa es ideal

conceptos,
polticas
de
artefactos.
3.7.2.
para definir el glosario

creacin
y
nombramiento
de
de
PREPARACIN ELABORACIN
Permite la definicin de la arquitectura, desarrollo del

plan del proyecto y la especificacin de caractersticas del
sistema.
Esta etapa permite definir la funcionalidad del software
a construir, al clasificar y priorizar los casos de uso del
sistema.
En esta fase empezamos a desarrollar la programacin
lgica expresados en diagramas (realizados en los modelos de
anlisis),
se realiza el anlisis & diseo de la base de
datos, pasando por el modelo conceptual, el modelo lgico y
el modelo fsico de la base de datos.
Se
realizan las pruebas de certificacin y control de
calidad hasta llegar al final de la iteracin n, todas las
etapas mencionadas se pueden realizar en paralelo, regresando
a la etapa anterior proyectndose a la etapa siguiente,
gracias al modelo iterativo-incremental en el que se basa el
proceso.
3.7.3.
CONSTRUCCIN
En esta fase se desarrolla el cdigo final, se construye

el producto final.
El
propsito
de
esta
fase
es
desarrollar
incrementalmente el producto software completo el cual estar
listo para ser transferido al usuario:
Se producen los siguientes artefactos:
Despus de realizar el proceso de ingeniera reversa, se

realiza el modelo completo de diseo y casos de uso,
producto del cdigo de la implementacin
Liberaciones de productos ejecutables de funcionalidad
incremental (versiones, prototipos)
Documentacin tcnica del sistema
Manuales de usuario
42
Tomo I
Se obtiene la versin beta del producto
3.7.4.
TRANSICIN
Se realiza la transicin del producto en el entorno

usuario.
Esta
fase,
est
dedicada
a
establecer
los
lineamientos
de
performance,
logrando
as
cubrir
las
expectativas de usuario.
Se obtienen los siguientes artefactos:
Produccin de ejecutables de producto

Modelo de componentes al realizar la compilacin y
despliegue de componentes en base a la ingeniera
reversa
Modelo de diseo actualizado en base a la Ingeniera
reversa
Pruebas beta
del software para validar el nuevo
sistema versus las expectativas del usuario
Manuales de usuario actualizados
Documentacin de desarrollo actualizada
Se realiza el proceso
de retroalimentacin desde el
punto de vista del usuario referente a la reciente
implementacin. Se contesta a las siguientes preguntas
el usuario est satisfecho?, los gastos reales de los
recursos versus gastos previstos son aceptables?
Uno de los puntos de importancia en esta fase es el

desarrollar el plan de soporte y mantenimiento para el
sistema de informacin que acaba de ser puesto en produccin,
se define cada cuanto tiempo se realizar el mantenimiento,
caractersticas del equipo de mantenimiento, procesos de
supervisin, polticas a seguir en el proceso de copia de
seguridad y las polticas de registro a los nuevos usuarios.
43
Tomo I
3.8. ETAPAS
3.8.1.
DISCIPLINAS CENTRALES
3.8.1.1.
MODELO DE NEGOCIO
Analiza la organizacin en trminos de procesos y las

personas u organizaciones que influencian participan en l,
de forma directa indirecta. El modelo de negocio sirve
para determinar cual es el problema de la organizacin.
Presenta dos etapas:
MODELO DE CASOS DE USO DE NEGOCIO
Este modelo muestra la relacin existente entre un actor

de negocio externo interno y al caso de uso de negocio,
desde el punto de vista general.
MODELO DE OBJETOS DE NEGOCIO
En esta etapa se define el detalle del negocio en trminos

de procesos empresariales; el caso de uso de negocio definido
en la etapa anterior pasa por el proceso de realizacin,
donde utilizando diferentes vistas del UML como: diagrama de
casos de uso (realizacin del caso de uso), diagrama de
clase, diagramas de secuencia, diagramas de colaboracin
e
incluso el diagrama de actividades se llega al detalle de
funcionalidad del proceso empresarial que se analiza.
3.8.1.2.
FUNCIONALIDAD
En esta etapa se define qu hace el sistema?, para

responder la interrogante anterior se realiza diversos
procesos para
el anlisis de los requerimientos, logrando
definir cuales sern las opciones del men principal del
sistema incluyendo cada uno de las sub opciones incluso
definir las interfaces del sistema final.
3.8.1.3.
ANLISIS
Esta etapa
est dirigida al anlisis de la informacin
obtenida
en el negocio, despus de haber definido la
funcionalidad del software que se construye en la etapa
anterior,
es necesario definir como se realizar la
44
Tomo I
implementacin
en
base
a
todos
los
requerimientos
establecidos. El
Proceso Unificado Rational, propone los
denominados, clasificadores de anlisis, para realizar la
programacin lgica; este muestra
el detalle de cmo se
realizar
los procesos de funcionalidad del software final.
Ejemplo: cmo
independiente?
se
inserta
un
registro
Para el desarrollo de la interrogante

necesario conocer las siguientes entradas:
una
tabla
anterior
es
En qu parte del men principal se encuentra la opcin

de insercin del nuevo registro.
Cuntas y cules son las interfaces que participan en el
proceso de insercin del registro
Cul es la tabla de la base de
datos, obviamente,
debemos definir la estructura de la futura tabla, que
an no existe.
Por ltimo se propone un modelo utilizando los
clasificadores
de
anlisis
y
artefactos
del
UML
mostrando
la
relacin
lgica
de
participacin
e
interaccin entre cada uno de los artefactos que
participan para lograr insertar el registro en una tabla
independiente.
3.8.1.4.
DISEO
Esta etapa
causa duda y controversia, entre muchos
autores de libros artculos en la web, en ms del 60% del
material bibliogrfico investigado para la presente edicin,
existe dudas con respecto a esta etapa, para muchos autores
esta es la etapa de implementacin lgica del software, hay
algunos
que
pretenden
hacer
una
comparacin
con
la
metodologa estructurada y su tpico modelo entidad /
relacin (E/R) para la construccin de la base de datos. Es
lamentable que las justificaciones sean slo tericas.
La programacin lgica ya fue definida en la etapa de
anlisis, en la etapa de diseo nos dedicamos a la
construccin de la base de datos relacional / objeto,
Es importante mencionar que NO existe comunin entre el
modelo E/R y el modelo de Objetos. Es imposible compararlos
ya que tienen puntos de partida y consecuencias diferentes.
45
Tomo I
En diseo tenemos que tomar

en cuenta la informacin
proveniente de etapas anteriores,
se inicia una de las
actividades ms importantes en el proceso de construccin de
software, el anlisis y diseo de la base de datos, y la
primera propuesta del modelo de diseo del futuro software.
Realizaremos el modelo orientado a objetos, definido por
etapas iterativas de desarrollo desde el modelo conceptual,
pasando por el modelo lgico hasta llegar al modelo fsico
que es el modelo de base de datos relacional objeto
propiamente dicho.
El objetivo del modelo orientado a objetos es la
construccin de una base de datos relacional objeto que
cumpla con todos los criterios de performance y calidad.
Los criterios de calidad de la base son los siguientes:
la base de datos No debe permitir nulos, ni redundancia
logrando la homogeneidad, sin pasar por el tedioso mtodo de
normalizacin, el cual
es un trmino no existente en el
proceso RUP.
3.8.1.5.
IMPLEMENTACIN
En esta etapa se administra la generacin de archivos,

empezamos la codificacin para producir el software final, se
debe tener en cuenta los artefactos producidos en las
anteriores etapas, sobre todo el modelo de la base de datos
relacional objeto (clases con el estereotipo tabla
relacional - objeto, estructura, relaciones entre clases, las
llaves primarias y los campos forneos)
y el modelo de
anlisis (programacin lgica en trminos de diagramas).
Ya terminada la etapa de implementacin, realizamos el
proceso de ingeniera reversa para actualizar para primera
propuesta del diseo,
este proceso es til para garantizar
el cumplimiento de todos los requerimientos del usuario.
3.8.1.6.
CERTIFICACIN
Esta etapa analizamos los prototipos, por cada caso de

uso. Gracias a la caracterstica del modelo iterativo e
incremental del RUP, se construyen diversos prototipos, los
cuales debern pasar por un estricto control de calidad,
definiendo con certeza cuales son los prototipos que cumplen
46
Tomo I
con los requerimientos

anteriores.
del
usuario
definido
en
etapas
Existen muchos mtodos de prueba de calidad de software,

recomiendo el proceso de ingeniera reversa. Con este proceso
probamos que la primera propuesta del diseo
realizado en
base al modelo de anlisis es consecuente con la segunda
propuesta del diseo, obtenido como producto del proceso de
ingeniera reversa.
3.8.1.7.
ENTREGA
Se gestiona el proceso de puesta en marcha del software,

este debe estar preparado para la
produccin
siendo
flexible para facilitar el proceso de integracin con otros
sistemas de la organizacin.
Es requisito indispensable que los sistemas de informacin
hayan
aprobado
todos
los
lineamientos
de
calidad,
establecidos en la etapa de pruebas,
es suficiente la
presencia de un error en el sistema de informacin para No
entregar el software resultado.
3.8.2.
DISCIPLINAS DE SOPORTE
3.8.2.1.
CONTROL DE CAMBIOS
Establecimiento de polticas
de gestin para la
administracin de cambios en el proyecto de construccin del
software.
Los cambios
generalmente vienen de los principales
involucrados del proyecto los clientes, esos cambios
son
clasificados en 2 categoras:
Cambios
relevantes, aquellos que tienes repercusiones
serias en el desarrollo del proyecto, incluso se puede
modificar la estructura de la base de datos y la
propuesta de interfaces.
Cambios
irrelevantes,
aquellas
que
pueden
ser
solucionados
sin mayor dificultad,
este tipo de
cambios no repercute en modificaciones mayores tanto en
el mbito de aplicacin como en el mbito de la base de
datos.
47
Tomo I
Al inicio del proyecto se establecen las polticas de

control de cambio, quin es la
persona personas
integrantes del grupo de desarrollo que
recepcionarn los
pedidos de cambio; se resuelven las siguientes interrogantes
Cules son los formatos de recepcin?, Cules son los
medios
de
recepcin
del
cambio?,
Cules
son
las
restricciones
y supuestos, con respecto al manejo del
cambio?
3.8.2.2.
GESTIN DE PROYECTOS
El xito de la construccin del

depende
del
proceso,
es
necesario
administracin del proyecto y proceso
funcionen de forma mancomunada, slo as
en la construccin de software.
software no solo
que
el
binomio
de construccin,
se logra el xito
La gerencia de proyectos provee el marco que permite

cumplir con los objetivos de la organizacin usando un
proceso estructurado y controlado. Comprende varias tcnicas,
herramientas y metodologa que permiten al gerente y su
equipo llevar a cabo un proyecto que cumpla con el principio
del cuarto cuadrante4.
El proyecto deber cumplir:
Con terminar en el tiempo pactado.

Dentro de los lmites de presupuesto.
Con la calidad esperada por el cliente.
Con el alcance establecido en la definicin de proyecto.
El
rol
del
gerente
de
proyectos
es
de
gran
responsabilidad, siendo el encargado de dirigir y supervisar
el proyecto de principio a fin.
Algunas de sus principales tareas sern:
Definir el proyecto: debe definir el alcance del

proyecto, estableciendo sus lmites, en otras palabras,
se aclara que procesos, departamentos elementos de la
organizacin forma parte del proyecto.
Esto es fundamental para prevenir un crecimiento
indeseado del proyecto, a medida que se progresa. Es
Principio del Cuarto Cuadrante: Este principio indica los 4 factores de xito para un proyecto: el TIEMPO,
el COSTO, la CALIDAD y el ALCANCE.
48
Tomo I
importante diferenciar claramente aquellos elementos y

resultados que son absolutamente necesarios, de aquellos
que son deseables.
Planificar el proyecto: planificar el proyecto implica

proponer la solucin a desarrollar, en base a los
objetivos y resultados necesarios, y establecer cmo la
desarrollar. Los puntos mas importantes a considerar
son: estrategia (cmo se relaciona el proyecto con el
plan estratgico de la empresa), recursos (que necesito
y con qu cuento), finanzas (cuanto costar y dnde
obtener el dinero) y tiempo (de cunto tiempo se
dispone).
Obtener el respaldo de la alta gerencia: para el xito

de
cualquier
proyecto,
es
fundamental
el
apoyo
irrestricto de uno o mas gerentes de alto nivel. Esto
har mucho mas fluido todo el proceso, incluyendo la
obtencin de recursos, lograr la colaboracin de toda la
empresa
y
la
resolucin
de
conflictos
entre
departamentos si es posible.
Formar el equipo humano: Identificar y ubicar a aquellas

personas mejor calificadas para las distintas tareas
involucradas. Con frecuencia, el equipo se forma con
personas
provenientes
de
distintas
reas
de
la
organizacin, por lo que no reportan directamente al
gerente del proyecto. En ocasiones, es necesario
reforzar el equipo con personas de fuera del entorno de
trabajo, en cuyo caso hay que hacer el reclutamiento.
Obtener los recursos: Es responsabilidad del gerente de

proyectos asegurar los recursos (dinero, equipos,
personal de apoyo, espacio fsico, etc.) que le permita
al equipo funcionar en forma efectiva.
Definir
las
operaciones:
Incluye
determinar
las
herramientas a utilizar (ej. software de manejo de
proyectos),
definir
los
canales
de
comunicacin,
establecer la logstica, etc.
Controlar el proyecto: Asegurar que las metas se estn

logrando y que el proyecto sigue el curso planificado.
En el transcurso del desarrollo del proyecto,
surgirn cambios e imprevistos, en cuya circunstancia,
49
Tomo I
es labor del gerente mantener la flexibilidad que le

permita adaptarse, corregir y/o ajustar, sin poner en
peligro los resultados.
Para evitar problemas de fracaso del
gestores del proyecto deben prestar especial
principales
razones
de
proyecto, los
atencin a las
fracaso:
Mala definicin o concepcin del proyecto

Cambios en el alcance o definicin del proyecto
Falta de una metodologa adecuada para la administracin
del proyecto
Falta de planificacin en el control de los cambios
Falta de comunicacin entre los miembros del equipo
entre ellos y el resto de la empresa
Falta de claridad del contrato en trminos de supuestos
y restricciones
Desacuerdos entre clientes y los gerentes de proyecto
3.8.2.3.
ENTORNO
El anlisis del entorno, establece criterios polticas

que permitan
el proceso de puesta en marcha
del software
construido. El nuevo software debe funcionar adecuadamente
con los otros sistemas de informacin de la organizacin
facilitando as el proceso de integracin de los sistemas.
El sistema de informacin necesita cumplir con la
factibilidad tcnica5 y operativa6, para lograr el xito en
la organizacin.
Factibilidad Tcnica: La organizacin debe estar preparada tcnicamente para asegurar el xito de la
implementacin del software en trminos de Hw. Sw. Telecomunicaciones y equipos.
6
Factibilidad Operativa: Se cumple esta factibilidad cuando la construccin del software satisface a los
usuarios en trminos de requisitos y amigabilidad.
50
Tomo I
3.9 ROLES U OBREROS
Implementador
de Casos de Uso
Implementador
de Casos de Uso
Figura 25, Actividades y Artefactos de los Obreros segn el

Proceso Unificado Rational.
Un rol (obrero) define el conjunto de acciones,

conductas (en las actividades) y
responsabilidades (en los
artefactos) que puede ser desempeado por un individuo o
conjunto de individuos en la organizacin de desarrollo.
Cada obrero realizar un conjunto de actividades
relacionadas con el dominio y conocimiento del tema.
Se puede considerar a un obrero como un "sombrero" que
un individuo puede llevar en el proyecto, el obrero puede
vestir ms de un sombrero en el proyecto de construccin del
software.
Los obreros NO son los individuos, los obreros describen
cmo los individuos deben comportarse en el negocio y qu
responsabilidades deben tener.
El RUP establece 30 roles diferentes. Una de las
preguntas ms comunes es necesitamos 30 personas como mnimo
para abordar la construccin de un software?, la respuesta
obviamente es NO, una persona puede realizar ms de un rol
en el desarrollo del proyecto, eso depender de su
experiencia, conocimiento y habilidades; se debe
tener
especial cuidado en la asignacin de roles, este trabajo debe
ser realizado por el ingeniero de software con colaboracin
y comunin del equipo de desarrollo, una persona no puede
51
Tomo I
asumir dos roles dependientes, es decir una misma persona NO

puede ser juez y parte.
Por ejemplo:
Si un individuo aborda el rol de especificador de un
elemento, NO podr abordar el rol de revisor del mismo
elemento.
El RUP,
considera los siguientes
3.9.1.
trabajadores:
TRABAJADOR COMUN (ANY WORKER)
Figura 26A, Funciones del Trabajador Comn.

Un trabajador comn definido por el RUP, puede tener
niveles de acceso y privilegios, puede ingresar y salir de
algn artefacto relacionado con el mantenimiento del sistema,
ver figura N 26A.
52
Tomo I
3.9.2.
ARQUITECTO (ARCHITECT)
Figura 26B, Funciones del Arquitecto.

El Arquitecto dirige y coordina las actividades tcnicas y
los artefactos a lo largo del proyecto.
El Arquitecto
establece
la
estructura
global
para
cada
vista
arquitectnica:
La descomposicin de la vista, la agrupacin de elementos
y la comparacin con otros obreros.
El punto de vista del Arquitecto es profundo y global, ver
figura N 26B.
53
Tomo I
3.9.3.
REVISOR DE LA ARQUITECTURA (ARCHITECTURE

REVIEWER)
Figura 27, Funciones del Revisor de la Arquitectura.

Planea y conduce la revisin formal de la arquitectura y
el software en general, ver figura N 27.
3.9.4.
ANALISTA DE PROCESOS DE NEGOCIO (BUSINESS

PROCESS ANALYST)
Figura 28, Funciones del Analista de Procesos de Negocio.

Lidera y coordina el modelamiento de los casos de uso de
negocio para detallar y delimitar la organizacin que est
54
Tomo I
siendo modelada, por ejemplo definir que actores internos,

externos y que casos de uso de negocio existen. Tambin
analizan sus relaciones, ver figura N 28.
3.9.5.
DISEADOR DE NEGOCIO (BUSINESS DESIGNER)
Figura 29, Funciones del Diseador
de Negocio.
Detalla la especificacin de una parte de la organizacin

para describir el flujo de trabajo de uno muchos casos de
uso, se encarga de especificar que actores y entidades
de
negocio, se necesitan para realizar el caso de uso de negocio
describiendo el comportamiento de los casos de uso en los
actores y entidades. El diseador de negocio, define las
responsabilidades, operaciones, atributos y relaciones de uno
o muchos trabajadores de negocio con sus respectivas
entidades de negocio, ver figura N 29.
55
Tomo I
3.9.6
REVISOR DEL MODELO DE NEGOCIO (BUSINESS-MODEL

REVIEWER)
Figura 30, Funciones del Revisor del Modelo de Negocio.

Participa en revisiones formales
de los modelos de
casos de uso y los modelos de objetos de negocio, ver figura
N 30
3.9.7. DISEADOR DE LA ESTRUCTURA (CAPSULE DESIGNER)
Figura 31, Funciones del Diseador de la Estructura.

Su funcin es asegurar que el sistema pueda responder a los
eventos de manera oportuna, acorde a los requisitos
del
usuario, ver figura N 31.
56
Tomo I
3.9.8.
CRTICO DEL CDIGO (CODE REVIEWER)
Figura 32, Funciones del Crtico del Cdigo.

Un crtico del cdigo es responsable de:
Asegurar la calidad del cdigo fuente

Planear y conducir la revisin
del cdigo fuente, ver
figura N 32.
3.9.9.
ADMINISTRADOR DE LA CONFIGURACIN
(CONFIGURATION MANAGER)
Figura 33, Funciones del Administrador de la Configuracin.
57
Tomo I
Es responsable para mantener toda la infraestructura y el

ambiente que el grupo de desarrollo necesita para probar el
producto
que
construyen.
El
administrador
de
la
Configuracin tambin es responsable de escribir el Plan de
control para la demanda de cambios de configuracin y las
estadsticas de progreso, ver figura N 33.
3.9.10.
DESARROLLADOR DEL CURSO (COURSE DEVELOPER)
Figura 34, Funciones del Desarrollador del Curso.

El diseador del curso desarrolla el material de
entrenamiento para ensear a los usuarios cmo usar el
producto. Esto incluye la creacin de diapositivas, notas
para el estudiante, ejemplos, guas didcticas y todo lo
necesario para reforzar la comprensin del producto, ver
figura N 34.
58
Tomo I
3.9.11.
DISEADOR DE LA BASE DE DATOS (DATABASE

DESIGNER)
Figura 35, Funciones del Diseador de la Base de Datos.

El diseador de la base de datos define que las tablas,
ndices, vistas, constraints, triggers, stored procedures,
espacios de tablas o parmetros del almacenamiento, y otras
estructuras de la base de datos que se necesitan guardar,
recuperar adems de anular los objetos persistentes, ver
figura N 35.
59
Tomo I
3.9.12.
GERENTE DEL DESPLIEGUE (DEPLOYMENT MANAGER)
Figura 36, Funciones del Gerente del Despliegue.

El gerente del despliegue es responsable para los planes
de transicin el producto a la comunidad del usuario,
encargado de documentar
los planes del despliegue, ver
figura N 36.
60
Tomo I
3.9.13.
REVISOR DE DISEO (DESIGN REVIEWER)
Figura 37, Funciones del Revisor de Diseo basado en el RUP.

El revisor de diseo planea y establece polticas para
las revisiones formales de los
Artefactos de diseo, ver
figura N 37.
3.9.14.
DISEADOR (DESIGNER)
Figura 38, Funciones del Diseador.
61
Tomo I
El
diseador
define
las
responsabilidades,
funcionamientos, atributos, y relaciones de uno o varias
clases, determina como deben relacionarse las clases en el
ambiente de aplicacin, ver figura N 38.
3.9.15.
IMPLEMENTADOR (IMPLEMENTER)
Figura 39, Funciones del Implementador.

Un implementador, es responsable de desarrollar y probar
los componentes de acuerdo con las normas adoptadas por el
proyecto, como la definicin de estndares que permita a las
clases integrarse con sub sistemas
ms grandes, ver figura
N 39.
62
Tomo I
3.9.16.
CONTROLADOR
TESTER)
DE
LA
INTEGRACIN
(INTEGRATION
Figura 40, Funciones del Controlador de la Integracin.
El controlador de la integracin, es responsable

ejecutar la prueba de integracin, sus acciones incluye:
de
Realizar la prueba de estructuracin y ejecucin

Realizar la
evaluacin de la prueba
de ejecucin y
recuperacin de los errores
Definir La evaluacin
de los resultados de la prueba
identificando y documentado los defectos, ver figura N
40.
63
Tomo I
3.9.17.
CONTROLADOR DE CALIDAD (PERFORMANCE TESTER)
Figura 41, Funciones del Controlador de Calidad.

El controlador de calidad es responsable de ejecutar la
prueba de calidad del software, sus acciones incluye:
Realizar la prueba de
estructuracin y ejecucin, con
respecto a la calidad.
Definir la evaluacin de la ejecucin y de la prueba de
recuperacin de errores evaluando los resultados de
prueba, identificando y definiendo los factores que
afectan a la performance y la calidad
del software, ver
figura N 41.
64
Tomo I
3.9.18.
INGENIERO DE PROCESOS (PROCESS ENGINEER)
Figura 42, Funciones del Ingeniero de Procesos.

El Ingeniero de Procesos es responsable del proceso de
desarrollo de software respectivamente, incluye la definicin
y configuracin del proceso antes del inicio del proyecto y
durante el desarrollo del proyecto. Este continua brindando
mejoras
en la aplicacin del proceso de desarrollo del
software, ver figura N 42.
65
Tomo I
3.9.19.
GESTOR DEL PROYECTO(PROJECT MANAGER)
Figura 43, Funciones del Gestor del Proyecto.

El gestor de proyectos se encarga de
administrar los
recursos,
prioridades,
coordina
interacciones
con
los
clientes y usuarios, hace que el inters del equipo de
desarrollo se mantenga centrado con el objetivo del proyecto.
Estable el conjunto de prcticas que asegura la calidad e
integridad de los artefactos del proyecto, adems es
responsable de la efectividad
del software en trminos de
funcionalidad, adaptabilidad, robustez y flexibilidad, ver
figura N 43.
66
Tomo I
3.9.20.
CRTICO DE REQUISITOS (REQUIREMENTS REVIEWER)
Figura 44, Funciones del Crtico de Requisitos.

Planea y administra la revisin formal de los modelos de
casos de uso, ver figura N 44.
3.9.21.
INVOLUCRADOS (STAKEHOLDERS)
Los involucrados son individuos y organizaciones que estn

activamente involucrados con el proyecto o cuyos intereses
pueden estar afectados positiva o negativamente por los
resultados de la ejecucin del proyecto o de la culminacin
del mismo. Ellos tambin pueden influenciar sobre el proyecto
y sus resultados.
El equipo de gerencia del proyecto debe identificar a los
involucrados del proyecto, determinar sus
requerimientos,
luego administrar e influenciar esos requerimientos para
seguir el xito del proyecto.
La identificacin de los involucrados es a menudo tedioso.
Los involucrados principales del un proyecto, incluyen a:
Gerente del proyecto

Cliente
Organizacin ejecutora
Miembros del equipo de desarrollo
Patrocinador
67
Tomo I
3.9.22.
ADMINISTRADOR
ADMINISTRATOR)
DEL
SISTEMA
(SYSTEM
Figura 45, Funciones del Administrador del Sistema.

El administrador del sistema mantiene el ambiente de
desarrollo, hardware, software, administracin del sistema,
realiza copias de seguridad, registra a los usuarios
estableciendo sus privilegios, ver figura N 45.
68
Tomo I
3.9.23.
ANALISTA DEL SISTEMA (SYSTEM ANALYST)
Figura 46, Funciones del Analista del Sistema.

El analista del sistema, planea y coordina
el proceso
de identificacin, seleccin de los modelos de casos de uso,
estableciendo la funcionalidad y parmetros del sistema.
Algunas de las actividades son:
La identificacin de
los actores y casos de uso
La estructuracin de los modelos de casos de uso
Para ms detalle, ver la figura N 46.
69
Tomo I
3.9.24.
INTEGRADOR DEL SISTEMA (SYSTEM INTEGRATOR)
Figura 47, Funciones del Integrador de Sistemas.

Es el encargado de planear el proceso de integracin del
software con otros construidos en forma paralela con los
que ya existen en la organizacin
patrocinadora, el
integrador debe establecer polticas de integracin
con la
finalidad de evitar conflictos de funcionamiento global con
los software actuales y los futuros, ver figura N 47.
70
Tomo I
3.9.25. PROBADOR DEL SISTEMA (SYSTEM TESTER)
Figura 48, Actividades del Probador del Sistema.

Es el encargado de planificar, disear y ejecutar las
pruebas del sistema de informacin, las pruebas incluyen:
La prueba de estructura y ejecucin

La evaluacin del proceso de ejecucin de
pruebas y
propuesta de solucin de errores
La evaluacin de
resultados del proceso de prueba y
documentacin del conjunto de errores hallados en el
proceso, ver figura N 48.
71
Tomo I
3.9.26. DOCUMENTADOR (TECHNICAL WRITER)
Figura 49, Funciones del Documentador.

Es el encargado de producir material de apoyo al usuario
final como las guas del usuario, los textos de ayuda, las
notas del descargo, etc., ver fig. N 49.
3.9.27. DISEADOR DE PRUEBAS (TEST DESIGNER)
Figura 50, Funciones del Diseador de Pruebas.
72
Tomo I
El Diseador
de Pruebas es el principal obrero en el
proceso de pruebas, es el encargado de la planificacin,
aplicacin y evaluacin de las pruebas, incluye las
siguientes actividades:
La
La
La
de
generacin del plan y modelo de prueba

aplicacin de procedimientos de prueba
evaluacin de la estructura, resultados y efectividad
las pruebas, para ms detalle, ver figura N 50.
3.9.28. ADMINISTRADOR DE HERRAMIENTAS (TOOLSMITH)
Figura 51, Funciones del Administrador de Herramientas.

Es el encargado de desarrollar las herramientas de apoyo a
necesidades especiales, proporciona herramientas y procesos
adicionales como solucin a tareas tediosas en la correccin
de errores, define adems la buena
integracin entre tales
herramientas, ver figura N 51.
73
Tomo I
3.9.29. ESPECIFICADOR DE CASOS DE USO (USE-CASE SPECIFIER)
Figura 52,
Funciones del Especificador de Casos de Uso.
Es el encargado de detallar la especificacin de

una
parte de la funcionalidad del sistema describiendo los
aspectos de requerimiento de uno o muchos casos de uso,
adems es responsable del mantenimiento e integracin
del
paquete de casos de uso (casos de uso, actores, modelo de
casos de uso), ver figura N 52.
74
Tomo I
3.9.30. DISEADOR DE LAS INTERFACES DE USUARIO (USER

INTERFACE DESIGNER)
Figura 53,
Usuario.
Funciones
del
Diseador
de
la
Interfaces
de
Es el encargado de coordinar las actividades de anlisis

de prototipos
con respecto a las interfaces de usuario,
mediante:
La captura de requerimientos para las interfaces de

usuario
La construccin de prototipos de las interfaces de
usuario
La consideracin de opiniones de los involucrados del
proyecto para la definicin de interfaces, ver figura N
53.
75
Tomo I
3.10. ACTIVIDAD
Figura 54, Actividades del Analista de Procesos de Negocios.

La actividad, describe una unidad de trabajo que puede
ser asignada a un trabajador. Ejemplo Crear o modificar un
artefacto, ver figura N 54.
Una actividad lleva entre un par de horas, un par de
das un poco ms dependiendo de la habilidad, experiencia y
conocimiento del trabajador, involucra un solo trabajador y
un nmero pequeo de artefactos.
Las actividades se consideran en
evaluacin del progreso del proyecto.
la
planificacin
3.11. ARTEFACTO:
Definido como la pieza de informacin que es producida,
modificada, utilizada por un proceso en particular, son
productos tangibles del proyecto, usados por los trabajadores
para realizar nuevas actividades y son el resultado de esas
actividades. Pueden ser los siguientes:
El documento, donde se especifiquen a los casos de uso

de negocio
donde se define la arquitectura del
software.
El modelo, como el modelo de caso de uso, modelo de

anlisis, modelo de diseo, etc.
76
Tomo I
Un elemento dentro de un modelo tal

un sub sistema.
como una clase
Ahora mencionar cuales son los artefactos a utilizar en

cada de una de etapas de construccin de software segn el
RUP, tanto en las etapas centrales como de soporte.
No se trata de memorizar que artefacto producir un
trabajador, el uso constante de
estos har que sean parte
tcita del desarrollo de software, slo tenemos que
aplicarlo.
Para evitar la complejidad que DETESTO, aprenderemos los
diferentes artefactos por etapas de construccin del software
utilizando grficos relacionados con la notacin UML:
3.11.1. ARTEFACTOS DEL MODELO DE NEGOCIO

A continuacin detallo todos los artefactos creados
utilizados por un trabajador, con respecto a la etapa de
MODELO DE NEGOCIO.
C o n d u c to r
S ec r e ta ri a
R e g i s tr a r C o n d u c to r
Modelo de
casos de uso
de negocio
Especificacin
suplementaria de
negocio
Analista de
procesos de negocio
Modelo de objetos
de negocio
Figura 55, Artefactos producidos utilizados

trabajador Analista de procesos de negocio.
77
por
el
Tomo I
Realizacin del caso

de uso de negocio
Caso de uso
de negocio
Diseador
de negocio
Entidad de
negocio
Trabajador
interno de
negocio
Unidad
organizacional
Objetivo de
negocio
Figura 56, Artefactos producidos

trabajador Diseador de Negocio.
utilizados
por
el
3.11.2. ARTEFACTOS DE REQUERIMIENTOS

ANALISIS DE REQUERIMIENTOS.
Caso de usos
Especificador
de casos de uso
Paquete de
casos de uso

trabajador Especificador de Casos de Uso.
78
por
el
Tomo I
Glosario
Analista de
sistemas
Caractersticas
de los requerimientos
Requerimiento de
involucrados
Visin
C o n d u c to r
S ec r e ta ri a
R e g is tr a r
C o n d u c to r
Especificacin
suplementaria
Modelo de casos
de uso de sistema

trabajador Analista de Sistemas.
Lmite
utilizados
por
el
por
el
Prototipos de
casos de uso
Diseador de
interfaces de usuario
Prototipos de
interfaces de
usuario
Actor

trabajador Diseador de interfaces de usuario.
79
Tomo I
3.11.3. ARTEFACTOS DE DISEO

DISEO.
Modelo anlisis
Seal
Protocolo
Arquitecto
Modelo de diseo
Documento de
la arquitectura de
software
Figura 60, Artefactos

trabajador Arquitecto.
Interface
Evento
producidos
utilizados
por
el
Paquete de diseo
Modelo de
estados
Caso de uso
realizacin de
diseo
Diseador
Clase de diseo
Diseo de subsistemas

trabajador Diseador.
Modelo de clases y paquetes
producidos
80
utilizados
por
el
Tomo I
Modelo de
casos de uso
de negocio
Analista de
procesos de negocio
Modelo de objetos
de negocio
Especificacin
suplementaria de
negocio

trabajador Analista de Proceso de negocio.
por
el
utilizados
por
el

trabajador Diseador de la Base de Datos.
por
el
Estructura
Diseador de
la estructura

trabajador Diseador de la estructura.
Modelo de
Clases
Diseador de la
base de datos
81
Tomo I
Prueba
de procedimientos
Modelo de
pruebas
Diseador de
pruebas
Modelo del
plan de accin

trabajador Diseador de Pruebas.
3.11.4.
Modelo de
casos
utilizados
por
el
ARTEFACTOS DE IMPLEMENTACIN

IMPLEMENTACIN.
Arquitecto
Modelo de
implementacin

trabajador Arquitecto.
producidos
utilizados
por
el
utilizados
por
el
Plan de construccin
de la
integracin
Integrador
del sistema

trabajador Integrador del Sistema.
82
Tomo I
Diseador
de pruebas
Prueba de
escrituras

utilizados
por
el
por
el
Componente
Implementador
Sub sistema
de implementacin
Prueba de sub sistema

y componentes

trabajador Implementador.
utilizados
3.11.5. ARTEFACTOS DE DESPLIEGUE

DESPLIEGUE.
83
Tomo I
Plan de
entrenamiento
Diseador
del curso

trabajador Diseador del Curso.
utilizados
por
el
utilizados
por
el
por
el
Instalacin de
artefactos
Implementador

trabajador Implementador.
Documentador
Tcnico
Documento de
soporte a
usuarios

trabajador Documentador Tcnico.
84
Notas de
realizacin
utilizados
Tomo I
Plan de
despliegue
Administrador
del despliegue

trabajador Administrador del Despliegue.
utilizados
por
el
3.11.6. ARTEFACTOS DE ADMINISTRACIN

ADMINISTRACIN.
Lista de
riesgos
Plan de
desarrollo del
software
Especificacin d
del proyecto
Gestor del
proyecto
Plan de medida
Defectos X
Cambios de
requerimientos
Especificacin de
iteracin
Valoracin de
iteracin
Casos de uso
de negocio
Valoracin de
estatus

trabajador Gestor del Proyecto.
85
utilizados
por
el
Tomo I
Diseador de
pruebas
Plan de pruebas

por
el
utilizados
por
el

trabajador Administrador de la Configuracin.
por
el
Ingeniero
de procesos
Desarrollo de
casos

trabajador Ingeniero de Procesos.
utilizados
Desarrollo de
valoracin
organizativa
Plan de
administracin de
la configuracin
Administrador
de la
configuracin
86
Tomo I
3.11.7. ARTEFACTOS DE ESPECIFICACIN Y PAUTAS

ESPECIFICACIONES.
Herramientas
Administrador
del sistema
Integrador
del sistema
Administrador
de herramientas

administradores.
producidos
Analista de
procesos de negocio
utilizados
por
los
Base del
modelo de negocio
Figura 79, Artefactos producidos o utilizados por el Analista

de Procesos de Negocio.
Analista de
sistemas
Base del
modelo de casos
de uso
Desarrollo de
valoracin
organizativa
Base de las caractersticas

de requerimientos

trabajador Analista de Sistemas.
87
utilizados
por
el
Tomo I
Diseador de
interfaces de
usuario
Base de
interfaces de usuario

trabajador Diseador de Interfaces de usuario.
por
el
3.12. PROCESO UNIFICADO RATIONAL Y EL CASE DE MODELAMIENTO

RATIONAL ROSE, EN EL TRABAJO DE NEGOCIO.
Figura 82, Ventana de Creacin de nuevos modelos en el Case

de Modelamiento Rational Rose.
El Case Rational Rose, es la herramienta de modelado que
soporta las fases y etapas del proceso RUP, para utilizar las
ayudas y libreras del RUP en Rational Rose, hacer clik en
la plantilla Rational Unified Proccess, luego clik en el
boton ok, ver figura N 82.
88
Tomo I
Figura 83, Browser del Case Rational

paquete de casos de uso de negocio.
Rose,
sealando
al
Despus de cagar las libreras del RUP

, se tiene una
plantilla de trabajo, desde un punto de vista general,
definido en el paquete Business Use Case Model, entorno
donde se crea los siguientes artefactos:
Caso de uso de negocio

Actor interno de negocio
Actor externo de negocio
Unidad organizacional
Modelo de casos de uso de uso de negocio.
Adems se realzan las siguientes actividades:
Definicin de unidades organizacionales

Seleccin de actores internos y externos
Definicin de procesos empresariales
Establecimiento de criterios y polticas de accin para
la creacin de los modelo de casos de uso de negocio,
ver figura N 83.
89
Tomo I
Figura 84, Browser del Case Rational

paquete modelo de objetos de negocio.
Rose,
sealando
al
El punto de vista detallado, se define en el paquete

Business Object Model, en este entorno se crea los
siguientes artefactos:
Diagramas
Diagramas
Diagramas
Diagramas
Entidades
de
de
de
de
de
realizacin del caso de uso de negocio

clases
secuencia
colaboracin
negocio
Adems se realizan las siguientes actividades:
Definicin de entidades de negocio

Realizacin del detalle de negocio mediante artefactos
de creacin de clases (diagrama de clases) y de
interaccin
de
objetos
(diagrama
de
secuencia
colaboracin), ver figura N 84.
90
Tomo I
RESUMEN
Hasta este captulo, usted debe comprender las razones
de optar por
el proceso RUP para la
construccin de
software en estos das, ya debemos estar familiarizados con
todos los elementos que implica
el RUP y listos para
adentrarnos en el maravillo y siempre sorprendente mundo de
la construccin de software.
Los siguientes conceptos deben ser conocidos al 100% para
continuar con el siguiente captulo:
Estructura del RUP

Fase y Etapas del RUP
Trabajadores roles
Actividades
Entorno de trabajo para el RUP
Hora de comenzar con la construccin de un sistema de

informacin en base a los requerimientos del principal
involucrado del proyecto El cliente.
A TRABAJAR!
91
Tomo I
CAPITULO IV
MODELO DE NEGOCIO BASADO EN EL RUP
4.1.
INTRODUCCIN
Ya estamos preparados para dar inicio

construccin de software basado en RUP.
al
proceso
de
Iniciamos como es de suponer a conocer la organizacin

problema, utilizando para esta tan importante
labor
la
primera etapa del RUP, Lo conoces?, si la respuesta es
negativa recomiendo revisar el captulo 3, donde se estudio
el corazn del proceso RUP.
Para las personas que si
prestaron atencin a los
captulos anteriores, es tiempo de poner manos a la obra,
pero,
En base a
que Caso?, el proceso de construccin
estar centrado en el caso compaa de taxis TAXI SEGURO, a
detallarse en el captulo 4.2.
Sin ms prembulos comenzamos
con la etapa MODELO DE
NEGOCIO, esta etapa implica 2 sub etapas:
MODELO DE CASOS DE USO DE NEGOCIO Y

MODELO DE OBJETOS DE NEGOCIO
Utilizaremos el case de Modelamiento Rational Rose, 2003,

para la presente edicin del libro. Con respecto a la
versin anterior del Rational Rose (2002), la ltima versin
presenta cambios significativos, en el ambiente de NEGOCIO.
Dedicaremos el tiempo necesario para detallar cules son
aquellos elementos notacionales que fueron modificados
92
Tomo I
cules
son
las
novedades,
como
siempre
modelamiento Rational Rose SORPRENDE!
el
case
de
4.2. CASO PRCTICO COMPAA DE TAXI TAXI SEGURO

La compaa de taxis TAXI SEGURO atiende a una gran
rea metropolitana y emplea aproximadamente 500 taxis y 1000
conductores.
El
Departamento
de
Contabilidad
report
recientemente que la cobertura de seguros para TAXI SEGURO
est aumentando a razn de 45 por ciento ms rpido en
comparacin con compaas de taxis similares en toda la
nacin. Adicionalmente, los ingresos se han quedado atrs en
un 22 por ciento con respecto a los pronsticos de la
compaa como resultado de menores tarifas de los taxis. El
presidente de TAXI SEGURO cree que parte de este desempeo
poco brillante se debe a una poltica poco agresiva en la
evaluacin del desempeo de los conductores.
En consecuencia, el presidente ha solicitado que se disee
un sistema de informacin que evale aquellos aspectos del
desempeo del conductor que estn relacionados ms de cerca
con las primas de seguros y las solicitudes del servicio de
taxis.
Usted, como analista programador de sistemas de TAXI
SEGURO, cuenta con las siguientes estadsticas: Las multas
de trnsito han alcanzado el promedio de casi 2800 anualmente
durante los tres ltimos aos. Los taxis se ven involucrados
en un promedio de casi 57 accidentes a la semana, 45 de los
cuales son considerados como golpes menores y 12 de los
cuales implican alguna demanda por lesiones personales.
El personal de servicio a clientes maneja entre 25 y 50
quejas de clientes por tiempos de espera largos, lenguaje
abusivo, servicio eficiente, etc., de forma diaria. Cada
queja reportada, accidente y multa de trfico se registra por
da, conductor, nmero de taxi y hora del da
93
Tomo I
4.3. CONCEPTO DEL MODELO DE NEGOCIO

El modelamiento de negocio basado en el RUP, permite
realizar un estudio exhaustivo de la organizacin en trminos
de Procesos de Negocio.
Gracias al modelamiento de negocio, podemos
empezar
el
desarrollo del Sistema de Informacin con informacin certera
y de primera mano, pudiendo lograr as la construccin de un
Sistema de Informacin de Calidad.
El modelamiento
organizacin, aun
Informacin.
de negocio, puede existir en cualquier

cuando NO cuente con un Sistema de
El resultado del modelamiento de negocio, es

para el Modelo de Desarrollo de Software .
Modelo
de
Casos de Uso
Las salidas del Modelamiento de Negocio

sern las entradas del Modelo de
desarrollo de Sw., asegurando as el
conocimiento
del
Negocio
como
requisito indispensable para el logro de
un software de Calidad
Modelo de
Objetos de
Negocio
de Negocio
Anlisis
de
Requerim
ientos
Anlisis
&
Diseo
la ENTRADA
Impleme
ntacin
Pruebas
Puesta
en
Marcha
Figura 85, Ciclo de desarrollo de software basado en el RUP.
4.4.
PROPSITOS DEL MODELO DE NEGOCIO

Entender los problemas actuales de la organizacin.
Asegurar que clientes, usuarios, equipo de desarrollo y
otros involucrados tengan igual entendimiento de la
organizacin.
Un modelo de negocio provee una vista esttica de la
estructura de la organizacin y una vista dinmica
dentro de los procesos de la organizacin.
94
Tomo I
4.5. ELEMENTOS
DE NEGOCIO SEGN EL RUP
4.5.1. GLOSARIO DE NEGOCIO

Es de vital importancia acordar la
terminologa de
negocio comn desde la definicin del proyecto, para lograr
estndares y agilidad en la comunicacin.
Ejemplo:
Para que un empleado obtenga los tiles de oficina,
mensualmente, tiene que presentar el documento PECOSA
4.5.2.
PARTES DEL GLOSARIO DE NEGOCIO
No solo los documentos son parte de glosario, algunos

procesos
segn
el
grado
de
relevancia
tambin
son
considerados.
El RUP propone la siguiente estructura de descripcin del
proceso.
Introduccin
Propsito
Alcance
Referencias
Resumen
Definiciones
4.5.3.
REGLA DEL NEGOCIO
Polticas condiciones a
ser satisfechas por el negocio.
No se realizar ningn pago sin documento de sustento

No se admite como empleado a una persona cuya documentacin
sea incompleta
95
Tomo I
Los pagos a
proveedores se realiza
mediante cheques
Figura 86, Notacin UML para la Regla de Negocio.
4.5.4.
PARTES DEL DOCUMENTO REGLAS DEL NEGOCIO
Introduccin.
Propsito.
Alcance
Referencias
Resumen
Reglas del negocio.
4.5.5.
META
Es el requisito a ser satisfecho por el negocio, detalla

el valor deseado de una medida
especfica en el futuro,
utilizado para planear y administrar las actividades del
negocio.
Ejemplo:
Eliminar las
tardanzas
e
inasistencias a
diciembre del
ao 2005.
Figura 87, Notacin UML para la Meta.
4.5.6.
UNIDAD ORGANIZACIONAL
En esencia, es similar al paquete, sirve para organizar

los
artefactos
que
permitan
explicar
los
procesos
96
Tomo I
empresariales
que se analizan,
casos de uso de negocio.
en trminos de actores y
Ejemplo: Sirve para organizar los modelos de casos de uso

de negocio referido a un proceso de nivel macro como:
Ventas, Compras, Control de Personal, etc.
En el case Rational
Rose 2003
En el case Rational
Rose 2002
Recursos Humanos
Figura 88, Notacin UML para una Unidad Organizacional.

4.5.7.
CASO DE USO DE NEGOCIO
Representa a un proceso empresarial,

aquel conjunto de
actividades continuas, necesarias para la existencia de la
organizacin. Los casos de uso de negocio empiezan su
definicin en verbo.
Ejemplo: Generar Pedido, Generar Orden de Compra,
Generar Factura, Generar Boleta, Registrar Personas, etc.,
ver figura N 89.
En el case Rational
Rose 2003
Registrar
Cliente
En el case Rational
Rose 2002
Figura 89, Notacin UML del Caso de uso de Negocio.
4.5.8.
ACTOR INTERNO DE NEGOCIO (WORKER)
Conocido
tambin
como
actor
interno
de
negocio,
representa a una persona un grupo de personas que tienen
97
Tomo I
relacin directa con el proceso empresarial, su definicin

depende al caso de uso de negocio que se este analizando.
Ejemplo: Cajero, considerando el proceso Generar Factura
En el case Rational
Rose 2003
En el case Rational
Rose 2002
Conductor
Figura 90, Notacin UML de un Actor Interno de Negocio.
4.5.9.
ACTOR
EXTERNO DE NEGOCIO
Representa a una persona un grupo de personas que tenga

relacin indirecta con el proceso empresarial caso de uso
de negocio.
La
definicin del actor externo de negocio depende del
caso de uso de negocio que se est analizando. Ejemplo
Proveedor, si consideramos el proceso Solicitar/Registrar
Proforma.
En el case Rational
Rose 2003
En el case Rational
Rose 2002
Proveedor
Figura 91, Notacin UML de un Actor Externo de Negocio.
4.5.10
ENTIDAD DE NEGOCIO
Representa a un documento cualquier elemento de

informacin
que es usado manipulado por
un trabajador
interno de negocio.
98
Tomo I
Por ejemplo: En el caso de uso de negocio Registrar

Instructor, registramos los datos del instructor en algn
archivo, file, folder base de datos, cada uno de los esos
elementos donde se
almacenan la informacin del nuevo
conductor se denomina entidad de negocio.
En el case Rational
Rose 2003
En el case Rational
Rose 2002
EN_Conductor
Figura 92, Notacin UML de una Entidad de Negocio.
4.5.11.
REALIZACIN DEL CASO DE USO DE NEGOCIO
Sirve como repositorio de todos los artefactos, que tienen

como objetivo explicar el funcionamiento al detalle del
proceso empresarial que se analiza incluyendo la explicacin
de los documentos que se utilizan generan.
Ejemplo: Realizacin del caso de uso Registrar Conductor.
En el case Rational
Rose 2003
Figura 93,
negocio.
En el case Rational
Rose 2002
Realizacin:
Registrar Conductor
Notacin
UML,
del
99
caso
de
uso
realizacin
de
Tomo I
4.5.12.
RECURSO
Este elemento representa al recurso de la organizacin,

los recursos y roles actan de manera conjunta para
realizacin del sistema de negocio.
Recurso
Figura 94, Notacin UML, del elemento Recurso.
4.5.13.
MODELO DE CASOS DE USO DE NEGOCIO
Este elemento
Negocio.
representa
la
Modelo
de
Casos
uso
Modelo de Casos de Uso de

Negocio _ Compaa de taxi
Figura 95, Notacin UML
Modelo de Casos de Uso de Negocio.
100
de
Tomo I
4.5.14.
DOMINIO DEL NEGOCIO
Este elemento representa al campo de accin , giro de la

organizacin.
Recurso
Enseanza Universitaria
Figura 96, Notacin UML Dominio del Negocio.
4.5.15
MODELO DE ANALISIS DE NEGOCIO
Este elemento representa a la realizacin del caso de uso

de negocio, a travs de artefactos del UML, como diagramas de
clases, secuencia y colaboracin, detallando la funcionalidad
del proceso que se analiza.
Modelo de
Anlisis de Negocio
Modelo de Anlisis de Negocio.
101
Tomo I
4.5.16
TRABAJADOR FISICO
Este elemento representa a una

personas, que laboran dentro de la
puestos claves para la organizacin.
persona grupo de
organizacin ocupando
Trabajador Fsico
4.5.17.
del Trabajador Fsico.
RECURSOS COLABORATIVOS
Este
elemento
representa
al
grupo
de
recursos
empresariales, cuya iteracin relacin es necesaria para
el xito de un determinado proceso empresarial.
Generar Planilla mensual
Figura 99 Notacin UML del Recurso Colaborativo.
4.5.18.
SISTEMA DE NEGOCIO
Este
elemento
representa
a
unidades
empresariales
individuales, este encapsula un conjunto de roles y recursos,
para el cumplimiento de un propsito en particular, adems
define un conjunto de responsabilidades mediante los cuales,
los propsitos pueden ser alcanzados.
102
Tomo I
Proceso de revisin de automviles anual
Figura 100, Notacin UML del Sistema de Negocio.
4.5.19.
COMPONENTE DE NEGOCIO
Este elemento representa a un elemento de negocio con

cdigo correspondiente a cualquier sistema parte de la
organizacin, desde el inicio del estudio empresarial para
la mejora en trminos de procesos, implementacin de un
nuevo sistema de informacin la mejora de alguno
existente.
Sistema de
Caja.class
Figura 101, Notacin UML de un Componente de Negocio.
103
Tomo I
4.5.20.
LOCALIZACIN DEL NEGOCIO
Este elemento representa a la ubicacin geogrfica, la ms

estratgica para efectos de mercadeo de la organizacin.
Oficina Central, park Avenue 135,

Miami-Florida
Figura 102,
negocio.
4.5.21.
Notacin
UML
de
la
localizacin
fsica
del
DISEADOR DE NEGOCIO
Este elemento es responsable de detallar los eventos

comerciales, usndolos para descomponer espacio y tiempo
dentro del proceso empresarial que se analiza.
Especialista en transporte
pblico con taxis
Figura 103, Notacin UML del Diseador de Negocio.
4.5.22.
EVENTO DE NEGOCIO
Representa al conjunto de sucesos, acciones empresariales

que repercuten directamente al proceso que se analiza.
104
Tomo I
Revisin Mecnica obligatoria

definido por la Municipalidad
Figura 104, Notacin UML de un Evento de Negocio.
4.5.23. DOCUMENTO DE NEGOCIO

Representa al documento formal, utilizado para garantizar
la funcionalidad del un proceso en particular con referencia
a organizaciones supervisoras del buen funcionamiento de la
misma.
Ejemplo el
documento formal Contrato
entidad supervisora Ministerio de Trabajo.
de
Trabajo,
Contrato de Trabajo
del Conductor
Figura 105, Notacin UML del documento de negocio.
4.6
DETERMINACIN DE LA SITUACIN ACTUAL DE LA ORGANIZACIN
Elaborar un listado de trminos y

comnmente, en un Glosario de Trminos.
definiciones usados
Consiste en desarrollar un entendimiento preliminar de

los objetivos de la empresa, los cuales son determinados por
los stakeholders y responsables del negocio.
105
Tomo I
Identificar
las
reglas
del
negocio,
para
luego
plasmarlos en el documento de Reglas del Negocio. Involucrar
a las personas con ms experiencia y conocimiento en la
organizacin de la siguiente manera:
Convertirlos en miembros del equipo de modelado de

negocio.
Entrevistarlos para conocer sus ideas y opiniones
basadas en sus experiencias.
Hacer que revisen nuestros avances.
4.7. MODELO DE CASOS DE USO DE NEGOCIO

4.7.1.
CONCEPTO
Este modelo, muestra la relacin existente entre un Caso

de Uso de Negocio con los diferentes actores de negocio, se
realiza en el entorno de trabajo del diagrama de casos de
uso.
7.4.2.
TIPOS DE RELACIONES EN EL MODELO DE CASOS DE

USO DE NEGOCIO.
En el ambiente de casos de uso de

los siguientes tipos:
4.7.2.1.
negocio identificamos
RELACION DEL TIPO ASOCIACION UNIDIRECCIONAL
En el modelo de caso de uso de negocio, esta relacin

indica participacin.
4.7.2.2.
RELACION DEL TIPO HERENCIA
Este tipo de relacin indica que las clases que

participan en el modelo de casos de uso de negocio pueden
utilizar la caracterstica de generalizacin herencia.
4.7.3.
TIPOS DE ESTERIOTIPOS EN LAS RELACIONES DE

MODELOS DE CASOS DE USO DEL NEGOCIO
En el modelo de casos de uso de negocio podemos

identificar a los siguientes estereotipos:
106
Tomo I
4.7.3.1.
<<REALIZE>>
El estereotipo <<realize>>, brinda el comportamiento a

la relacin existente entre un caso de uso ya sea de negocio
sistema con su respectivo caso de uso de realizacin.
4.7.3.2.
<<IMPORT>>
El estereotipo <<import>>, brinda el comportamiento a la

relacin existente entre los siguientes artefactos:
Modelo de casos de uso de negocio y

Modelo de anlisis
4.7.3.3.
<<SUPPORT>>
El estereotipo <<support>>, brinda el comportamiento a

la relacin existente entre artefactos de negocio indicando
apoyo soporte de accin.
4.7.4. DESARROLLANDO EL MODELO DE CASOS DE USO DE

NEGOCIO DEL CASO TAXI SEGURO
4.7.4.1.
AGREGAR ELEMENTOS DE NEGOCIO A LA CAJA DE

HERRAMIENTAS DEL CASE RATIONAL ROSE
Hacer click derecho en el Tool Box, seleccionar la
opcin Customize.
En la ventana Personalizar la barra de herramientas
agregar los elementos necesarios.
Figura 106, Agregando elementos a la caja de herramientas del

case Rational Rose 2003.
107
Tomo I
4.7.4.2.
DEFINICION DE LAS METAS
En el paquete Bussiness Use Case, cargado por defecto

al hacer clic en la plantilla Rational Unified Process (ver
figura N 82, de la Vista de Casos de Uso del Case Rational
Rose, definir los objetivos de negocio, puede crearse dentro
de un paquete.
Evitar personal
Indocumentado
Evitar faltas e
inasistencias
Disminuir los ndices

de accidentes
No exceder en las
primas de seguro
Figura 107, Algunos objetivos a cumplir en el caso Compaa

de Taxis Taxi Seguro.
4.7.4.3.
DEFINICION DE LAS UNIDADES ORGANIZACIONALES
Para el presente caso

identificamos
las
siguientes unidades
organizacionales, para
ms detalle ver la
figura n 108.
Figura 108, Definicin de las Unidades Organizacionales con

respecto al caso Compaa de Taxis Taxi Seguro.
108
Tomo I
4.7.4.4. DOCUMENTACIN DE LAS UNIDADES

ORGANIZACIONALES
Figura 109, Documentacin

Mantenimiento.
4.7.4.5.
de
DEFINICIN DE
la
unidad
organizacional
LOS ACTORES DE NEGOCIO
Figura 110, Creacin de los actores

compaa de taxis Taxi Seguro.
de
negocio
del
caso
En el paquete Business Use-Case Model, crear un

diagrama
de
casos
de
uso
denominado
Actores
de
Negocio_CompaaDeTaxi; en el evento doble clic al diagrama
de casos de uso creado, aperturamos el entorno de trabajo
correspondiente, ahora si podemos comenzar con la
creacin
de los actores internos y externos de negocio.
109
Tomo I
La idea es tener un repositorio de creacin para

elementos similares, logrando su fcil ubicacin. En el
anlisis de la
empresa ABC por ejemplo, se pueden
encontrar ms de 50 elementos, la idea es encontrarlos en el
ambiente preestablecido.
4.7.4.6.
DESCRIPCION
DE LOS
Figura 111, Documentacin del

Responsable de Mantenimiento.
ACTORES DE NEGOCIO
actor
interno
de
negocio
El taln de Aquiles de la mayora de los desarrolladores de software es por la poca

importancia dada al proceso de documentacin en la construccin del software, se
preocupan de la documentacin slo cuando este, YA es un problema, la idea es
evitar que
el riesgo se DEFINICION
convierta en problema!
4.7.4.7.
DE LOS CASOS DE USO DE NEGOCIO
Figura 112, Creacin de los casos de uso de negocio del caso

compaa de taxis Taxi Seguro.
110
Tomo I
4.7.4.7.
DESCRIPCION DE LOS CASOS DE USO DE NEGOCIO
Figura 113, Documentacin del caso de uso de negocio Generar

cuenta del da.
4.7.4.8. MODELO DE CASOS DE USO DE NEGOCIO

No olvidemos que el
muestra la participacin
de negocio con un proceso
crea?, no desespere que a
Modelo de Casos de Uso de Negocio,

de los actores internos y externos
de negocio en particular. Dnde se
continuacin lo menciono.
El modelo de casos de uso de negocio, se

crea en el entorno de trabajo de un
diagrama de casos de uso, los cuales
pueden ser agregados en cada unidad
organizacional al hacer click derecho,
new , Use Case Diagram.
Figura 114, Creando un diagrama de casos de uso, para los
Modelos de Casos de Uso de Negocio.
111
Tomo I
Ahora si podemos crear el tan esperado Modelo de Casos

de Uso de Negocio para el proceso REGISTRAR CONDUCTOR.
Figura 115, Modelo de Casos de Uso de Negocio Registrar

conductor.
Menciono otro ejemplo para mayor ilustracin; pero slo

dos?, NO se preocupe, el proceso ntegro, lo detallo en el
CD, que acompaa a la presente. REVISELO!.
112
Tomo I
Figura 116, Modelo de Casos de Uso de

descuento por faltas e inasistencias.
Negocio
Procesar
4.8. MODELO DE OBJETOS DE NEGOCIO
4.8.1.
CONCEPTO
Este modelo, muestra el detalle del caso de uso de negocio

que se est analizando, como se realiza o desarrolla el caso
de uso en mencin, para tal cometido el RUP, indica el uso de
los siguientes artefactos propios del UML:
Diagrama
Diagrama
Diagrama
Diagrama
de
de
de
de
4.8.2.
Casos de Uso, para la realizacin

Clases
Secuencia
Colaboracin
TIPOS DE RELACIONES EN EL MODELO DE

OBJETOS DE NEGOCIO
4.8.2.1. ASOCIACION BIDIRECCIONAL
Este tipo de asociacin

Reglas del negocio.
113
contiene
las
denominadas
Tomo I
4.8.2.2.
Este tipo de
secuencia, permite
objetos.
OBJECT LINK
relacin
presente en el diagrama de
la definicin de un mensaje entre dos
4.8.2.3.
OBJECT LINK TO SELF
Muestra la ejecucin
de un mensaje desde
objeto, presente slo en diagramas de secuencia.
4.8.2.4.
el
mismo
OBJECT MESSAGE
Este tipo de relacin

presente en el diagrama de
colaboracin, permite la definicin del mensaje entre dos
objetos.
4.8.2.5.
OBJECT MESSAGE TO SELF
Permite la definicin de un mensaje

entre el
objeto, presente slo en diagramas de colaboracin.
114
mismo
Tomo I
4.8.3.
DIAGRAMA DE DEPENDENCIAS ENTRE EL MODELO DE

CASOS DE USO DE NEGOCIO Y EL MODELO DE
ANALISIS O MODELO DE OBJETOS DE NEGOCIO
La idea de este diagrama es demostrar la dependencia

entre del Modelo de Anlisis Modelo de objetos de negocio
con respecto al Modelo de Casos de Uso de Negocio.
Figura 117, Dependencia del Modelo de Anlisis con respecto

al Modelo de Casos de Uso, referido al caso Compaa de taxi
Taxi Seguro.
115
Tomo I
4.8.4.
PROCESO DE REALIZACION DEL CASO DE USO DE

NEGOCIO
El caso de uso
realizacin de
negocio, permite
explicar
al
detalle como se
realiza
un
determinado
caso de uso de
negocio,
utilizando
artefactos como
diagrama
de
clases, secuencia
y colaboracin.
REALIZE
Figura 118, Diagrama de casos de uso,

realizacin del proceso Registrar Conductor.
mostrando
la
El comportamiento de la relacin est dado por el

estereotipo <<realize>>, se puede activar haciendo doble
click en la relacin y seleccionado
la opcin deseada.
Podemos crear un Sistema de

Negocio, es un paquete que ayuda
a organizar los artefactos para la
realizacin
de
un
proceso
empresarial. Para nuestro caso se
denomina Registrar Conductor,
contiene al diagrama de casos de
uso, contenedor del modelo de
realizacin, al caso de uso
Realizacin: Registrar Conductor
y sus diagramas correspondientes.
Figura 119, Distribucin del browser del case Rational Rose,

en el ambiente de Modelo de Objetos de Negocio.
116
Tomo I
4.8.4.1. DIAGRAMA DE CLASES
Figura 120, Diagrama de Clases

Conductor, con respecto al caso
Seguro.
del proceso Registrar

Compaa de taxi Taxi
No olvidemos que el Diagrama de Clases, es una

estructura esttica, muestra las clases
y sus relaciones.
En
el negocio utilizamos la ya descrita Entidad de
Negocio, el cual representa a cualquier documento, ficha,
archivo, etc.; creado, manipulado por un trabajador interno
de negocio.
Como cualquier elemento
repositorio, si se necesita
realizacin de otro proceso,
facilidad.
deber ser contenido en un

la misma entidad para
la
puede ser ubicado con mucha
117
Tomo I
4.8.4.1.1. DEFINIENDO UN REPOSITORIO PARA ENTIDADES

DE NEGOCIO.
Entidad de Negocio
Figura 121,
negocio.
Creando
4.8.4.2.
un
repositorio
para
las entidades de
DIAGRAMA DE COLABORACIN
Sabemos que el diagrama de colaboracin es del tipo

dinmico e interactivo, muestra
como cada uno de los
objetos, se comunican mediante una secuencia de mensajes para
explicar el detalle de un proceso en particular. No olviden
que la distribucin es con respecto al espacio.
Figura 122, Diagrama Colaboracin para

proceso Registrar Conductor.
118
la realizacin del
Tomo I
4.8.4.3.
DIAGRAMA DE SECUENCIA
Este diagrama es equivalente al diagrama de secuencia,

la diferencia radica en la distribucin,
el diagrama de
secuencia presenta la distribucin con respecto al tiempo.
Figura 123, Diagrama Secuencia

proceso Registrar Conductor.
119
para
la
realizacin
del
Tomo I
4.8.4.4.
DIAGRAMA DE ACTIVIDADES
Es necesario considerar los diagramas de actividades en

el estudio de la organizacin para resolver los FACTORES
DE DESICIN, los cuales No son considerados por los
artefactos de negocio ya que se asume la afirmacin.
Figura 124, Creando el Diagrama de Actividades Registrar

Conductor.
En el paquete Business Object Model crear el paquete
Diagrama de Actividades, el cual ser repositorio de todos
los diagramas de actividades dirigido a negocio, para el caso
que desarrollamos, se denomina: Registrar Conductor.
120
Tomo I
Jefe de RR-HH
Asistente de RR-HH
Postulante de Conductor
Figura 125, Creando el Diagrama de Actividades Registrar

Conductor.
121

Libro Rup Uml RMM Tomoi

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Libro Rup Uml RMM Tomoi

Cargado por

Copyright:

Formatos disponibles

Construccin de Software O.O.

con el Proceso Unificado y UML, un punto de vista prctico

METODOLOGA ORIENTADO A OBJETOS

Despus de muchos aos de evolucin en la construccin

Las caractersticas de la Metodologa Orientada a

1.2. METODOLOGIA ORIENTADO A OBJETOS

Permite el desarrollo rpido de software al utilizar la

1.3. BASE CONCEPTUAL DE LA METODOLOGIA ORIENTADO A OBJETOS

Es un ente real conceptual que posee caractersticas

IDENTIDAD + COMPORTAMIENTO + ESTADO

Figura 01, Ejemplos de objetos referidos a la clase Persona.

Es una abstraccin y no refencia a ningn objeto en

Figura 02, Ejemplos de Clases.

1.4. CARACTERISTICAS TERICAS DE LA METODOLOGA ORIENTADO A

Propiedad que permite a la clase o subClase tener acceso

Producida gracias a la caracterstica de herencia de la

La ventaja principal que aporta es la

Son bloques de construccin de aplicaciones. Los

Si se acepta de forma universal el modelo de objetos

El modelo de objetos formaliza la estructura y el

del modelo de objetos anlisis orientados

VENTAJAS DEL ANALISIS ORIENTADOS A OBJETOS EN

La base de datos est completamente libre de nulos.

La base de datos est libre de redundancia.

La normalizacin de la base de datos es implcita.

La base de datos est preparada para cambios futuros.

Las clases son componentes

El modelamiento orientado a objetos permite:

o La generacin de cdigo para la programacin, y

El modelo de objetos conduce directamente hacia

Los objetos se comunican entre si mediante mensajes.

Idea original del Magster Amancio Guzmn Rodrguez

Cuando un objeto no esta capacitado para realizar una

Tambin conocido como operacin

Por ejemplo, para el atributo nombre, podemos considerar

Representa el sistema software desde una perspectiva

LENGUAJE DE MODELAMIENTO UNIFICADO

As como los arquitectos utilizan los planos para

La construccin de software es un arte; como toda expresin

El UML, es una tcnica de modelado, NO una metodologa el

los prximos aos, debido a las

Fue creado por expertos en metodologa,

2.3. ANTECEDENTES DEL UML

Creadores de Lenguaje de Modelamiento Unificado.

Figura 04, Aportes significativos de los mtodos originales

Aceptacin por la OMG

Socios del UML

Mtodo Unificado 0.8

1995 OOPSLA 950

Mtodo Unificado 0.8

Figura 05, Evolucin del UML desde el advenimiento del Mtodo

2.4. UML AL DETALLE

Podemos dividir al UML en cuatro partes:

Muestran los diferentes aspectos del sistema que son

Consideramos las siguientes vistas:

Las vistas anteriores, son trabajados en el browser del

Figura 06, Vista del UML, desde 2 puntos de vista.

Son los grficos que describen el

Los conceptos usados son elementos del modelo que

Son smbolos genricos para informacin adicional sobre un

2.5. VISTAS DEL UML

Los Diagramas de estructura esttica de UML se van a

Vamos a recordar los diferentes modelos que sirven para