Metodología RUP y Metodología UML

Metodología RUP:

El proceso de desarrollo RUP (Rational Unified Process) aplica varias de las mejores practicas en el desarrollo moderno de software en una forma que se adapta a un amplio rango de proyectos y organizaciones. Provee a cada miembro del equipo, un fácil acceso a una base de conocimiento con guías., plantillas y herramientas para todas las actividades criticas del desarrollo de software. Esta metodología permite que todos los integrantes de un equipo de trabajo, conozcan y compartan el proceso de desarrollo, una base de conocimientos y los distintos modelos de cómo desarrollar el software utilizando un lenguaje modelado común: UML.

El RUP es un proceso de desarrollo de software:

Provee un enfoque estructurado para realizar tareas y responsabilidades en una organización de desarrollo. Su principal objetivo es asegurar la producción de software de alta calidad, que cumpla las necesidades de sus usuarios finales, que sea realizado en las fechas acordadas y con el presupuesto disponible.

El RUP es un producto:

IBM comercializa un producto que permite instanciar al RUP según las características del proyecto, siendo una referencia en la metodología que sirve como repositorio único de información.

El RUP es un marco de trabajo (Framework):

Este marco de trabajo puede ser adoptado y extendido para satisfacer las necesidades de la organización que lo utilice seleccionando las fases y interacciones, los flujos de trabajo y disciplinas que se van a recorrer y los entregables o productos (artifacts) que se van a construir. Es importante conocer como esta organizado y estructurado el proceso para poder seleccionar el frame work, los elementos del proceso que mas valor darán al proyecto.

El RUP incorpora muchas de las conocidas como “buenas practicas” en el desarrollo de software moderno, lasa cuáles se deben tener presentes en el desarrollo de aplicaciones empresariales para garantizar el éxito del proyecto, tales como: Desarrollo iterativo, Gestión de Requerimientos, Arquitectura basada en componentes, Modelo Visual, Verificación de la calidad en forma continua y control de cambios.

El RUP presenta 3 características que constituyen la esencia de todo el proceso de desarrollo:

1. Dirigido por los casos de uso.
2. Centrado en la arquitectura.
3. Ciclo de vida iterativo.

Otras características o ventajas de la aplicación de esta metodología son las siguientes:

• Reconoce que las necesidades del usuario y sus requerimientos no se pueden definir completamente al principio
• Permite evaluar tempranamente los riesgos en lugar de descubrir problemas en la integración final del sistema
• Reduce el costo del riesgo a los costos de un solo incremento
• Acelera el ritmo del esfuerzo de desarrollo en su totalidad debido a que los desarrolladores trabajan para obtener resultados claros a corto plazo
• Distribuye la carga de trabajo a lo largo del tiempo del proyecto ya que todas las disciplinas colaboran en cada iteración.
• Facilita la reutilización del código teniendo en cuenta que se realizan revisiones en las primeras iteraciones lo cual además permite que se aprecien oportunidades de mejoras en el diseño

El proceso de desarrollo está dividido en Fases a lo largo del tiempo cada una de las cuales tiene objetivos específicos y un conjunto de “artefactos” definidos que deben alcanzarse. La duración de cada fase depende del equipo y del producto a generar.
A su vez, cada fase puede tener una o más iteraciones y cada iteración sigue el modelo en cascada pasando por las distintas disciplinas. Cada iteración termina con una liberación del producto.

Las fases son las siguientes:

1) Inicio
2) Elaboración
3) Construcción
4) transición

Metodología UML:

La metodología que se propone, denominada UML-MAST, concilia las diferencias entre la visión del diseñador de sistemas de tiempo real y la del de sistemas orientados a objetos. A tal fin define un nivel de abstracción adecuado para los elementos de modelado del comportamiento de tiempo real, que permite formularlos con una estructura paralela a la arquitectura lógica del sistema, y vincularlos a esta. La semántica de modelado sigue el perfil UML para planificabilidad, rendimiento y tiempo (SPT) estandarizado por el OMG, del que UML-MAST puede considerase una implementación. La propuesta se integra con las herramientas de análisis y diseño de sistemas de tiempo real MAST (Modeling and Analysis Suite for Real-Time Applications), que analiza los modelos y retorna los resultados al modelo inicial para su interpretación por el diseñador. Asimismo, se han definido criterios para la extensión de esta metodología a otros niveles de abstracción tales como sistemas basados en componentes y sistemas implementados utilizando Ada 95. Parte de los resultados de este trabajo han sido incorporados por el OMG a su perfil SPT.

Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.
Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.

Arquitectura bajo capas

Link Arquitectura bajo capas:

http://docs.google.com/Presentation?id=dgvxhrnv_113hh7qgxcg

Taller 4 junio UML

Link esquema de 3 capas:

http://docs.google.com/Presentation?id=dgvxhrnv_945pvjw6cq

Link de la Exposicion de UML en ppt

Link Exposicion:

http://docs.google.com/Presentation?id=dgvxhrnv_65d4xv8fg6

Abstract

Introducción:

The following diagram will discuss components that is a component of its features, will have pictures and videos related to this type of diagram, so that from this, and know better how to deploy the system development software.

Definición, Características y Palabras Claves

Definición:

Explicación del Tema:

Un diagrama de componentes es un diagrama tipo del lenguaje unificado .Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, librerías compartidas, módulo, ejecutables, paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura del software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.

Debido a que estos son más parecidos a los diagramas de casos de usos estos son utilizados para modelar la vista estática y dinámica de un sistema. Muestra la organización y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.En él se situarán librerías, tablas, archivos, ejecutables y documentos que formen parte del sistema.Uno de los usos principales es que puede servir para ver qué componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.

Se utilizan para modelar la vista estática de un sistema. Muestra la organización y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema. En el situaremos librerías, tablas archivos, ejecutables y documentos que formen parte del sistema.Uno de los usos principales es que puede servir para ver que componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.

Aquí tenemos un componente del sistema de Windows. En el diagrama de componenetes de Windows debe salir este componente, ya que sin el sistema no funcionaría.

}

En esta otra figura tenemos el mismo componente, pero indicamos que dispone de un interface. Al ser una Dll el interface nos da acceso a su contenido. Esto nos hace pensar que la representación anterior es incorrecta, pero no es así solo corresponde a un nivel diferente de detalle. Como ya hemos indicado antes todo objeto UML puede ser modificado mediante estereotipos, los standard que define UML son:

• Executable
• Library
• Table
• File
• Document

Aunque por suerte no estamos limitados a estas especificaciones. Que pasa si queremos modelar un proyecto de Internet donde nuestros componentes son ASP, HTML, y Scripts, y queremos marcarlo en el modelo. Pues utilizamos un estereotipo. Existe ya unos definidos WAE (Web Applications Extensión).
Podemos modelar diferentes partes de nuestro sistema, y modelar diferentes entidades que no tiene nada que ver entre ellas.

• Ejecutables y bibliotecas.
• Tablas.
• API
• Código fuente.
• Hojas HTML.

Ejecutables:

Nos facilita la districución de ejecutables a los clientes. Documenta sus necesidades y dependencias. Si disponemos de un ejecutable que solo se necesita a el mismo para funcionar no necesitaremos el diagrama d ecomponentes. Los pasos a seguir para modelar, a priori no a porteriori, son:

• Indentificar los componentes, las participaciones del sistema, cuales son factibles de ser reutilizadas. Agruparlos por nodos y realizar un diagrama por cada nodo que se quiera modelar.
• Identificar cada componente con su estereotipo correspondiente.
• Considerar las relaciones entre componentes.

