Repblica Bolivariana de Venezuela Ministerio del Poder Popular de la Defensa Universidad Nacional Experimental de la Fuerza Armada Bolivariana UNEFA-Ncleo-San

Tom Ctedra: Diseo de Sistemas

Proceso Unificado de Software y Diseo Orientado a Objetos.

Profesora: Abg.: Jackeline Hernndez Ctedra: Diseo de Sistemas

Seccin 7N01 Bachilleres:

Villazana Mara Urbez Cristian. Hernndez Mara Higinia Moreno Engelbert

C.I:23.536.219 C.I:24.492.399 C.I: 17.746.165 C.I: 11.773.602

29 De Mayo De 2013

CONTENIDO

INTRODUCCIN.............................................................................................. 3 PROCESO UNIFICADO DE SOFTWARE Y DISEO ORIENTADO A OBJETOS.......4 1.PROCESO UNIFICADO DE SOFTWARE..........................................................5 a)Definicin: .................................................................................................. 5 b)Ventajas y Desventajas............................................................................... 5 c)Caractersticas Generales............................................................................5 d)Fases Y Flujos De Trabajo............................................................................6 a)Definicin:................................................................................................... 8 b)Principios del Proceso Racional Unificado...................................................8 c)Ciclo De Vida............................................................................................. 11 3.DISEO ORIENTADO A OBJETOS................................................................12 a)Definicin:................................................................................................. 12 b)Principios Del Diseo Orientado A Objetos................................................12 CONCLUSIN................................................................................................ 15 BIBLIOGRAFIA............................................................................................... 16

INTRODUCCIN

El proceso unificado de software consiste en emprender un proceso del cual se obtendr como resultado un software que permita al usuario satisfacer sus necesidades y que el mismo pueda manejar el software con facilidad sin complicaciones, este proceso se ejecuta en diferentes etapas como por ejemplo la etapa o fase de inicio que es donde se emprende la idea como tal de fijar negocio, metas, visin o misin del proyecto a ejecutar, luego sigue la fase de elaboracin en la cual se refina la visin y se mejora la idea o misin como tal, luego les siguen otras fases hasta llegar a la fase final de transicin en la cual se le otorga al usuario final en proyecto del software ya terminado. todas estas etapas o fases tienen un fin en comn el cual es darle perfeccionamiento al sistema que se est elaborando para cumplir a cabalidad con la propuesta que se genero en el negocio por parte del cliente o usuario. Existe tambin lo que se denomina como el Proceso Orientado a Objetos el cual tiene una metodologa muy diferente al proceso antes mencionado ya que Es una fase de la metodologa orientada a objetos para el desarrollo de Software. Su uso induce a los programadores a pensar en trminos de objetos, en vez de procedimientos, cuando planifican su cdigo.

PROCESO UNIFICADO DE SOFTWARE Y DISEO ORIENTADO A OBJETOS

1.

PROCESO UNIFICADO DE SOFTWARE a) Definicin:

El Proceso Unificado es un proceso de software genrico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes reas de aplicacin, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaos de proyectos. Provee un enfoque disciplinado en la asignacin de tareas y responsabilidades dentro de una organizacin de desarrollo. Su meta es asegurar la produccin de software de muy alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y presupuesto predecible. b) Ventajas y Desventajas VENTAJAS COMPUESTO POR CUATRO FASES Y OCHO DISCIPLINAS ITERATIVO E INCREMENTAL DIRIGIDO POR CASO DE USO BASADO EN LA ARQUITECTURA IMPLEMENTA LAS MEJORES PACTICAS DE INGENIEIA DE SOFTWARE MODELAMIENTO VISUAL DEL SOFTWARE SE REDUCEN RIESGOS Y SE TIENEN VERSIONES OPERATIVAS DESDE ETAPAS TEMPRANAS COSTE DEL RIESGO A UN SOLO INCREMENTO. REDUCE EL RIESGO DE NO SACAR EL PRODUCTO EN EL CALENDARIO PREVISTO. ACELERA EL RITMO DE DESARROLLO. ADAPTA MEJOR A LAS NECESIDADES DEL CLIENTE. c) Caractersticas Generales Iterativo e Incremental: El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboracin, SOLO EXISTEN PROBLEMAS DE COMUNICACIN ENTRE EL INGENIERO DE SOFTWARE Y EL USUARIO DESVENTAJAS

