cuestionario unidad2

of 24 /24
CUESTIONARIO 1 UNIDAD 2 1) EXPLIQUE AMPLIAMENTE EN QUE CONSISTE EL MODELADO ORIENTADO A OBJETOS Y CUALES SON SUS IMPLIFICACIONES AL REALIZAR SISTEMAS DE COMPUTO (SOFTWARE). El MOO es la construcción de modelos de un sistema por medio de la identificación y especificación de un conjunto de objetos relacionados, que se comportan y colaboran entre sí de acuerdo a los requerimientos establecidos para el sistema de objetos. La definición anterior ya sugiere la distinción, dentro del proceso de MOO, de tres dimensiones o perspectivas relativamente ortogonales para describir un sistema de objetos: Dimensión estructural de los objetos: Se centra en las propiedades estáticas o pasivas de los sistemas. Está relacionada con la estructura estática del sistema de objetos. Dimensión dinámica del comportamiento: Se centra en las propiedades activas y describe el comportamiento individual y la colaboración entre los objetos que constituyen el sistema. Dimensión funcional de los requerimientos: Son consideradas las propiedades relativas a la función de transformación del sistema de objetos, es decir, los procesos de conversión de entradas en salidas. El proceso de MOO puede ser dividido en un conjunto mínimo de actividades. La lista a seguir muestra estas actividades sin ninguna secuencia específica: Identificar las clases, objetos y atributos: Se determinan cuáles son las clases, objetos y atributos que deben incluirse en el modelo. Asociar estáticamente los objetos: Es la configuración de una estructura estática que exprese relaciones dependientes del dominio del problema. Describir el comportamiento de los objetos: Es la especificación del comportamiento de los objetos sobre la base de los conceptos básicos de estado, regla de transición, evento y acción. Definir la colaboración del comportamiento de los objetos: Busca reflejar la interacción o colaboración entre los objetos, considerando el flujo de eventos o mensajes entre los mismos. Organizar las clases en jerarquías de herencia: Se propone organizar las clases de tal forma a maximizar la compartición de propiedades comunes entre ellas. Agregar y/o particionar las clases por niveles de abstracción: Jerarquiza el modelo por niveles de complejidad haciendo uso de mecanismos de particionamiento o de agregación.

Author: susho

Post on 06-Jun-2015

1.612 views

Category:

Documents


1 download

Embed Size (px)

TRANSCRIPT

CUESTIONARIO 1 UNIDAD 2

1) EXPLIQUE AMPLIAMENTE EN QUE CONSISTE EL MODELADO ORIENTADO A OBJETOS Y CUALES SON SUS IMPLIFICACIONES AL REALIZAR SISTEMAS DE COMPUTO (SOFTWARE).

El MOO es la construccin de modelos de un sistema por medio de la identificacin y especificacin de un conjunto de objetos relacionados, que se comportan y colaboran entre s de acuerdo a los requerimientos establecidos para el sistema de objetos. La definicin anterior ya sugiere la distincin, dentro del proceso de MOO, de tres dimensiones o perspectivas relativamente ortogonales para describir un sistema de objetos: Dimensin estructural de los objetos: Se centra en las propiedades estticas o pasivas de los sistemas. Est relacionada con la estructura esttica del sistema de objetos. Dimensin dinmica del comportamiento: Se centra en las propiedades activas y describe el comportamiento individual y la colaboracin entre los objetos que constituyen el sistema. Dimensin funcional de los requerimientos: Son consideradas las propiedades relativas a la funcin de transformacin del sistema de objetos, es decir, los procesos de conversin de entradas en salidas. El proceso de MOO puede ser dividido en un conjunto mnimo de actividades. La lista a seguir muestra estas actividades sin ninguna secuencia especfica: Identificar las clases, objetos y atributos: Se determinan cules son las clases, objetos y atributos que deben incluirse en el modelo. Asociar estticamente los objetos: Es la configuracin de una estructura esttica que exprese relaciones dependientes del dominio del problema. Describir el comportamiento de los objetos: Es la especificacin del comportamiento de los objetos sobre la base de los conceptos bsicos de estado, regla de transicin, evento y accin. Definir la colaboracin del comportamiento de los objetos: Busca reflejar la interaccin o colaboracin entre los objetos, considerando el flujo de eventos o mensajes entre los mismos. Organizar las clases en jerarquas de herencia: Se propone organizar las clases de tal forma a maximizar la comparticin de propiedades comunes entre ellas. Agregar y/o particionar las clases por niveles de abstraccin: Jerarquiza el modelo por niveles de complejidad haciendo uso de mecanismos de particionamiento o de agregacin.

