DMMS_U1_A2_JUBP

Ingeniería en Desarrollo de software Semestre 4

Unidad 1. Herramientas para el modelado de software

Actividades de aprendizaje

Clave: Licenciatura TSU 15142420 / 16142420

Universidad Abierta y a Distancia de México

Actividad 2. Fases del proceso RUP Propósito: Distinguir actividades que se realizan en un proyecto real siguiendo la metodología RUP para la elaboración y finalización de un proyecto. Instrucciones: 1. De la lista de actividades resumida de un proyecto real y que se enlistan de manera desordenada, identifica cuál de las 4 fases del modelo RUP es la adecuada para comenzar su ejecución. Para eso coloca la letra que identifica a la fase en el lado derecho (columna fase) de la actividad que le corresponde. 2. Copia las tablas en un archivo de texto. 3. Coloca tus respuestas en la columna de la derecha y redacta brevemente el porqué de tus respuestas. 4. Guarda la actividad con el nombre DMMS_U1_A2_XXYZ. Sustituye las XX por las dos primeras letras de tu primer nombre, la Y por la inicial de tu primer apellido y la Z por la inicial de tu segundo apellido. 5. Envía el archivo a tu Docente en línea para recibir retroalimentación mediante la herramienta Tarea. FASES DEL PROCESO RUP

LETR A I E C T

NOMBRE DE FASE INICIO ELABORACION CONSTRUCCION TRANSICION/CIE RRE

LISTA DE ACTIVIDADES EN DESORDEN Orden 1 2 3 4 5 6 7 8 9

ACTIVIDAD Clarificar los requisitos pendientes. Desarrollar la especificación de los casos de uso, Definir visión general de la arquitectura. Realizar las mejoras del proyecto. Ajustar los errores y defectos encontrados en las pruebas de aceptación. Capacitar a los usuarios. Desarrollar la arquitectura base del sistema. Verificar que el producto cumple con las especificaciones involucradas en el proyecto. Diseñar la solución preliminar.

FASE

E E E T C T E C I

10 11 12 13 14 15 16 17 18

1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.-

Completar la funcionalidad de la iteración. Definir casos de uso de la arquitectura base del sistema. Administrar los cambios de las evaluaciones realizadas por los usuarios. Identificar riesgos. Asegurar la disponibilidad del software para los usuarios. Definir el plan de las fases e iteraciones siguientes de desarrollo. Definir el alcance del proyecto. Proveer soporte técnico. Definir la viabilidad del proyecto.

C E C E T E I T I

Carrera: Desarrollo de software Semestre 04 Programa de la asignatura: Métodos y modelos de desarrollo de software Unidad 1. Herramientas para el modelado de software Autorreflexiones. Repasemos: En un breve párrafo menciona todas las ideas, conceptos o características que conozcas sobre UML, RUP y modelado de procesos.

1. ¿Qué es UML y para qué es utilizado? El lenguaje unificado de modelado (UML), es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. Captura de decisiones y conocimiento sobre los sistemas que se deben construir. Se usa para entender, diseñar, hojear, configurar, mantener y controlar la información sobre tales sistemas, se usa con todos los métodos de desarrollo, etapas del ciclo de vida, dominios de aplicación y medios. 2. ¿Cuáles son los componentes de UML? Descríbelos brevemente. FORMA ELEMENTO DESCRIPCIÓN 1

componente

2

Puerto de la interfaz proporcionada.

3

Puerto de la interfaz necesaria.

4

Dependencia

5

Parte

Un fragmento reutilizable de funcionalidad del sistema. Un componente proporciona y consume el comportamiento a través de interfaces y puede usar otros componentes. Puede ocultar o mostrar los elementos internos de un componente mediante el control expandir y contraer. Is Indirectly Instantiated. Si es valor true (predeterminado), el componente solo existe como artefacto de diseño. En tiempo de ejecución. Representa un grupo de mensajes o llamadas que implementa el componente y que pueden usar otros componentes o sistemas externos. Un puerto es una propiedad de un componente que tiene una interfaz como su tipo. Representa un grupo de mensajes o llamadas que envía el componente a otros componentes o sistemas externos. El componente está diseñado para acoplarse a componentes que proporcionan al menos estas operaciones. El puerto tiene una interfaz como su tipo. Se puede usar para identificar una interfaz necesaria en un componente, se puede satisfacer mediante una interfaz proporcionada por otro. Las dependencias también se pueden usar de manera más general entre los elementos del modelo para mostrar que el diseño de uno depende del diseño del otro. Un atributo de un componente, cuyo tipo suele ser otro componente. Un elemento se usa en el diseño interno de su componente primario. Los elementos se muestran gráficamente, anidados dentro del componente primario. Para crear un elemento de un tipo de componente existente, arrastre el componente desde el Explorador de modelos UML hasta el componente propietario. Para crear un elemento de un nuevo tipo, haga clic en la herramienta

