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 Ing. Rosa Menndez Mueras 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.
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 a
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.
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
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. los efectos de
1.4.4.
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.
La ventaja principal que aporta es la aplicaciones eficientes y de gran fiabilidad.
generacin
de
1.4.6.1.
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.
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 del modelo de objetos anlisis orientados construccin de la base de datos es evitar nulos y redundancia logrando adems la los datos en ella.
1.4.8
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 reutilizables.
El modelamiento orientado a objetos permite: 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).
la
1.4.9.
MENSAJE:
Los objetos se comunican entre si mediante mensajes.

1
Idea original del Magster Amancio Guzmn Rodrguez
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 de a
Tambin conocido como operacin en la etapa anlisis. Son las diversas acciones (comportamientos) realizar con las caractersticas de la clase.
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.
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.
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
Grady Booch
Ivar Jacobson
James Rumbaugh
Figura 03,
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
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
Aceptacin por la OMG Permiso final a la OMG Permiso inicial a la OMG
UML 1.1
Socios del UML
1996
Mtodo Unificado 0.8
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
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.
Logical View
End-user Functionality
Implementation View Use Case View

Programmers Software management
Process View
Performance Scalability Throughput
Deployment View System topology Delivery, installation Communication System engineering
Figura 06, Vista del UML, desde 2 puntos de vista.
2.4.2.
DIAGRAMAS contenido en una que se usan para
Son los grficos que describen el vista. UML tiene ocho tipos de diagramas proveer todas las vistas del sistema.
2.4.3.
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
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. DIAGRAMA DE CLASES
2.6.2.
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
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
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
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
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
2.8.2.
ELEMENTOS DEL DIAGRAMA DE CASOS DE USO
Caso de Uso del Sistema
Caso de Uso del Negocio
Herencia
Caso de Uso Realizacin del Sistema
Caso de Uso Realizacin del Sistema
Asociacin Unidireccional
Actor Interno del Negocio
Actor Externo del Negocio
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
2.9.
DIAGRAMA
ACTIVIDADES
2.9.1.
CONCEPTO ejecutados por una el hardware el
Muestra las diversas actividades persona, una organizacin, incluso software.
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
Actividad
Swimlane
Sincronizacin Horizontal y Vertical
Desicion
Transicin de Estado
Transicin Recursiva
Figura 12, Elementos del Diagrama de Actividades.
20
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
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
Fin
Estado
Transicin de Estado
Sincronizacin Horizontal y Vertical
Desicion
Transicin Recursiva Figura 14, Elementos del Diagrama de Estados
Figura 15, Ejemplos del Diagrama de Estados.
22
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
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
Figura 17, Ejemplo
del Diagrama de Secuencia.
2.12.2.
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
2.12.2.2. ELEMENTOS DEL DIAGRAMA DE COLABORACION
Objeto
Objecto Link
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
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
Programa Principal
Cuerpo del Subprograma
Especificacin de la Tarea
Componente
Especificacin del Paquete
Cuerpo de la Tarea Cuerpo del paquete
Figura 20, Elementos del Diagrama de Componentes.
27
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
Figura 22, Ejemplo
del Diagrama del Despliegue.
29
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
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. principales un ao de elementos y prctico y
31
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
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 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 y organizarlos, funcionalidad y captarlas y por negocio. proceso
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
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. cmo
Permite la verificacin de la calidad mediante las siguientes actividades:
del
software,
Crea pruebas para cada escenario (casos de asegurando que todos los requerimientos apropiadamente implementados.
uso), estn
Verifica la calidad del software con respecto a los requerimientos basados en la confiabilidad, funcionalidad, desempeo de la aplicacin y del sistema. Prueba cada iteracin. 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
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 Dirigido por casos de uso Desarrollo basado en componentes
Gestiona requerimientos
Define tcnicas de modelamiento visual
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
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
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
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. progreso es conforme avanzan las
3.5.4.
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
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
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
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
Esta etapa es ideal conceptos, polticas de artefactos.
para definir el glosario creacin y nombramiento
de de
3.7.2.
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
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
3.8. ETAPAS
3.8.1.
DISCIPLINAS CENTRALES MODELO DE NEGOCIO
3.8.1.1.
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
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 a una tabla
Para el desarrollo de la interrogante necesario conocer las siguientes entradas:
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
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
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 CONTROL DE CAMBIOS
3.8.2.1.
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
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 software no solo que el binomio de construccin, se logra el xito
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.
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.
4
48
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
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
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
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 trabajadores:
3.9.1.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 y
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
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 Analista de procesos de negocio
Especificacin suplementaria de negocio
Modelo de objetos de negocio
Figura 55, Artefactos producidos utilizados trabajador Analista de procesos de negocio.
por
el
77
Caso de uso de negocio Diseador de negocio Entidad de negocio Objetivo de negocio Unidad organizacional
Realizacin del caso de uso de negocio
Trabajador interno de negocio
Figura 56, Artefactos producidos trabajador Diseador de Negocio.
utilizados
por
el
3.11.2. ARTEFACTOS DE REQUERIMIENTOS A continuacin detallo todos los artefactos creados utilizados por un trabajador, con respecto a la etapa de ANALISIS DE REQUERIMIENTOS.
Caso de usos
Especificador de casos de uso
Paquete de casos de uso
Figura 57, Artefactos producidos utilizados trabajador Especificador de Casos de Uso.
por
el
78
Glosario
Caractersticas de los requerimientos
Analista de sistemas
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
Modelo de casos de uso de sistema
Especificacin suplementaria
Figura 58, Artefactos producidos trabajador Analista de Sistemas.
utilizados
por
el
Lmite
Prototipos de casos de uso
Diseador de interfaces de usuario
Actor
Prototipos de interfaces de usuario
Figura 59, Artefactos producidos utilizados trabajador Diseador de interfaces de usuario.
por
el
79
3.11.3. ARTEFACTOS DE DISEO A continuacin detallo todos los artefactos creados utilizados por un trabajador, con respecto a la etapa de DISEO.
Modelo anlisis
Seal Protocolo
Arquitecto
Modelo de diseo
Interface
Documento de la arquitectura de software
Evento
Figura 60, Artefactos trabajador Arquitecto.
producidos
utilizados
por
el
Modelo de estados
Paquete de diseo
Diseador
Caso de uso realizacin de diseo
Clase de diseo
Diseo de subsistemas
Modelo de clases y paquetes
Figura 61, Artefactos trabajador Diseador.
producidos
utilizados
por
el
80
Modelo de casos de uso de negocio
Modelo de objetos de negocio
Analista de procesos de negocio
Especificacin suplementaria de negocio
Figura 62, Artefactos producidos utilizados trabajador Analista de Proceso de negocio.
por
el
Estructura Diseador de la estructura
Figura 63, Artefactos producidos trabajador Diseador de la estructura.
utilizados
por
el
Modelo de Clases
Diseador de la base de datos
Figura 64, Artefactos producidos utilizados trabajador Diseador de la Base de Datos.
por
el
81
Modelo de pruebas
Prueba de procedimientos
Diseador de pruebas Modelo del plan de accin Modelo de casos
Figura 65, Artefactos producidos trabajador Diseador de Pruebas.
utilizados
por
el
3.11.4.
ARTEFACTOS DE IMPLEMENTACIN
A continuacin detallo todos los artefactos creados utilizados por un trabajador, con respecto a la etapa de IMPLEMENTACIN.
Arquitecto Modelo de implementacin
Figura 66, Artefactos trabajador Arquitecto.
producidos
utilizados
por
el
Integrador del sistema
Plan de construccin de la integracin
Figura 67, Artefactos producidos trabajador Integrador del Sistema.
utilizados
por
el
82
Diseador de pruebas
Prueba de escrituras
utilizados
por
el
Componente
Implementador
Sub sistema de implementacin
Prueba de sub sistema y componentes
Figura 69, Artefactos producidos trabajador Implementador.
utilizados
por
el
3.11.5. ARTEFACTOS DE DESPLIEGUE A continuacin detallo todos los artefactos creados utilizados por un trabajador, con respecto a la etapa de DESPLIEGUE.
83
Diseador del curso
Plan de entrenamiento
Figura 70, Artefactos producidos trabajador Diseador del Curso.
utilizados
por
el
Implementador
Instalacin de artefactos
Figura 71, Artefactos producidos trabajador Implementador.
utilizados
por
el
Documentador Tcnico
Documento de soporte a usuarios
Notas de realizacin
Figura 72, Artefactos producidos trabajador Documentador Tcnico.
utilizados
por
el
84
Administrador del despliegue
Plan de despliegue
Figura 73, Artefactos producidos trabajador Administrador del Despliegue.
utilizados
por
el
3.11.6. ARTEFACTOS DE ADMINISTRACIN A continuacin detallo todos los artefactos creados utilizados por un trabajador, con respecto a la etapa de 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 Valoracin de estatus Casos de uso de negocio
Figura 74, Artefactos producidos trabajador Gestor del Proyecto.
utilizados
por
el
85
Diseador de pruebas
Plan de pruebas
utilizados
por
el
Ingeniero de procesos
Desarrollo de casos
Desarrollo de valoracin organizativa
Figura 76, Artefactos producidos trabajador Ingeniero de Procesos.
utilizados
por
el
Administrador de la configuracin
Plan de administracin de la configuracin
Figura 77, Artefactos producidos utilizados trabajador Administrador de la Configuracin.
por
el
86
3.11.7. ARTEFACTOS DE ESPECIFICACIN Y PAUTAS A continuacin detallo todos los artefactos creados utilizados por un trabajador, con respecto a la etapa de ESPECIFICACIONES.
Herramientas Integrador del sistema Administrador del sistema
Administrador de herramientas
Figura 78, Artefactos administradores.
producidos
utilizados
por
los
Analista de procesos de negocio
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
Figura 80, Artefactos producidos trabajador Analista de Sistemas.
utilizados
por
el
87
Diseador de interfaces de usuario
Base de interfaces de usuario
Figura 81, Artefactos producidos utilizados 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
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
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
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
CAPITULO IV
MODELO DE NEGOCIO BASADO EN EL RUP
4.1.
INTRODUCCIN al proceso de
Ya estamos preparados para dar inicio construccin de software basado en RUP.
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
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
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 .
la ENTRADA
Modelo de Casos de Uso de Negocio
Modelo de Objetos de Negocio
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
Impleme ntacin Puesta en Marcha
Anlisis de Requerim ientos
Anlisis & Diseo
Pruebas
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
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 ser satisfechas por el negocio.
Polticas condiciones a
No se realizar ningn pago sin documento de sustento No se admite como empleado a una persona cuya documentacin sea incompleta
95
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
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
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.
Registrar Cliente
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
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
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.
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
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_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.
Realizacin: Registrar Conductor
Figura 93, negocio.
Notacin
UML,
del
caso
de
uso
realizacin
de
99
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 representa la Modelo de Casos uso de
Este elemento Negocio.
Modelo de Casos de Uso de Negocio _ Compaa de taxi
Figura 95, Notacin UML
Modelo de Casos de Uso de Negocio.
100
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
4.5.16
TRABAJADOR FISICO persona grupo de organizacin ocupando
Este elemento representa a una personas, que laboran dentro de la puestos claves para la organizacin.
Trabajador Fsico
del Trabajador Fsico.
4.5.17.
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
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
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.
Notacin
UML
de
la
localizacin
fsica
del
4.5.21.
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
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 definiciones usados
Elaborar un listado de trminos y comnmente, en un Glosario de Trminos.
Consiste en desarrollar un entendimiento preliminar de los objetivos de la empresa, los cuales son determinados por los stakeholders y responsables del negocio.
105
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. negocio identificamos
En el ambiente de casos de uso de los siguientes tipos: 4.7.2.1.
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
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
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
4.7.4.4. DOCUMENTACIN DE LAS UNIDADES ORGANIZACIONALES
Figura 109, Documentacin Mantenimiento.
de
la
unidad
organizacional
4.7.4.5.
DEFINICIN DE
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
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 ACTORES DE NEGOCIO
Figura 111, Documentacin del Responsable de Mantenimiento.
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 DE LOS CASOS DE USO DE NEGOCIO 4.7.4.7. convierta en problema!
Figura 112, Creacin de los casos de uso de negocio del caso compaa de taxis Taxi Seguro.
110
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
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
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 Casos de Uso, para la realizacin Clases Secuencia Colaboracin
4.8.2.
TIPOS DE RELACIONES EN EL MODELO DE OBJETOS DE NEGOCIO
4.8.2.1. ASOCIACION BIDIRECCIONAL
Este tipo de asociacin Reglas del negocio.
contiene
las
denominadas
113
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 el mismo
Muestra la ejecucin de un mensaje desde objeto, presente slo en diagramas de secuencia.
4.8.2.4.
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 mismo
Permite la definicin de un mensaje entre el objeto, presente slo en diagramas de colaboracin.
114
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
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
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
4.8.4.1.1. DEFINIENDO UN REPOSITORIO PARA ENTIDADES DE NEGOCIO.
Entidad de Negocio
Figura 121, negocio.
Creando
un
repositorio
para
las entidades de
4.8.4.2.
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.
la realizacin del
118
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.
para
la
realizacin
del
119
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
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

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Libro Rup Uml RMM Tomoi