2) ENLISTE Y DEFINA LOS 9 DIAGRAMAS DE UML.

Diagrama de casos de uso que muestra a los actores (otros usuarios del sistema), los casos de uso (las situaciones que se producen cuando utilizan el sistema) y sus relaciones. Diagrama de clases que muestra las clases y la relaciones entre ellas. Diagrama de secuencia muestra los objetos y sus mltiples relaciones entre ellos. Diagrama de colaboracin que muestra objetos y sus relaciones, destacando los objetos que participan en el intercambio de mensajes. Diagrama de estado muestra estados, cambios de estado y eventos en un objeto o en parte del sistema. Diagrama de actividad que muestra actividades, as como los cambios de una a otra actividad junto con los eventos que ocurren en ciertas partes del sistema. Diagrama de componentes que muestra los componentes de mayor nivel de la programacin (cosas como Kparts o Java Beans). Diagrama de implementacin que muestra las instancias de los componentes y sus relaciones. Diagrama de relaciones de entidad que muestra los datos y las relaciones y restricciones entre ellos.

3) REPRESENTE GRAFICAMENTE CADA UNO DE LOS 9 DIAGRAMAS UML Y EXPLIQUE SU INTERPRETACION.

Diagrama de casos de uso Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de casos de uso y los actores participantes en el proceso.

Es importante resaltar que los diagramas de casos de uso no estn pensados para representar el diseo y no puede describir los elementos internos de un sistema. Los diagramas de casos de uso sirven para facilitar la comunicacin con los futuros usuarios del sistema, y con el cliente, y resultan especialmente tiles para determinar las caractersticas necesarias que tendr el sistema. En otras palabras,

los diagramas de casos de uso describen qu es lo que debe hacer el sistema, pero no cmo.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 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:

que especifica una situacin en la que un caso de uso tiene lugar dentro de otro caso de uso 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. Los actores no representan a personas fsicas o a sistemas, sino su papel. Esto significa que cuando una persona interacciones con el sistema de diferentes maneras (asumiendo diferentes papeles), estar representado por varios actores. Por ejemplo, una persona que proporciona servicios de atencin al cliente telefnicamente 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.

Clase Una clase define los atributos y los mtodos de una serie de objetos. Todos los objetos de esta clase (instancias de esa clase) tienen el mismo comportamiento y el mismo conjunto de atributos (cada objetos tiene el suyo propio). En ocasiones se utiliza el trmino tipo en lugar de clase, pero recuerde que no son lo mismo, y que el trmino tipo tiene un significado ms general.

En , las clases estn representadas por rectngulos, con el nombre de la clase, y tambin pueden mostrar atributos y operaciones de la clase en otros dos compartimentos dentro del rectngulo.

Representacin visual de una clase en UML

Atributos En UML, los atributos se muestran al menos con su nombre, y tambin pueden mostrar su tipo, valor inicial y otras propiedades. Los atributos tambin pueden ser mostrados visualmente:

+ Indica atributos pblicos # Indica atributos protegidos - Indica atributos privados

Operaciones Las operaciones (mtodos) tambin se muestran al menos con su nombre, y pueden mostrar sus parmetros y valores de retorno. Las operaciones, al igual que los atributos, se pueden mostrar visualmente:

+ Indica operaciones pblicas # Indica operaciones protegidas - Indica operaciones privadas

Plantillas Las clases pueden tener plantillas, un valor usado para una clase no especificada o un tipo. El tipo de plantilla se especifica cuando se inicia una clase (es decir cuando se crea un objeto). Las plantillas existen en C++ y se introducirn en Java 1.5 con el nombre de Genricos.