Construccin y Transicin. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio puede incluir varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que aade o mejora las funcionalidades del sistema en desarrollo. Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clsico o en cascada: Anlisis de requisitos, Diseo, Implementacin y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas vara a lo largo del proyecto.

Diagrama ilustrando como el nfasis relativo en las distintas disciplinas cambia a lo largo del proyecto. Dirigido por los casos de uso: En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteracin tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a travs de las distintas disciplinas: diseo, implementacin, prueba, etc. El proceso dirigido por casos de uso es el rup. Centrado en la arquitectura: El Proceso Unificado asume que no existe un modelo nico que cubra todos los aspectos del sistema. Por dicho motivo existen mltiples modelos y vistas que definen la arquitectura de software de un sistema. La analoga con la construccin es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanera, etc. Enfocado en los riesgos: El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos crticos en una etapa temprana del ciclo de vida. Los resultados de cada iteracin, en especial los de la fase de Elaboracin deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero. d) Fases Y Flujos De Trabajo Fases del Proceso Unificado de Software

 Fase de Inicio: En esta fase corresponde definir el negocio. Es la etapa donde se define la factibilidad del proyecto a realizar, se representa el modelo de negocio, visin y metas del proyecto, se identifican actores, conceptos de dominio y deseos de usuario. Adicionalmente se complementa con la definicin de la arquitectura preliminar, y estimaciones (imprecisas, preliminares) de plazos y costos. Tambin se define la viabilidad del proyecto. Fase de Elaboracin: En la fase de elaboracin se obtiene la visin refinada del proyecto a realizar, la implementacin iterativa del ncleo central de la aplicacin, la resolucin de los riesgos ms altos, la identificacin de nuevos requisitos y nuevos alcances, y estimaciones ms ajustadas. A esta altura existe la posibilidad de detener el proyecto por complejidad tcnica. Fase de Construccin: La fase de construccin es la implementacin iterativa del resto de los requisitos de menor riesgo y elementos ms sencillos. Es la evolucin hasta convertirse en un producto listo, incluyendo todos los requisitos (100%), para entregarse al Cliente. Al final de esta fase el sistema contiene todos los casos de uso que el cliente y la direccin del proyecto han acordado. La mayora de los casos de uso que no se desarrollaron en la fase anterior se desarrollan en iteraciones, en grupos de requisitos o casos de uso durante esta fase. Fase de Transicin: Es el periodo donde el producto es completamente entregado al cliente para ser testeado y desplegado (instalado). Flujos de Trabajo del Proceso Unificado de Software Requisitos: Flujo de trabajo fundamental cuyo propsito esencial es orientado al desarrollado hacia el sistema correcto. Esto se lleva a cabo mediante la descripcin de los requisitos del sistema de forma tal que se pueda llegar a un acuerdo entre el cliente (incluyendo los usuarios) y los desarrolladores del sistema, acerca de lo que el sistema debe hacer y lo que no. Anlisis: Flujos de trabajo fundamental cuyo propsito principal es analizar los requisitos descritos en la captura de requisitos, mediante su refinamiento y estructuracin. El objetivo de esto es (1) lograr una comprensin mas precisa de los requisitos, y (2) obtener una descripcin de los requisitos que sea fcil de mantener y que nos ayude a dar estructura al sistema en su conjunto incluyendo su arquitectura. Diseo: Flujo de trabajo fundamental cuyo propsito principal es la de formular modelos que se centran en los requisitos no funcionales y el dominio de la solucin y que prepara para la implementacin y pruebas del sistema. Implementacin: Flujo de trabajo fundamental cuyo propsito esencial es implementar el sistema en trminos de componentes, es decir cdigo fuente guiones, ficheros binarios, ejecutables, et. Prueba: Flujo de trabajo fundamental cuyo propsito esencial es comprobar el resultado de la implementacin mediante las pruebas de cada construccin,

incluyendo tanto construcciones internas como intermedias, as como las versiones finales del sistema que van a ser entregadas a terceras personas.