Încărcat de

Drepturi de autor:

Formate disponibile

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

Rosa Menndez Mueras Tomo I

METODOLOGA ORIENTADO A OBJETOS

1.3. BASE CONCEPTUAL DE LA METODOLOGIA ORIENTADO A OBJETOS 1.3.1. OBJETO

IDENTIDAD + COMPORTAMIENTO + ESTADO

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

Figura 02, Ejemplos de Clases.

1.4. CARACTERISTICAS TERICAS DE LA METODOLOGA ORIENTADO A OBJETOS.

manera de modificarlos language (SQL).

La ventaja principal que aporta es la aplicaciones eficientes y de gran fiabilidad.

VENTAJAS DEL ANALISIS ORIENTADOS A OBJETOS EN LA BASE DE DATOS1

El modelo de objetos conduce directamente hacia programacin en la WEB(accesos remotos de BD).

Los objetos se comunican entre si mediante mensajes.

Idea original del Magster Amancio Guzmn Rodrguez

LENGUAJE DE MODELAMIENTO UNIFICADO

Creadores de Lenguaje de Modelamiento Unificado.

Planificacin de una revisin mayor

Planificacin de una revisin menor

Solicitud a una revisin menor

Aceptacin por la OMG Permiso final a la OMG Permiso inicial a la OMG