Asociaciones de clases Las clases se puede relaciones (estar asocionadas) con otras de diferentes maneras: Generalizacin La herencia es uno de los conceptos fundamentales de la programacin orientada a objetos, en la que una clase recoge todos los atributos y operaciones de la clase de la que es heredera, y puede alterar/modificar algunos de ellos, as como aadir ms atributos y operaciones propias. En UML, una asociacin de generalizacin entre dos clases, coloca a estas en una jerarqua que representa el concepto de herencia de una clase derivada de la clase base. En UML, las generalizaciones se representan por medio de una lnea que conecta las dos clases, con una flecha en el lado de la clase base.

Representacin visual de una generalizacin en UML

Asociaciones Una asociacin representa una relacin entre clases, y aporta la semntica comn y la estructura de muchos tipos de conexiones entre objetos. Las asociaciones son los mecanismos que permite a los objetos comunicarse entre s. Describe la conexin entre diferentes clases (la conexin entre los objetos reales se denomina conexin de objetos o enlace). Las asociaciones pueden tener una papel que especifica el propsito de la asociacin y pueden ser unidireccionales o bidireccionales (indicando si los dos objetos participantes en la relacin pueden intercambiar mensajes entre s, o es nicamente uno de ellos el que recibe informacin del otro). Cada extremo de la asociacin tambin tiene un valor de multiplicidad, que indica cuntos objetos de ese lado de la asociacin estn relacionados con un objeto del extremo contrario.

En UML, las asociaciones se representan por medio de lneas que conectan las clases participantes en la relacin, y tambin pueden mostrar el papel y la multiplicidad de cada uno de los participantes. La multiplicidad se muestra como un rango [mn...mx] de valores no negativos, con un asterisco (*) representando el infinito en el lado mximo.

Representacin visual de una asociacin en UML

Acumulacin Las acumulaciones son tipos especiales de asociaciones en las que las dos clases participantes no tienen un estado igual, pero constituyen una relacin completa. Una acumulacin describe cmo se compone la clase que asume el rol completo de otras clases que se encargan de las partes. En las acumulaciones, la clase que acta como completa, tiene una multiplicidad de uno. En UML, las acumulaciones estn representadas por una asociacin que muestra un rombo en uno de los lados de la clase completa.

Representacin visual de una relacin de acumulacin en UML

Composicin Las composiciones son asociaciones que representan acumulaciones muy fuertes. Esto significa que las composiciones tambin forman relaciones completas, pero dichas relaciones son tan fuertes que las partes no pueden existir por s mismas. nicamente existen como parte del conjunto, y si este es destruido las partes tambin lo son. En UML, las composiciones estn representadas por un rombo slido al lado del conjunto.

Otros componentes de los diagrama de clases Los diagramas de clases pueden contener ms componentes aparte de clases. Interfaces Las interfaces son clases abstractas, esto es, instancias que no pueden ser creadas directamente a partir de ellas. Pueden contener operaciones, pero no atributos. Las clases pueden heredarse de las interfaces pudiendo as realizarse instancias a partir de estos diagramas. Tipo de datos Los tipo de datos son primitivas incluidas en algunos lenguajes de programacin. Algunos ejemplos son: bool y float. No pueden tener relacin con clases, pero las clases s pueden relacionarse con ellos. Enumeraciones Las enumeraciones son simples listas de valores. Un ejemplo tpico de esto sera una enumeracin de los das de la semana. Al igual que los tipos de datos, no pueden relacionarse con las clases, pero las clases s pueden hacerlo con ellos. Paquetes Los paquetes, en lenguajes de programacin, representan un espacio de nombres en un diagrama se emplean para representar partes del sistema que contienen ms de una clase, incluso cientos de ellas. Diagramas de secuencia Los diagramas de secuencia muestran el intercambio de mensajes (es decir la forma en que se invocan) en un momento dado. Los diagramas de secuencia ponen especial nfasis en el orden y el momento en que se envan los mensajes a los objetos. En los diagramas de secuencia, los objetos estn representados por lneas intermitentes verticales, con el nombre del objeto en la parte ms alta. El eje de tiempo tambin es vertical, incrementndose hacia abajo, de forma que los mensajes son enviados de un objeto a otro en forma de flechas con los nombres de la operacin y los parmetros.