6

Part Assembly

7

Delegación

Generalizaion

9

Control Contraer o expandir comentario

Componente y, a continuación, haga clic en el componente propietario. Por ejemplo, un componente Car tiene los elementos engine: CarEngine, backLeft: Wheel, frontRight: Wheel, etc. Más de un elemento puede tener el mismo tipo y componentes diferentes pueden tener elementos del mismo tipo. Tipo: el tipo de elemento, que se define en otra parte del modelo. Normalmente, el tipo es otro componente. Multiplicidad: el valor predeterminado 1. Puede establecerlo en 0….1 para indicar que el elemento puede tener valor null, en * para indicar que el elemento es una colección de estancias del tipo especificado o en cualquier expresión que pueda evaluar en un intervalo de números. Una conexión entre los puertos de la interfaz necesaria de un elemento y los puertos de la interfaz proporcionada de otro elemento. La implementación de un ensamblado de elementos puede variar de un componente a otro. Los elementos conectados deben tener el mismo componente primario. Una conexión entre los puertos de la interfaz necesaria de un elemento y los puertos de la interfaz proporcionada de otro elemento. La implementación de un ensamblado de elementos puede variar de un componente a otro. Los elementos conectados deben tener el mismo componente primario. Vincula un puerto a una interfaz de uno de los elementos del componente. Indica que los mensajes enviados al componente son administrados por el elemento o que los mensajes enviados desde el elemento se envían desde el componente primario. Indica que un componente hereda de otro componente. Los elementos y las interfaces se heredan. Úselo para mostrar u ocultar los elementos internos de un componente. Para obtener notas adicionales. Puede vincular un comentario a cualquier número de elementos del diagrama mediante la herramienta Conector.

3. ¿Qué es un proceso de desarrollo de software? Un proceso está definido como una serie de acciones u operaciones que conducen a un fin. En general, una empresa u organización requiere de uno o más procesos para lograr sus objetivos, los cuales por lo general involucran la utilización de sistemas de software. En el caso de una empresa que se dedica al desarrollo de software, se requieren procesos que abarquen desde la creación de un sistema de software hasta su mantenimiento. Todo esto es conocido como el ciclo de vida del software., el desarrollo de sistemas de software es algo muy complejo. De lo contrario todos haríamos siempre software perfecto Un aspecto básico para manejar la complejidad inherente en los sistemas de software es contar con un modelo de proceso a seguir. 4. ¿Cómo define el Autor Booch, que es un modelo? Es un generador de potenciales configuraciones del sistema; los posibles sistemas son sus extensiones, o valores. Idealmente, todas las configuraciones consistentes con el modelo deberán ser posibles. A veces, sin embargo, no es posible representar todas las restricciones dentro del modelo. Es también una descripción de la estructura genérica y del significado de un sistema. Las descripciones son su objetivo o significado. Es siempre una abstracción a un cierto nivel. Captura los aspectos esenciales de un sistema y omite algunos de los detalles. Tiene los siguientes aspectos: Abstracción frente a detalle. Especificación frente a implementación Descripción frente a estancia. Variaciones a la interpretación 5. Define y describe los siguientes conceptos: Objeto

Entidades discretas, con límites bien definidos y con identidad, que encapsulan el estado y el comportamiento; se dice también de las estancias de una clase. Abstracción Acto de identificar aquellas características esenciales de una cosa que la distinguen del resto de las cosas. Tipo de dependencia que relaciona dos elementos que representan el mismo concepto en diferentes niveles de abstracción. Clases de objetos

