Instituto Tecnolgico Superior de Cintalapa

ANLISIS Y MODELADO DE SISTEMAS DE INFORMACIN

UNIDAD 1
EL MODELO DEL PROCESO DEL SOFTWARE TEMA: CUADRO COMPARATIVO: RUP & UML

CATEDRATICO:

Lic. ERNESTO SOLIS RAMIREZ

ALUMNO:

DIEGO ARMANDO PREZ CLEMENTE.

SEMSTRE & GRUPO: 5 E

Mircoles 04 De Septiembre 2013

2|Pgina

MODELO

RUP
Los orgenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken Hartman, uno de los contribuidores claves de RUP colabor con Boehm en la investigacin. En 1995 Rational Software compr una compaa sueca llamada Objectory AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos de uso a los mtodos de desarrollo orientados a objetos. El Rational Unified Process fue el resultado de una convergencia de Rational Approach y Objectory (el proceso de la empresa Objectory AB). El primer resultado de esta fusin fue el Rational Objectory Process, la primera versin de RUP, fue puesta en el mercado en 1998, siendo el arquitecto en jefe Philippe Kruchten. El Proceso Unificado es un proceso de desarrollo de software: conjunto de actividades necesarias para transformar los requisitos del usuario en un sistema software. Trabajadores (quin): Define el comportamiento y responsabilidades (rol) de un individuo, grupo de individuos, sistema automatizado o mquina, que trabajan en conjunto como un equipo. Ellos realizan las actividades y son propietarios de elementos. Actividades (cmo): Es una tarea que tiene un propsito claro, es realizada por un trabajador y manipula

UML
El lenguaje UML comenz a gestarse en octubre de 1994 cuando Rumbaugh se uni a la compaa Rational fundada por Booch (dos reputados investiga-dores en el rea de metodologa del software). El objetivo de ambos era unificar dos mtodos que haban desarrollado: el mtodo Booch y el OMT (Object Mode-lling Tool ). El primer borrador apareci en octubre de 1995. En esa misma poca otro reputado investigador, Jacobson, se uni a Rational y se incluyeron ideas suyas. Estas tres personas son conocidas como los tres amigos. Adems, este lenguaje se abri a la colaboracin de otras empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron a la definicin de la primera versin de UML. UML es ante todo un lenguaje. Un lenguaje proporciona un vocabulario y unas reglas para permitir una comunicacin. En este caso, este lenguaje se centra en la representacin grfica de un sistema. Caso de uso Un caso de uso describe, desde el punto de vista de los actores, un grupo de actividades de un sistema que produce un resultado concreto y tangible. Los casos de uso son descriptores de las interacciones tpicas entre los usuarios de un sistema y ese mismo sistema. Representan el interfaz externo del sistema y
3|Pgina

HISTORIA

CONCEPTO

PRINCIPALES ELEMENTOS

elementos. Artefactos (qu): Productos tangibles del proyecto que son producidos, modificados y usados por las actividades. Pueden ser modelos, elementos dentro del modelo, cdigo fuente y ejecutables. Flujo de actividades (cundo): Secuencia de actividades realizadas por trabajadores y que produce un resultado de valor observable.

especifican qu requisitos de funcionamiento debe tener este (recuerde, nicamente el qu, nunca el cmo). Cuando se trabaja con casos de uso, es importante tener presentes algunas secillas reglas: Cada caso de uso est relacionado como mnimo con un actor Cada caso de uso es un iniciador (es decir, un actor) Cada caso de uso lleva a un resultado relevante (un resultado con valor intrnseco) Los casos de uso pueden tener relaciones con otros casos de uso. Los tres tipos de relaciones ms comunes entre casos de uso son: <<include>> que especifica una situacin en la que un caso de uso tiene lugar dentro de otro caso de uso <<extends>> que especifica que en ciertas situaciones, o en algn punto (llamado punto de extensin) un caso de uso ser extendido por otro. Generalizacin que especifica que un caso de uso hereda las caractersticas del super caso de uso, y puede volver a especificar algunas o todas ellas de una forma muy similar a las herencias entre clases. Actor Un actor es una entidad externa (de fuera del sistema) que interacciona con el sistema participando (y normalmente iniciando) en un caso de uso. Los actores pueden ser gente real (por ejemplo, usuarios del sistema), otros ordenadores o eventos externos.

4|Pgina