Los mensajes pueden ser o bien sncronos, el tipo normal de llamada del mensaje donde se pasa el control a objeto llamado hasta que el mtodo finalize, o asncronos donde se devuelve el control directamente al objeto que realiza la llamada. Los mensajes sncronos tienen una caja vertical en un lateral del objeto invocante que muestra el flujo del control del programa.

Diagramas de colaboracin Los diagramas de colaboracin muestran las interacciones que ocurren entre los objetos que participan en una situacin determinada. Esta es ms o menos la misma informacin que la mostrada por los diagramas de secuencia, pero destacando la forma en que las operaciones se producen en el tiempo, mientras que los diagramas de colaboracin fijan el inters en las relaciones entre los objetos y su topologa.

En los diagramas de colaboracin los mensajes enviados de un objeto a otro se representan mediante flechas, mostrando el nombre del mensaje, los parmetros y la secuencia del mensaje. Los diagramas de colaboracin estn indicados para mostrar una situacin o flujo programa especficos y son unos de los mejores tipos de diagramas para demostrar o explicar rpidamente un proceso dentro de la lgica del programa.

Diagrama de estado Los diagramas de estado muestran los diferentes estados de un objeto durante su vida, y los estmulos que provocan los cambios de estado en un objeto.

Los diagramas de estado ven a los objetos como mquinas de estado o autmatas finitos que pueden estar en un conjunto de estados finitos y que pueden cambiar su estado a travs de un estmulo perteneciente a un conjunto finito. Por ejemplo, un objeto de tipo NetServer puede tener durante su vida uno de los siguientes estados:

Listo Escuchando Trabajando Detenido

y los eventos que pueden producir que el objeto cambie de estado son

Se crea el objeto El objeto recibe un mensaje de escucha Un cliente solicita una conexin a travs de la red Un cliente finaliza una solicitud La solicitud se ejecuta y ser termina El objeto recibe un mensaje de detencin Etc.

Estado Los estados son los ladrillos de los diagramas de estado. Un estado pertenece a exactamente una clase y representa un resumen de los valores y atributos que puede tener la clase. Un estado UML describe el estado interno de un objeto de una clase particular Tenga en cuenta que no todos los cambios en los atributos de un objeto deben estar representados por estados, sino nicamente aquellos cambios que pueden afectar significativamente a la forma de funcionamiento del objeto Hay dos tipos especiales de estados: inicio y fin. Son especiales en el sentido de que no hay ningn evento que pueda devolver a un objeto a su estado de inicio, y de la misma forma no hay ningn evento que pueda sacar a un objeto de su estado de fin.

Diagrama de actividadLos diagramas de actividad describen la secuencia de las actividades en un sistema. Los diagramas de actividad son una forma especial de los diagramas de estado, que nicamente (o mayormente) contienen actividades.

Los diagramas de actividad son similares a los diagramas de flujo procesales, con la diferencia de que todas las actividades estn claramente unidas a objetos. Los diagramas de actividad siempre estn asociados a una clase, a una operacin o a un caso de uso. Los diagramas de actividad soportan actividades tanto secuenciales como paralelas. La ejecucin paralela se representa por medio de iconos de fork/espera, y en el caso de las actividades paralelas, no importa en qu orden sean invocadas (pueden ser ejecutadas simultneamente o una detrs de otra). Actividad Una actividad es un nico paso de un proceso. Una activa es un estado del sistema que actividad interna y, al menos, una transicin saliente. Las actividades tambin pueden tener ms de una transicin saliente, si tienen diferentes condiciones. Las actividades pueden formar jerarquas, lo que significa que una actividad puede estar formada de varias actividades de detalle, en cuyo caso las transiciones entrantes y salientes deberan coincidir con las del diagrama de detalle. Elementos de ayuda Existen unos pocos elementos en UML que no tiene un valor semntico real en la maqueta, pero que ayudan a clarificar partes del programa. Estos elementos son

Lnea de texto Notas de texto y enlaces Cajas