Socios del UML

Mtodo Unificado 0.8

1995 OOPSLA 950

Mtodo Unificado 0.8

OMT UML 0.9

Podemos dividir al UML en cuatro partes:

Implementation View Use Case View

Deployment View System topology Delivery, installation Communication System engineering

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

DIAGRAMAS contenido en una que se usan para

2.5. VISTAS DEL UML

2.6. DESCRIPCION DE LOS DIAGRAMAS DEL UML 2.6.1. DIAGRAMA DE CLASES

TIPOS DE RELACIONES ENTRE CLASES

ELEMENTOS DEL DIAGRAMA DE CLASES

Figura 07, Elementos en un diagrama de clases.

Figura 08, Ejemplos de Diagramas de Clase.

2.7. DIAGRAMA DE PAQUETES

Figura 09, Elementos y Diagrama de paquetes.

2.8. DIAGRAMA DE CASOS DE USO

ELEMENTOS DEL DIAGRAMA DE CASOS DE USO

Caso de Uso del Sistema

Caso de Uso del Negocio

Caso de Uso Realizacin del Sistema

Caso de Uso Realizacin del Sistema

Actor Interno del Negocio

Actor Externo del Negocio

Actor del Sistema

Figura 10, Elementos a utilizar en un Diagrama de Casos de Uso.

Figura 11, Ejemplos de

Diagramas de Casos de Uso.

CONCEPTO ejecutados por una el hardware el

Muestra las diversas actividades persona, una organizacin, incluso software.

ELEMENTOS DEL DIAGRAMA DE ACTIVIDADES

Sincronizacin Horizontal y Vertical

Figura 12, Elementos del Diagrama de Actividades.

Figura 13, Ejemplo de Diagrama de Actividades.

2.10.2. ELEMENTOS DEL DIAGRAMA DE ESTADOS

Sincronizacin Horizontal y Vertical

Transicin Recursiva Figura 14, Elementos del Diagrama de Estados

Figura 15, Ejemplos del Diagrama de Estados.

2.11. DIAGRAMA DE OBJETOS 2.11.1. CONCEPTO

2.12.1. DIAGRAMA DE SECUENCIA