Los actores no representan a personas fsicas o a sistemas, sino su rol. Esto significa que cuando una persona interacta con el sistema de diferentes maneras (asumiendo diferentes papeles), estar representado por varios actores. Por ejemplo, una persona que proporciona servicios de atencin telefnica a clientes y realiza pedidos para los clientes estara representada por un actor equipo de soporte y por otro actor representante de ventas. Descripcin de casos de uso Las descripciones de casos de uso son reseas textuales del caso de uso. Normalmente tienen el formato de una nota o un documento relacionado de alguna manera con el caso de uso, y explica los procesos o actividades que tienen lugar en el caso de uso. Diagrama de clases Los diagramas de clases muestran las diferentes clases que componen un sistema y cmo se relacionan unas con otras. Se dice que los diagramas de clases son diagramas estticos porque muestran las clases, junto con sus mtodos y atributos, as como las relaciones estticas entre ellas: qu clases conocen a qu otras clases o qu clases son parte de otras clases, pero no muestran los mtodos mediante los que se invocan entre ellas. Unifica los mejores elementos de metodologas anteriores. Preparado para desarrollar grandes y complejos proyectos. Orientado a Objetos. Utiliza el UML como lenguaje de representacin visual. Su necesidad radica principalmente en el hecho de que es un lenguaje que permite desarrollar un plan bien analizado que pueda ser comprensible tanto como para el cliente como para los o el realizador explicarlo, analizarlo y desarrollarlo.

CARACTERSTICAS

5|Pgina

VENTAJAS

DESVENTAJAS

Es el proceso de desarrollo ms general de los existentes actualmente. Es una forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo (quin hace qu, cundo y cmo). Consume muchos recursos Genera mucho tiempo en el desarrollo del sistema Costoso Requiere experiencia en la identificacin de riesgos.
Cada ciclo constas de cuatro fases: inicio, elaboracin, construccin, y transicin.

UML Se puede usar para diferentes tipos de sistemas UML consolida muchas de las notaciones y conceptos ms usados orientados a objetos. UML es fcilmente entendible. UML no es un mtodo de desarrollo. UML al no ser un mtodo de desarrollo es independiente del ciclo de desarrollo UML no se presta con facilidad al diseo de sistemas distribuidos. El ciclo de vida en trminos concretos es lo que dura cualquier cosa u objeto desde su inicio de elaboracin hasta el final de la misma, pasando por varias etapas intermedias ya que todo producto lleva un proceso de elaboracin, ste proceso puede ser ya sea sencillo o laborioso; pero, todos tienen un mismo objetivo en comn, cumplir exitosamente con el producto final. El diagrama de flujo o diagrama de actividades es la representacin grfica del algoritmo o proceso. Se utiliza en disciplinas como programacin, economa, procesos industriales y psicologa cognitiva. En Lenguaje Unificado de Modelado (UML), un diagrama de actividades representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un diagrama de actividades muestra el flujo de control general. En SysML el diagrama de actividades ha sido extendido para indicar flujos entre pasos que mueven elementos fsicos (e.g., gasolina) o energa (e.g., presin). Los cambios

CICLO DE VIDA

FLUJO DE TRABAJO

Modelo del Negocio: Describe los procesos de negocio, identificando quines participan y las actividades que requieren automatizacin. Requerimiento: Define qu es lo que el sistema debe hacer, para lo cual se identifican las funcionalidades requeridas y las restricciones que se imponen. Anlisis y Diseo: Describe cmo el sistema ser realizado a partir de la funcionalidad prevista y las restricciones impuestas (requerimientos), por lo que indica con precisin lo que se debe programar. Implementacin: Define cmo se organizan las clases y objetos en componentes, cules nodos se utilizarn y la

6|Pgina

FASES

ubicacin en ellos de los componentes y la estructura de capas de la aplicacin. Prueba (Testeo): Busca los defectos a los largo del ciclo de vida. Instalacin o despliegue: Produce relase del producto y realiza actividades (empaque, instalacin, asistencia a usuarios, etc.) para entregar el software a los usuarios finales. Administracin del proyecto: Involucra actividades con las que se busca producir un producto que satisfaga las necesidades de los clientes. Administracin de configuracin y cambios: Describe cmo controlar los elementos producidos por todos los integrantes del equipo de proyecto en cuanto a: utilizacin/actualizacin concurrente de elementos, control de versiones, etc. Ambiente: Contiene actividades que describen los procesos y herramientas que soportarn el equipo de trabajo del proyecto; as como el procedimiento para implementar el proceso en una organizacin. La fase de concepcin o inicio tiene por finalidad definir la visin, los objetivos y el alcance del proyecto, tanto desde el punto de vista funcional como del tcnico, obtenindose como uno de los principales resultados una lista de los casos de uso y una lista de los factores de riesgo del proyecto. El principal esfuerzo est radicado en el Modelamiento del Negocio y el Anlisis de Requerimientos. Es la nica fase que no necesariamente culmina con una versin ejecutable.