Las lneas de texto son tiles para aadir informacin textual a un diagrama. Es texto es libre y no tiene ningn significado para la maqueta. Las notas son tiles para aadir informacin ms detallada de un objeto o una situacin especfica. Tienen la gran ventaja de que se pueden anclar a los elementos UML para mostrar que una nota pertenece a un objeto o situacin especficos Las cajas son rectngulos repartidos libremente que pueden usarse para juntar objetos haciendo los diagramas ms legibles. No tienen significado lgico en la maqueta Diagramas de componentes Los diagramas de componentes muestran los componentes del software (ya sea las tecnologas que lo forman como Kparts, componentes CORBA, Java Beans o simplemente

secciones del sistema claramente distintas) y los artilugios de que est compuesto como los archivos de cdigo fuente, las libreras o las tablas de una base de datos. Los componentes pueden tener interfaces (es decir clases abstractas con operaciones) que permiten asociaciones entre componentes. Diagramas de implementacin Los diagramas de implementacin muestran las instancias existentes al ejecutarse as como sus relaciones. Tambin se representan los nodos que identifican recursos fsicos, tpicamente un ordenador as como interfaces y objetos (instancias de las clases). Diagramas de relacin de entidad Los diagramas de relaciones de entidad (diagramas ER) muestran el diseo conceptual de las aplicaciones de bases de datos. Representan varias entidades (conceptos) en el sistema de informacin y las relaciones y restricciones existentes entre ellas. Una extensin de los diagramas de relaciones de entidad llamado diagramas de relaciones de entidad extendida o diagramas de relaciones de entidad mejoradas (EER), se utiliza para incorporar las tcnicas de diseo orientadas a objetos en los diagramas ER.

Entidad Una Entidad es cualquier concepto del mundo real con una existencia independiente. Puede ser un objeto con una existencia fsica (ejemplo, mquina, robot) o puede ser un objeto con una existencia conceptual (p. ej.: Curso de universidad). Cada entidad tiene un conjunto de atributos que describen las propiedades de la entidad. Nota: No existen notaciones estndar para representar los diagramas ER. Los diferentes textos sobre este asunto utilizan diferentes notaciones. Los conceptos y notaciones para los diagramas EER utilizados en Umbrello provienen del siguiente libro: Elmasri R. y Navathe S. (2004). Fundamentals of Database Systems 4 ed. Addison Wesley (Fundamentos de los sistemas de bases de datos) En un diagrama ER, las entidades se representan como rectngulos, con el nombre de la clase, y tambin pueden mostrar atributos y operaciones de la clase en otros dos compartimentos dentro del rectngulo.

Representacin visual de una entidad en un diagrama ER

Atributos de la entidad En los diagramas ER, los atributos de la entidad se muestra con su nombre en un compartimento diferente de la entidad a la que pertenecen. Restricciones Las restricciones en los diagramas ER especifican las restricciones de los datos en el esquema de informacin. Existen cuatro tipos de restricciones soportadas por Umbrello:

Clave primaria: El conjunto de atributos declarados como clave primaria es nica para la entidad. Solo puede haber una clave primaria en una entidad y ninguno de los atributos que la componen puede ser NULL. Clave nica: El conjunto de atributos declarados como nica son nicos para la entidad. Pueden haber muchas restricciones nicas en una entidad. Los atributos que lo componen pueden tener el valor NULL. Las claves nicas y primarias identifican de forma nica una fila de una tabla (entidad) Clave externa: Una clave externa es una restriccin referencia entre dos tablas. La clave externa identifica una columna o un conjunto de columnas en un tabla (referenciada) que referencia una columna o conjunto de columnas en otra tabla (referenciada). Las columnas en la tabla referenciada deben formar una clave primaria o una clave nica. Restriccin de comprobacin: Una restriccin de comprobacin (tambin conocida como restriccin de comprobacin de tabla) es una condicin que define los datos vlidos cuando se aaden o actualizan datos en una tabla de la base de datos relacional. Se aplicar una restriccin a cada fila de la tabla. La restriccin debe ser un predicado. Puede referirse a una o varias columnas de la tabla. Ejemplo: precio >= 0

Conceptos del diagrama de relaciones de entidades extendido (EER) Especializacin La especializacin es una manera de formar nuevas entidades utilizando entidades que ya se hayan definido. Las entidades nuevas, conocidas como entidades derivadas, asumir (o heredar) atributos de las entidades que ya existan, y que se refieren a las entidades base. Se pretende ayudar a reutilizar datos con pequeas o ninguna modificacin. En Umbrello, se puede especificar la especializacin de separacin y de solapamiento La especializacin de separacin La especializacin de separacin especifica que las subclases de la especializacin se pueden separar. Esto significa que una entidad puede ser miembro de ms de una de las entidades derivadas de la especializacin