Herencia Se refiere al mecanismo por el que se comparten atributos y operaciones usando la relación de generalización. Clases Clases Una clase es un conjunto de objetos que comparten una estructura y comportamiento comunes. Clase representa una abstracción, la esencia que comparten los objetos. Un objeto es un ejemplo de una clase. Un objeto no es una clase, y una clase no es un objeto. Las clases actúan como intermediarias entre una abstracción y los clientes que pretenden utilizar la abstracción. De esta forma, la clase muestra: Visión externa de comportamiento (interface), que enfatiza la abstracción escondiendo su estructura y secretos de comportamiento. Visión interna (implementación), que abarca el código que se ofrece en la interface de la clase. Polimorfismo. Es una desahogo del sistema de tipos, de tal manera que una referencia a una clase (atributo, parámetro o declaración local o elemento de un vector) acepta direcciones de objetos de dicha clase y de sus clases derivadas (hijas, nietas,…).

5. ¿Cuáles son los tipos de diagramas que incluye UML y cuál es su objetivo? Tipos de diagrama objetivo grafica Casos de uso

Estos diagramas muestran operaciones que se esperan de una aplicación o sistema y como se relaciona con su entorno, es por ello que se ve desde el punto de vista del usuario. Describen un uso del sistema y como éste interactúa con el usuario.

De clases

Estos diagramas son utilizados durante el proceso de análisis y diseño de los sistemas informáticos, en donde se intentan conformar el diagrama conceptual de la información que se manejará en el sistema.

De objetos

Forma parte de la vista estática del sistema. En este diagrama se modelan las instancias de las clases del Diagrama de Clases. Este diagrama cabe aclarar que cuenta con objetos y enlaces. En estos diagramas también es posible encontrar las clases para tomar como referencia su instanciación. Muestra un conjunto de objetos y sus relaciones en un momento concreto. Los Diagramas de Objetos son realmente útiles para modelar estructuras de datos

De comportamientos: De estados. De actividad.

complejas Diagrama de estados engloba todos los mensajes que un objeto puede enviar o recibir, en otras palabras es un escenario que representa un camino dentro de un diagrama. Como característica de estos diagramas siempre cuentan con dos estados especiales, el inicial y el final, con la particularidad que este diagrama puede tener solo un estado inicial pero varios estados finales. Es una variación del Diagrama de Estados UML donde los estados representan operaciones y las transiciones representan las actividades que ocurren cuando la operación es completa.

De interacción: De secuencia. De Colaboración.

Un Diagrama de Secuencias muestra una interacción ordenada según la secuencia temporal de eventos y el intercambio de mensajes. Los diagramas de secuencia ponen especial énfasis en el orden y el momento en el que se envían los mensajes a los objetos.

De Implementación: De componentes. De Despliegue.

Normalmente contiene componentes, interfaces y relaciones entre ellos. Los componentes perteneces a un mundo físico, es decir, representan a un bloque de construcción al modelar aspectos físicos de un sistema. Básicamente este tipo de diagrama se utiliza para modelar el Hardware utilizado en la implementación del sistema y las relaciones entre sus componentes.

6. Dentro de UML ¿Qué son las vistas y cuál es su clasificación? Vistas: Proyección de un modelo, que se ve desde cierta perspectiva o punto de observación y emite aquellas entidades que no son relevantes para esa perspectiva. Se refiere a las proyecciones tanto en el modelo semántico como en la notación visual. Clasificación: Vista de Casos de Uso: Nos facilita información sobre el comportamiento y funcionalidad del sistema. Vista de Diseño: Nos proporciona información del vocabulario y la funcionalidad del sistema.

Vista de Interacción: Nos da información sobre el rendimiento del sistema, la escalabilidad del mismo y la capacidad de procesamiento necesaria. Vista de Implementación: Establece el ensamblado del sistema y la gestión de la configuración. Vista de Despliegue: Nos permite establecer la topología del sistema, su distribución y las pautas para su instalación.

7. ¿Qué es un caso de uso?

Vista de Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso. 9. Dentro de los casos de uso ¿Qué significa: Asociaciones, generalización y relaciones?



Relaciones: o Asociación Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.