En este gráfico se muestra un ejecutable que utiliza dos librerías, estas dos librerías disoponen de su interface con el que ofrecen el acceso a sus servicios. Se pueden ver que estas librerías son coponentes que pueden ser reutilizados en otras partes del sistema.

Código fuente:

Se utiliza para documentar las dependencias de los diferentes ficheros de código fuente. Un ejecutable, o librería es una combinación de estos ficheros, y al mostrar la dependencia entre ellos obtenemos una visión de las partes necesarias para la creación del ejecutable o librería.
Al tener documentadas las relaciones se pueden realizar cambios en el código de un archivo teniendo en cuenta donde se utiliza, y que otros ficheros pueden verse afectados por su modificación.

Aquí tenemos la relación entre los diferentes ficheros de un sistema. Cada fichero Cpp utiliza su fichero .h correspondiente, y MiServicio.h utiliza NTService.h u Stdio.h.

Características:

1. Un componente debe tener un nombre por ejemplo (cliente o camino).
2. Un componente tiene características similares a una clase (nombre, tiene interfaces, puede participar en relaciones.
3. Representa un elemento físico en bits.
4. Representa nodos físicos.
5. Las operaciones de los componentes se alcanzan por la interface.

Palabras Claves:

• Nodos
• Componentes
• Dependencias
• Ejecutables
  

Video y Imagenes

Ventajas

Ventajas:

• Los diagramas de componentes describen los elementos físicos del sistema y sus relaciones.

• Muestran las opciones de realización incluyendo código fuente, binario y ejecutable.

• Los componentes representan todos los tipos de elementos software que entran en la fabricación de aplicaciones informáticas.

• Pueden ser simples archivos, paquetes, bibliotecas cargadas dinámicamente, etc.

Conclusiones del Grupo

Conclusiones:

1. Un componente de software es una parte física de un sistema, como puede ser un módulo, una base de datos, un programa ejecutable una biblioteca de programas, etc. Puede considerarse que un componente es la materialización de una o más clases. En efecto, las clases so conceptos -constituyen una abstracción de un conjunto de atributos y operaciones-que se implementan o materializan en los componentes.
2. Existen tres tipos de componentes los cuálesn se dividen en: distribución, trabajo y ejecución, estos tipos son de vital ayuda para la interpretación del sistema que iremos a diseñar.
3. Un componentes se representa con un rectángulo en el que se inscribe su nombre y en el que se muestran dos pequeños rectángulos en su lado izquierdo.
4. Utilizan interfaces para elaborar operaciones interconectando componentes, sus interfaces mas utilizadas son los provistos o requeridos y los utilizados.

Bibliografías

Bibliografías:

• www.dsi.uclm.es/asignaturas/42530/pdf/M2tema12.pdf

• http://tvdi.det.uvigo.es/~avilas/UML/node49.html

• http://es.wikipedia.org/wiki/Diagrama_de_componentes

• http://anteproyecto-protesis-mano-robotica.googlecode.com/files/TEORIA_11_UML_componentes%20e%20interfaces%20(buenísimo).pdf

• http://elcodigok.blogspot.com/2008/03/diagrama-de-componentes-uml.html

• http://www.google.com.co/search?hl=es&q=caracteristicas+diagrama+de+componentes&btnG=Buscar&meta=

Taller UML Casos de uso 13 de Mayo

URL de los ejercicios propuestos en clase sobre Casos de Uso: http://docs.google.com/Doc?id=dgvxhrnv_60c8swz5hd

Diseño UML

Diseño UML


Datos:

Nombre: Luis Antonio Ramírez Aranguren.
Edad: 19 años.
Dirección: Cr 3b # 32a45.
Teléfono: 245-89-29, 566-94-95 o 3124995570.
Ocupación: Aprendiz Sena

Expectativas:

Las expectativas que tengo frente al programa ADSI es lograr mis logros o metas trazadas antes de haber entrado a esta especialidad, las cuales tienen énfasis en lograr construir mi empresa de software y poder especializarme en Francia ya que por medio de lo que aprenda de los maestros en cada modulo será la base de mi evolución como empresario.

Que es UML?

UML no es un método de desarrollo. No te va a decir cómo pasar del análisis al diseño y de este al código. No son una serie de pasos que te llevan a producir código a partir de unas especificaciones.UML al no ser un método de desarrollo es independiente del ciclo de desarrollo que vayas a seguir, puede encajar en un tradicional ciclo en cascada, o en un evolutivo ciclo en espiral o incluso en los métodos ágiles de desarrollo.
Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

Su Uso:

1. Mejora nuestro nivel de comunicacion formal.


2. Abordamos la complejidad con una documentacion minimalista.


3. Desarrollamos procesos/productos con mayor fiabilidad y calidad.

Su contenido:

Dispone de:

• Repertorio de unidades (Clases, Acciones, Objetos, Estados, Casos d eUso).


• Gramática que define las reglas de combinación pra formar iotras unidades más complejas (diagramas, modelos).


• Una determinada escala de abstracción y granularidad.

Ventaja Clave:

Con un número clavereducido de elementos UML y sus reglas de combinación, es posible construir y comunicar estructuras y funcionalidad muy complejas.

La contrapartida sería una especificación textual con centenares de páginas muy difícil de mantener ante nuevos cambios.

Lo usamos para:

1. Definir un problema que afecta a una organización (análisis).
   
2. Plantear una solución de diseño (abstracción).
   
3. Modelar procesos de negocio (optimización de flujos de trabajo).


4. Construir un producto de software (concreción de una abstracción).


5. Certificar la coherencia, completitud y usabilidad del producto (calidad).
   
6. Evaluar la arquitectura de una organización (conocimiento).

Metodología:

1. Qué aspectos esenciales hay que modelar (desde un esbozo a un plano detallado).


2. Qué diagrama es el más apropiado para representar una vista del modelo (estructura y/o función).


3. En qué proceso de proyecto (Análisis, Diseño, Implementación, Testing, etc.), hay que realizar un determinado diagrama, y quién participará en su elaboración (Roles de proyecto).
   
4. Qué escala de abstracción y qué nivel de dedicación hay que aplicar a un diagrama en cada fase de proyecto (desde el estudio preliminar en adelante).


5. Cómo definimos un modelo a través de distintas vistas de arquitectura: estructura, procesos y Casos de Uso.


6. Cómo delimitamos el alcance de un proyecto en tiempo, coste, procesos y producto resultante.

Unidades básicas de UML:

• Estructura:

Define básicamente tipos de objetos (Clases) con sus atributos (qué conocen), sus responsabilidades (qué puede hacer) y su nivel de visibilidad (con quién puede relacionarse).

• Función:

Expresan acciones y procesos como resultado de los objetos en un escenario acotado (eventos), y modelan la sucesión de estados que transcurren a lo largo del ciclo de vida de un objeto.

• Conectores:

Definen las categorías de relación entre Clases, objetos, acciones, procesos, estados y la trazabilidad entre todas las unidades de estructura y función.

Diagramas UML existentes:

• Diagrama de Paquetes.
• Diagrama de Casos de Uso.
• Diagrama de Actividad.
• Diagrama de Secuencia.
• Diagrama de Comunicación.
• Diagrama de Estados.
• Diagrama de Despliegue.
• Diagrama de Componentes.
• Diagrama de Objetos.
• Diagrama de Clases.

Metodologías del desarrollo del sistema:

1. Requerimientos. (Modelo Casos de Uso)


2. Análisis. (Modelo Análisis)


3. Diseño. (Modelo Diseño, Modelo Componentes)


4. Implementación. (Modelo de Despliegue)
   
5. Testing. (Modelo de Certificación).

Para qué sirve UML:

• Sirve para representar visualmente las reglas de creación, estructua y comportamiento de un grupo relacionado de objetos y procesos.

• Para visualizar de manera eficiente la complejidad del sistema o una organizacion en un reducido número de diagramas.

• Para mantener más agilmente las especificaciones ante los cambios y nuevos enfoques de arquitectura.

Que un Caso de Uso?

Un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas.

Ejemplo Caso de Uso:

Para que sirve un Caso de Uso:

Sirve para describir la funcionalidad de un sistema, no son diagramas de flujo, estan compuestos por 4 elementos: Los actores con los cuales interactua el sistema, el sistema mismo, los casos de uso o servicios que el sistema ejecutará y las relaciones entre estos elementos.

Ventajas de los Casos de Uso:

La técnica de caso de uso tiene éxito en sistemas interactivos, ya que expresa la intención que tiene el actor (su usuario) al hacer uso del sistema.
Como técnica de extracción de requerimiento permite que el analista se centre en las necesidades del usuario, qué espera éste lograr al utilizar el sistema, evitando que la gente especializada en informática dirija la funcionalidad del nuevo sistema basándose solamente en criterios tecnológicos.
A su vez, durante la extracción (elicitation en inglés), el analista se concentra en las tareas centrales del usuario describiendo por lo tanto los casos de uso que mayor valor aportan al negocio. Esto facilita luego la priorización del requerimiento.

Desvantajas:

Los casos de uso pueden ser útiles para establecer requisitos de comportamiento, pero no establecen completamente los requisitos funcionales ni permiten determinar los requisitos no funcionales. Los casos de uso deben complementarse con información adicional como reglas de negocio, requisitos no funcionales, diccionario de datos que complementen los requerimientos del sistema. Sin embargo la ingeniería del funcionamiento especifica que cada caso crítico del uso debe tener un requisito no funcional centrado en el funcionamiento asociado.

Normas de aplicación:

Los casos de uso evitan típicamente la jerga técnica, prefiriendo la lengua del usuario final o del experto del campo del saber al que se va a aplicar. Los casos del uso son a menudo elaborados en colaboración por los ingenieros de requisitos y los clientes.
Cada caso de uso se centra en describir cómo alcanzar una única meta o tarea de negocio. Desde una perspectiva tradicional de la ingeniería de software, un caso del uso describe una característica del sistema. Para la mayoría de proyectos de software, esto significa que quizás a veces es necesario especificar diez o centenares de casos de uso para definir completamente el nuevo sistema. El grado de la formalidad de un proyecto particular del software y de la etapa del proyecto influenciará el nivel del detalle requerido en cada caso de uso.
Los casos de uso pretenden ser herramientas simples para describir el comportamiento del software o de los sistemas. Un caso del uso contiene una descripción textual de todas las maneras que los actores previstos podrían trabajar con el software o el sistema. Los casos del uso no describen ninguna funcionalidad interna (oculta al exterior) del sistema, ni explican cómo se implementará. Simplemente muestran los pasos que el actor sigue para realizar una tarea.

Un caso de uso debe:
Describir una tarea del negocio que sirva a una meta de negocio.
Tener un nivel apropiado del detalle.
Ser bastante sencillo como que un desarrollador lo elabore en un único lanzamiento.

Situaciones que pueden darse:
Un actor se comunica con un caso de uso (si se trata de un actor primario la comunicación la iniciará el actor, en cambio si es secundario, el sistema será el que inicie la comunicación).
Un caso de uso extiende otro caso de uso.
Un caso de uso usa otro caso de uso.

Símbolos del Caso de Uso:

Ejemplo de un Caso de Uso visto desde la interfaz del usuario (Registrarse como usuario):

Direccion URL de los primeros 5 casos de uso:http://docs.google.com/Doc?id=dgvxhrnv_50ff7mzwc6

Direccion URL formato de casos de uso:

http://docs.google.com/Doc?id=dgvxhrnv_34dg5x3www