Representacin visual de una especializacin de separacin en un diagrama EER

Especializacin de solapamiento Cuando las entidades derivadas no tienen restricciones para separarse, el conjunto de entidades se dice que estn en una especializacin de solapamiento. Esto significa que al igual que en el mundo real la entidad puede ser miembro de ms de una entidad derivada de la especializacin

Representacin visual de la especializacin de solapamiento en un diagrama EER

Categora Una entidad derivada se dice que es una Categora cuando representa una coleccin de objetos que es un subconjunto de unin de distintos tipos de entidades. Una categora se modela cuando se necesita relaciones de superclase/subclase sencillas con ms de una superclase, donde las superclases representan diferentes tipos de entidad (similar a la herencia mltiple en la programacin orientada a objetos).

Representacin visual de una categora en un diagrama EER4) ENLISTE 7 PERSONAJES IMPORTANTES PARA LA CREACION DEL UML Y SU APORTACION. 1.-BOOCH 2.-RUMBAUCH 3.-JACOBSON 4.-MEYER 5.-HAREL 6.-ODELL 7.-SHLAER-MELLOR 5) DESCRIBA 3 METODOLOGIAS PARA EL DESARROLLO DEL SOFTWARE Y EXPLIQUR AMPLIAMENTE SU FORMA DE APLICARSE.

Rational Unified Process (RUP) La metodologa RUP, llamada as por sus siglas en ingls Rational Unified Process, divide en 4 fases el desarrollo del software:

Inicio, El Objetivo en esta etapa es determinar la visin del proyecto. Elaboracin, En esta etapa el objetivo es determinar la arquitectura ptima. Construccin, En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial. Transmisin, El objetivo es llegar a obtener el release del proyecto. Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en reproducir el ciclo de vida en cascada a menor escala. Los Objetivos de una iteracin se establecen en funcin de la evaluacin de las iteraciones precedentes. Vale mencionar que el ciclo de vida que se desarrolla por cada iteracin, es llevada bajo dos disciplinas: Disciplina de Desarrollo Ingeniera de Negocios: Entendiendo las necesidades del negocio. Requerimientos: Trasladando las necesidades del negocio a un sistema automatizado. Anlisis y Diseo: Trasladando los requerimientos dentro de la arquitectura de software. Implementacin: Creando software que se ajuste a la arquitectura y que tenga el comportamiento deseado. Pruebas: Asegurndose que el comportamiento requerido es el correcto y que todo los solicitado esta presente. Disciplina de Soporte Configuracin y administracin del cambio: Guardando todas las versiones del proyecto. Administrando el proyecto: Administrando horarios y recursos. Ambiente: Administrando el ambiente de desarrollo. Distribucin: Hacer todo lo necesario para la salida del proyecto

Figura 1: Fases e Iteraciones de la Metodologa RUP

Es recomendable que a cada una de estas iteraciones se les clasifique y ordene segn su prioridad, y que cada una se convierte luego en un entregable al cliente. Esto trae como beneficio la retroalimentacin que se tendra en cada entregable o en cada iteracin. Los elementos del RUP son: Actividades, Son los procesos que se llegan a determinar en cada iteracin. Trabajadores, Vienen hacer las personas o entes involucrados en cada proceso. Artefactos, Un artefacto puede ser un documento, un modelo, o un elemento de modelo. Una particularidad de esta metodologa es que, en cada ciclo de iteracin, se hace exigente el uso de artefactos, siendo por este motivo, una de las metodologas ms importantes para alcanzar un grado de certificacin en el desarrollo del software.

Extreme Programing (XP) Es una de las metodologas de desarrollo de software ms exitosas en la actualidad utilizada para proyectos de corto plazo, cort equipo y cuyo plazo de entrega era ayer. La metodologa consiste en una programacin rpida o extrema, cuya particularidad es tener como parte del equipo, al usuario final, pues es uno de los requisitos para llegar al xito del proyecto.

Figura 2: Metodologa Extreme Programing

Caractersticas de XP, la metodologa se basa en:

Pruebas Unitarias: se basa en las pruebas realizadas a los principales procesos, de tal manera que adelantndonos en algo hacia el futuro, podamos hacer pruebas de las fallas que pudieran ocurrir. Es como si nos adelantramos a obtener los posibles errores. Refabricacin: se basa en la reutilizacin de cdigo, para lo cual se crean patrones o modelos estndares, siendo ms flexible al cambio. Programacin en pares: una particularidad de esta metodologa es que propone la programacin en pares, la cual consiste en que dos desarrolladores participen en un proyecto en una misma estacin de trabajo. Cada miembro lleva a cabo la accin que el otro no est haciendo en ese momento. Es como el chofer y el copiloto: mientras uno conduce, el otro consulta el mapa.

Qu es lo que propone XP? Empieza en pequeo y aade funcionalidad con retroalimentacin continua El manejo del cambio se convierte en parte sustantiva del proceso El costo del cambio no depende de la fase o etapa No introduce funcionalidades antes que sean necesarias El cliente o el usuario se convierte en miembro del equipo Derechos del Cliente Decidir que se implementa Saber el estado real y el progreso del proyecto Aadir, cambiar o quitar requerimientos en cualquier momento Obtener lo mximo de cada semana de trabajo Obtener un sistema funcionando cada 3 o 4 meses Derechos del Desarrollador Decidir como se implementan los procesos Crear el sistema con la mejor calidad posible Pedir al cliente en cualquier momento aclaraciones de los requerimientos Estimar el esfuerzo para implementar el sistema Cambiar los requerimientos en base a nuevos descubrimientos Lo fundamental en este tipo de metodologa es: La comunicacin, entre los usuarios y los desarrolladores La simplicidad, al desarrollar y codificar los mdulos del sistema La retroalimentacin, concreta y frecuente del equipo de desarrollo, el cliente y los usuarios finales. Microsoft Solution Framework (MSF)

Esta es una metodologa flexible e interrelacionada con una serie de conceptos, modelos y prcticas de uso, que controlan la planificacin, el desarrollo y la gestin de proyectos tecnolgicos. MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnolgicas.

Figura 3: Metodologa MSF MSF tiene las siguientes caractersticas: Adaptable: es parecido a un comps, usado en cualquier parte como un mapa, del cual su uso es limitado a un especfico lugar. Escalable: puede organizar equipos tan pequeos entre 3 o 4 personas, as como tambin, proyectos que requieren 50 personas a ms. Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente. Tecnologa Agnstica: porque puede ser usada para desarrollar soluciones basadas sobre cualquier tecnologa. MSF se compone de varios modelos encargados de planificar las diferentes partes implicadas en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto, Modelo de Equipo, Modelo de Proceso, Modelo de Gestin del Riesgo, Modelo de Diseo de Proceso y finalmente el modelo de Aplicacin.

6) TOMANDO COMO REFERENCIA UN VIDEO CENTRO DISEE (SIGUENDO LAFILOSOFIA OO) UN SISTEMA DE RENTA Y CONTROL DE ESTE (REGISTROS, ALTAS, BAJAS, PRESTAMOS, FACTURACION). 7) INVESTIGUE, DESCARGUE Y PRACTIQUE CON UN SOFTWARE ADECUADO PARA REALIZAR DIAGRAMAS UML, AL TERMINO DE LA PRACTICA, REALICE UNA SINTESIS EXPLICANDO AMPLIAMENTE EN QUE CONSISTIO LO REALIZADO. PUES AL REALIZAR LOS DIAGRAMAS DE UML PRIMERO SE TUVO QUE BAJAR EL PROGRAMA EN ESTE CASO BAJE EL UML DIAGRAMMER, UNA VEZ DESCARGADO LO INSTALE EN LA PC, AUNQUE ES VERSION DEMO. ME DISPUSE A PROBAR EL PROGRAMA PARA HACER LOS 9 DIAGRAMAS, NOTE QUE CADA DIAGRAMA CONTIENE DIFERENTES HERRAMIENTAS PARA SU ELABORACION AL IGUAL QUE SU FORMA DE HACERLOS VARIA MUCHO UNO DEL OTRO. 8) APLIQUE EL SOFTWARE PARA MEJORAR EL DISEO DE LA PREGUNTA 6