adicionales permiten al diagrama soportar mejor flujos de comportamiento y datos continuos. Estos diagramas utilizan smbolos con significados definidos que representan los pasos del algoritmo, y representan el flujo de ejecucin mediante flechas que conectan los puntos de inicio y de fin de proceso.

Anlisis de Requerimientos UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A travs del modelado de casos de uso, los actores externos que tienen inters en el sistema son modelados con la funcionalidad que ellos requieren del sistema (los casos de uso). Los actores y los casos de uso son modelados con relaciones y tienen asociaciones entre ellos o stas son divididas en jerarquas. Los actores y casos de uso son descritos en un diagrama

7|Pgina

La fase de elaboracin tiene como principal finalidad completar el anlisis de los casos de uso y definir la arquitectura del sistema, adems se obtiene una aplicacin ejecutable que responde a los casos de uso que la comprometen. A pesar de que se desarrolla a profundidad una parte del sistema, las decisiones sobre la arquitectura se hacen sobre la base de la comprensin del sistema completo y los requerimientos (funcionales y no funcionales) identificados de acuerdo al alcance definido. La fase de construccin est compuesta por un ciclo de varias iteraciones, en las cuales se van incorporando sucesivamente los casos de uso, de acuerdo a los factores de riesgo del proyecto. Este enfoque permite por ejemplo contar en forma temprana con versiones el sistema que satisfacen los principales casos de uso. Los cambios en los requerimientos no se incorporan hasta el inicio de la prxima iteracin. La fase de transicin se inicia con una versin beta del sistema y culmina con el sistema en fase de produccin.

use-case. Cada use-case es descrito en texto y especifica los requerimientos del cliente: lo que l (o ella) espera del sistema sin considerar la funcionalidad que se implementar. Un anlisis de requerimientos puede ser realizado tambin para procesos de negocios, no solamente para sistemas de software. Anlisis La fase de anlisis abarca las abstracciones primarias (clases y objetos) y mecanismos que estn presentes en el dominio del problema. Las clases que se modelan son identificadas, con sus relaciones y descritas en un diagrama de clases. Las colaboraciones entre las clases para ejecutar los casos de uso tambin se consideran en esta fase a travs de los modelos dinmicos en UML. Es importante notar que slo se consideran clases que estn en el dominio del problema (conceptos del mundo real) y todava no se consideran clases que definen detalles y soluciones en el sistema de software, tales como clases para interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc. Diseo En la fase de diseo, el resultado del anlisis es expandido a una solucin tcnica. Se agregan nuevas clases que proveen de la infraestructura tcnica: interfaces de usuario, manejo de bases de datos para almacenar objetos en una base de datos, comunicaciones con otros sistemas, etc. Las clases de dominio del problema del anlisis son agregadas en esta fase. El diseo resulta en especificaciones detalladas para la fase de programacin.

8|Pgina

DIFERENCIAS

Algunos aspectos que diferencian a RUP de las dems metodologas y lo que lo hace nico son que en RUP, los casos de uso no son slo una herramienta para especificar los requisitos del sistema, sino que tambin guan su diseo, implementacin y prueba. Los casos de uso constituyen un elemento integrador y una gua del trabajo. Adems de utilizar los casos de uso para guiar el proceso; se presta especial atencin al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores durante la

Programacin En esta fase las clases del diseo son convertidas a cdigo en un lenguaje de programacin orientado a objetos. Cuando se crean los modelos de anlisis y diseo en UML, lo ms aconsejable es trasladar mentalmente esos modelos a cdigo. Pruebas Normalmente, un sistema es tratado en pruebas de unidades, pruebas de integracin, pruebas de sistema, pruebas de aceptacin, etc. Las pruebas de unidades se realizan a clases individuales o a un grupo de clases y son tpicamente ejecutadas por el programador. Las pruebas de integracin integran componentes y clases en orden para verificar que se ejecutan como se especific. Las pruebas de sistema ven al sistema como una "caja negra" y validan que el sistema tenga la funcionalidad final que le usuario final espera. Las pruebas de aceptacin conducidas por el cliente verifican que el sistema satisface los requerimientos y son similares a las pruebas de sistema. Ahora bien, UML tiene mayor sentido cuando se est hablando de un anlisis, diseo y programacin bajo el paradigma OO (Orientado a Objetos). Si bien, hay algunos diagramas de UML que no necesariamente son exclusivamente al paradigma OO. Uno puede, si as lo desea, extrapolar el concepto de un diagrama para transmitir una idea fuera del paradigma. Como por ej, el diagrama de actividad que en ocasiones se lo emplea para representar el flujo de informacin y los procesos de un rea o departamento de una empresa.

9|Pgina

construccin y el mantenimiento. Tambin este propone que cada fase se desarrolle en iteraciones.

10 | P g i n a