2.

PROCESO RACIONAL UNIFICADO a) Definicin:

El Proceso Racional Unificado es un proceso de software genrico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes reas de aplicacin, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaos de proyectos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin. b) Principios del Proceso Racional Unificado Abstraccin: denota las caractersticas esenciales de un objeto que lo distingue de otras clases de objetos proveyndolo de fronteras conceptuales de definicin muy claras y dentro de una perspectiva funcional. La abstraccin es el paso de un objeto del mundo real a un objeto abstracto o a la informacin constructiva de una clase u objeto que sirva como componente de la solucin. La Abstraccin es una descripcin especial simplificada de un sistema que hace nfasis en ciertos rasgos y suprime otros. La buena abstraccin es aquella que logra hacer nfasis en los detalles significativos o relevantes de la solucin y discrimina cualquier otra caracterstica. Con esto se consigue un mapeo de los objetos del mundo real a los objetos del sistema. En la figura, la perspectiva de ver a un gato es muy distinta entre una abuela amorosa y un mdico veterinario, la abuela har una abstraccin fijndose en rasgos afectivos y de cuidado mientras que la Veterinaria lo ver como un objeto anatmico-fisiolgico de estudio.

Encapsulamiento: El encapsulamiento es el proceso mediante el cual se ocultan todos los detalles de un objeto que no contribuyen a sus caractersticas esenciales de uso, es

decir, este principio nos indica que debemos ocultar la complejidad constructiva del mdulo innecesaria para que otros objetos lo usen o se comuniquen con l sobre todo por motivos de seguridad y de la integridad del mdulo. Este principio nos propone fragmentar las abstracciones en dos partes principales, una parte constitutiva y otra parte de interfaz o servicio visible a comunicaciones o servicios. De esta manera la complejidad con la que se elabora cierta abstraccin queda a salvo y no preocupa a capas superiores de abstraccin. En la figura el gato ser tal que deber cerrar y unir con su piel todos sus mdulos componentes, negando la vista al usuario de mdulos internos cuya complejidad lo debe mantener ajeno, as el usuario no alcanzar a ver ni tripas ni corazn simplemente ver su fisonoma externa. Al crear objetos Orientados a Objetos, debe tratarse de ocultar todos los datos posibles y el contacto entre objeto y objeto para transferir informacin debe ser en lo posible va mensajes o invocacin de mtodos.

Modularidad: es una particin funcional de todo el sistema. Cada mdulo o parte del sistema debe contar tanto con una funcionalidad clara y relativamente sencilla como con una facilidad de combinarse con otros mdulos. Condicionantes tales como limitacin de memoria o dadas por compiladores o lenguajes particulares inducen a la modularidad pero el principio en la Tecnologa Orientada a Objetos es dividir funcionalmente buscando la interrelacin ms rica entre mdulos. A los mdulos se le ha llamado tambin paquetes unidades. Una divisin temtica de los mdulos es una manera muy conveniente de equilibrar la modularizacin, de esta manera, un mdulo puede ser el de los clculos numricos mientras que otro el de las operaciones con cadenas, o bien: un mdulo puede ser el de las variables generales y de arranque y configuracin de un sistema, un segundo mdulo alojar las clases primitivas, de las cuales se derivarn siempre para su uso otras clases y un tercer mdulo tendr las clases que usan a las primitivas.

En la figura nuestro gato aparece descompuesto en unidades funcionales. Su corazn funciona muy bien, al igual que el mecanismo de cuerda y cola, cada parte debe embonar perfectamente con las de su entorno para formar un gato completo.

Jerarqua: es el orden por niveles de todas las abstracciones. Las dos partes ms importantes de la jerarqua son la estructura de clases y la estructura de objetos. La primera establece todas las relaciones de herencia en sus modalidades permitidas, la segunda, la dinmica de mensajes. La organizacin de todas las abstracciones logradas en un sistema est en un orden riguroso que categoriza objetos de un mismo o semejante tipo dentro de una misma categora. As al hablar de ratones, podremos hablar de los blancos, los negros o los pintos pero en otra categora hablaremos de sus rganos y posiblemente en una categora ms inferior de sus tejidos. Ni los tejidos sabrn a qu rgano pertenecen ni los rganos a qu ratn pertenecen. La abstraccin superior no sabe de sus constituyentes nfimos y viceversa. Cada abstraccin debe connotar un nivel. En la figura observamos la sucesiva divisin de los objetos por medio de una ingeniosa analoga con cribas de orificio cada vez menor, en la primera criba quedan slo los objetos mayores: ratones completos, en la segunda los arreglos de mecanismos, en la tercera mecanismos unitarios aislados y as sucesivamente hasta llegar posiblemente a una atomizacin.