o Dependencia o Instanciación Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada. o Generalización Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso () o de Herencia (). Este tipo de relación está orientado exclusivamente para casos de uso (y no para actores). Extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características). Uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica. De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde está la duda clásica de usar o heredar. Ejemplo: Como ejemplo está el caso de una Máquina Recicladora: Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar:  Registrar el número de ítems ingresados.  Imprimir un recibo cuando el usuario lo solicita: a. Describe lo depositado b. El valor de cada ítem c. Total

 El usuario/cliente presiona el botón de comienzo  Existe un operador que desea saber lo siguiente: a. Cuantos ítems han sido retornados en el día. b. Al final de cada día el operador solicita un resumen de todo lo depositado en el día.  El operador debe además poder cambiar: a. Información asociada a ítems. b. Dar una alarma en el caso de que: i.

Ítem se atora.

ii.

No hay más papel.

Como una primera aproximación identificamos a los actores que interactúan con el sistema:

Luego, tenemos que un Cliente puede Depositar Ítems y un Operador puede cambiar la información de un Ítem o bien puede Imprimir un informe:

Además podemos notar que un ítem puede ser una Botella, un Tarro o una Jaba.

Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún ítem por un cliente o bien puede ser realizada a petición de un operador.

Entonces, el diseño completo del diagrama Use Case es:

10. ¿Qué significa RUP? El Proceso Unificado de Desarrollo de Software (RUP) Introducción El Proceso Unificado es un proceso de software genérico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaños de proyectos. Provee un enfoque disciplinado en la asignación de tareas y responsabilidades dentro de una organización de desarrollo. Su meta es asegurar la producción de software de muy alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y presupuesto predecible.

• Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo de vida del proceso a lo largo de su desenvolvimiento • Un eje vertical que representa las disciplinas, las cuales agrupan actividades de una manera lógica de acuerdo a su naturaleza. La primera dimensión representa el aspecto dinámico del proceso conforme se va desarrollando, se expresa en términos de fases, iteraciones e hitos (milestones). La segunda dimensión representa el aspecto estático del proceso: cómo es descrito en términos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos y roles.

11. ¿Para qué nos sirve RUP en el desarrollo de software? Un sistema de software se crea para servir a sus usuarios. Por lo tanto, para construir un sistema exitoso se debe conocer qué es lo que quieren y necesitan los usuarios prospectos. El término usuario se refiere no solamente a los usuarios humanos, sino a otros sistemas. En este contexto, el término usuario representa algo o alguien que interactúa con el sistema por desarrollar. Un caso de uso es una pieza en la funcionalidad del sistema que le da al usuario un resultado de valor. Los casos de uso capturan los requerimientos funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso el cual describe la funcionalidad completa del sistema. Este modelo reemplaza la tradicional especificación funcional del sistema. Una especificación funcional tradicional se concentra en responder la pregunta: ¿Qué se supone que el sistema debe hacer? La estrategia de casos de uso puede ser definida agregando tres palabras al final de la pregunta: ¿por cada usuario? Estas tres palabras tienen una implicación importante, nos fuerzan a pensar en términos del valor a los usuarios y no solamente en términos de las funciones que sería bueno que tuviera. Sin embargo, los casos de uso no son solamente una herramienta para especificar los requerimientos del sistema, también dirigen su diseño, implementación y pruebas, esto es, dirigen el proceso de desarrollo. Aún y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada. Son desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso dirigen la arquitectura del sistema y la arquitectura del sistema influencia la elección de los casos de uso. Por lo tanto, al arquitectura del sistema y los casos de uso maduran conforme avanza el ciclo de vida. 12. ¿Qué relevancia encontré en los contenidos para enriquecerme como persona y en un futuro como profesional? Encontré que con una buena planeación y análisis se puede facilitar la solución de casi cualquier problema que ocurre en la vida diaria 13. ¿Qué me aporto esta unidad? Me aporto mucho conocimiento, el uso de UML, me ayudara bastante cuando necesite programar un código en algún lenguaje de programación como, ya lo mencionaba antes, realizando los pasos convenientes facilitará la realización de proyectos.

Bibliografía:

https://msdn.microsoft.com/es-mx/library/dd409390.aspx http://yaqui.mxl.uabc.mx/~molguin/as/RUP.htm http://users.dcc.uchile.cl/~psalinas/uml/casosuso.html#casosuso