c) Ciclo De Vida El ciclo de vida RUP es una implementacin del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones. RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi en las distintas actividades. En la Figura muestra cmo vara el esfuerzo asociado a las disciplinas segn la fase en la que se encuentre el proyecto RUP. Las primeras iteraciones (en las fases de Inicio y Elaboracin) se enfocan hacia la comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto, la eliminacin de los riesgos crticos, y al establecimiento de una baseline (Lnea Base) de la arquitectura. Durante la fase de inicio las iteraciones hacen mayor nfasis en actividades de modelado del negocio y de requisitos. En la fase de elaboracin, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan ms los flujos de trabajo de requisitos, modelo de negocios (refinamiento), anlisis, diseo y una parte de implementacin orientado a la baseline de la arquitectura. En la fase de construccin, se lleva a cabo la construccin del producto por medio de una serie de iteraciones. Para cada iteracin se seleccionan algunos Casos de Uso, se refinan su anlisis y diseo y se procede a su implementacin y pruebas. Se realiza una pequea cascada para cada ciclo. Se realizan iteraciones hasta que se termine la implementacin de la nueva versin del producto.

En la fase de transicin se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios. Como se puede observar en cada fase participan todas las disciplinas, pero dependiendo de la fase el esfuerzo dedicado a una disciplina vara.

Esfuerzo en actividades segn fase del proyecto.

3.

DISEO ORIENTADO A OBJETOS a) Definicin:

Es una fase de la metodologa orientada a objetos para el desarrollo de Software. Su uso induce a los programadores a pensar en trminos de objetos, en vez de procedimientos, cuando planifican su cdigo. Un objeto agrupa datos encapsulados y procedimientos para representar una entidad. La 'interfaz del objeto', esto es, las formas de interactuar con el objeto, tambin es definida en esta etapa. Un programa orientado a objetos es descrito por la interaccin de esos objetos. El diseo orientado a objetos es la disciplina que define los objetos y sus interacciones para resolver un problema de negocio que fue identificado y documentado durante el anlisis orientado a objetos.

b) Principios Del Diseo Orientado A Objetos Los principios bsicos del diseo orientado a objetos se pueden resumir en: 1. Identificar a los objetos adecuados. 2. Favorecer el bajo acoplamiento. 3. Favorecer la reutilizacin de cdigo.

Para identificar los objetos adecuados, debemos descomponer el problema en casos de uso, en decir, pensar en que y no en como. Una prctica muy habitual es encontrar los objetos a travs de los sustantivos y verbos utilizados para definir los casos de uso, los sustantivos se suelen traducir en clases y propiedades mientras que los verbos en mtodos. En el diseo orientado a objetos, los objetos necesitan interactuar y comunicarse, para realizar dicha comunicacin, los objetos utilizan su propia interfaz pblica, dicha interfaz se compone principalmente de mtodos y propiedades. Para resolver el acoplamiento entre clases, debemos separar la interfaz de la implementacin. Si basamos las dependencias entre clases en interfaces, minimizamos el acoplamiento entre clases a un conjunto de funciones. Para favorecer la reutilizacin de cdigo, muchas veces aplicamos el concepto de la herencia, sin embargo cuando heredamos de una clase, heredamos un contexto de ejecucin y por tanto tenemos visibilidad del estado de la clase heredada, y esto puede llegar a ser problemtico por que una clase derivada que utilice el contexto que hereda (los mtodos heredados) puede romperse por cambios en la clase padre si dichos cambios alteran el contrato. Para favorecer la reutilizacin de cdigo, disponemos de dos opciones: Herencia (caja blanca) Composicin (caja negra)

La composicin de objetos, conlleva crear un objeto que cree un envoltorio donde alojar una instancia del objeto que deseamos reutilizar y que se referencie a travs de un miembro privado, Cuando creamos un objeto envoltorio, estamos favoreciendo la composicin sobre la herencia, pero entonces, Cuando usar herencia?, usaremos herencia cuando: Queremos compartir mtodos a travs de la clase base. Queremos aprovecharnos del polimorfismo (mtodos abstractos y virtuales).

Con la composicin los cambios en el objeto compuesto no afectan al objeto interno, adems los cambios del objeto interno, no afectan al objeto contenedor mientras no impliquen modificar la interfaz pblica. Ms Principios

 Responsabilidad nica: Cada clase debe ser responsable de realizar solo una actividad del sistema Clase Abierta y Cerrada: Una clase debe ser abierta a la extensin y cerrada a la modificacin Principio de Substitucin de Liskov : Cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas Principio de Inversin de Dependencia : Los mdulos de nivel superior no deben depender sino de las abstracciones. Los detalles deben depender a su vez de las abstracciones, no al contrario Principio de Segregacin de Interfaces : La implementacin de las abstracciones (que contradictorio) debe estar en la medida de lo posible en interfaces y no en clases Principio de Equivalencia de Reso y Distribucin: Solo los componentes que se distribuyen de manera final pueden ser reutilizados, el elemento ms importante es entonces el paquete. Principio de Cierre Comn: Los componentes que comparten funciones entre ellos o que dependen uno del otro deberan ser colocados juntos Principio de Reso Comn: Si se reutiliza una clase de un paquete entonces se reutilizan todas Principio de Dependencias acclicas: Los paquetes y sus dependencias no deben formar ciclos entre si Principio de Dependencias Estables: Los paquetes menos estables han de depender de los paquetes ms estables Principio de Abstraccin Estable: Los paquetes deben ser ms abstractos mientras ms estables son

CONCLUSIN

Existen diversos procesos para la elaboracin de un software o sistema que satisfaga las necesidades de los usuarios o clientes, y una de los mas eficientes es el proceso unificado de software, en el cual se ejecutan varias fases, las cuales se encargan de brindar el anlisis, o la comprensin remota de lo que el usuario o cliente desea obtener para as poder despus arrancar con las dems etapas ya una vez comprendida la situacin, este proceso es muy eficiente para la elaboracin de un solo software para una sola organizacin ya que se enfoca mucho en su perfeccionamiento y la satisfaccin del cliente como tal. La fase de prueba es indispensable para la culminacin del proyecto del software ya que nos brinda la oportunidad de remendar errores y perfeccionar una vez ms el funcionamiento y la presentacin del proyecto ante el usuario y as poder satisfacer sus necesidades planteadas en el planteamiento del problema o del negocio al inicio.

BIBLIOGRAFIA

http://ingsoftware072301.obolog.com/up-proceso-unificado-2010775 http://www.chaco.gov.ar/utn/disenodesistemas/apuntes/oo/ApunteRUP.pdf http://www.rodolfoquispe.org/blog/que-es-el-puds-proceso-unificado-dedesarrollo-de-software.php http://www.oocities.org/es/annadugarte/ads1/Objetos.htm http://yaqui.mxl.uabc.mx/~molguin/as/RUP.htm JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James. El Proceso Unificado de Desarrollo de Software. Pearson Addisson-Wesley. Ao 2000... http://es.wikipedia.org/wiki/Proceso_Unificado http://wiki.monagas.udo.edu.ve/index.php/UNIDAD_IV:_DISEO_ORIENTA DO_A_OBJETOS http://indalog.ual.es/mtorres/LP/DOO.pdf http://di002.edv.uniovi.es/~cernuda/pfc/doo.pdf http://astreo.ii.uam.es/~jlara/TACCII/4_ADOO.pdf http://www.elguille.info/colabora/NET2005/Percynet_Conceptosyprincipiosorie ntadoaobjetos.htm http://uxmcc1.iimas.unam.mx/~cursos/Objetos/Clase2/clase2.html http://uxmcc1.iimas.unam.mx/~cursos/Objetos/Clase2/clase2.html