Diseño y Modelación de un Proyecto de Software Utilizando el lenguaje UML

2. Descripción
3. Objetivos
4. Alcance
5. Justificación
6. Metodología
7. Historia del UML
8. Qué es UML?
9. Elementos Estructurales
10. Elementos de comportamiento
11. Elementos de agrupación
12. Elementos de anotación
13. Arquitectura
14. Ciclo de Vida
15. Caso Práctico
16. Diagramas y Descripción de Casos de Uso
17. Flujo Básico y Flujo alterno de los Sub Casos de Uso

INTRODUCCION

Desde los inicios de la informática se han estado utilizando distintas formas de representar los diseños de una manera más bien personal o con algún modelo gráfico, La falta de estandarización en la representación gráfica de un modelo impedía que los diseños gráficos realizados se pudieran compartir fácilmente entre distintos diseñadores, con este objetivo se creo el Lenguaje Unificado de Modelado (UML: Unified Modeling Language).

UML es el lenguaje de modelado de sistemas de software más conocido en la actualidad; es el estándar internacional aprobado por la OMG (Object Managment Group), consorcio creado en 1989 responsable de la creación, desarrollo y revisión de especificaciones para la industrial del software.

UML son un grupo de especificaciones de notación orientadas a Objeto, las cuales están compuesta por distintos diagramas, que representan las diferentes etapas del desarrollo de un proyecto de software. Este trabajo se centra en un Sistema de Control de Citas Médicas. Se han usados varios de los diagramas de UML, de modo que se muestre el uso de los mismos, enfocado desde una perspectiva práctica.

DESCRIPCION

El lenguaje UML comenzó a gestarse en octubre de 1994, cuando Rumbaugh se unió a la compañía Rational fundada por Booch (dos reputados investigadores en el área de metodología del software). El objetivo de amb os era unificar dos métodos que habían desarrollado: el método Booch y el OMT (Object Modelling Tool). El primer borrador apareció en octubre de 1995. En esa misma época otro reputado investigador, Jacobson, se unió a Rational y se incluyeron ideas suyas. Estas tres personas son conocidas como los "tres amigos". Además, este lenguaje se abrió a la colaboración de otras empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron a la definición de la primera versión de UML.

1. Modelado: es el diseño de un software antes de su codificación, es la visualización de lo que se quiere construir.

Esta primera versión se ofreció a un grupo de trabajo para convertirlo en 1997 en un estándar del OMG. Este grupo gestiona estándares relacionados con la tecnología orientada a objetos (metodologías, bases de datos objetuales, CORBA, etc.), propuso una serie de modificaciones y una nueva versión de UML (la 1.1), que fue adoptada por el OMG como estándar en noviembre de 1997. Desde aquella versión han habido varias revisiones que gestiona la OMG Revision Task Force. La última versión aprobada es la UML 2.0 superstructure. En estos momentos se está desarrollando actualizaciones a esta versión en la que se incluirán cambios importantes (principalmente añadir nuevos diagramas).

OBJETIVOS GENERALES

• Desarrollar el diseño y modelación de un Sistema de Control de Citas Médicas utilizando el lenguaje UML.
• Impulsar el acercamiento hacia una nueva manera de entender el diseño de software basado en UML.

OBJETIVOS ESPECIFICOS

• Estudiar el lenguaje de Modelado UML.
• Desarrollar por completo el diseño de un proyecto de software con el fin de comprender todo el proceso.
• Identificar en el diseño del proyecto los distintos tipos de diagramas que existen como son los:

• Diagramas de clases
• Casos de usos
• Paquetes
• Diagramas de interacción y secuencia, y los diagramas de transición de estados

• Aplicar patrones de diseño modernos para la construcción de una aplicación de software utilizando para ello la herramienta Rational Rose.
• Mostrar como UML crea un protocolo de comunicación estándar entre los desarrolladores.

ALCANCE

El trabajo presentado a continuación es un estudio sobre el Lenguaje de Modelado que abarca desde la definición de sus conceptos hasta su aplicación en un ejemplo práctico, en el mismo veremos como UML nos permite experimentar y visualizar un sistema que aun no ha sido codificado.

Este trabajo contiene la siguiente documentación:

• Diseño de Sistema utilizando UML
• • Historia del UML
  • Que es UML
  • Bloques de Construcción UML
  • • Elementos Estructurales
    • Elementos de comportamiento
    • Elementos de agrupación
    • Elementos de anotación
    • Relaciones
    • Diagramas
• Caso Practico de un Diseño de Software utilizando UML (Sistema de Control de Citas Medicas)
• • Definición de los requerimientos del sistema.
  • Los diagramas de casos y subcasos de uso.
  • La descripción de los casos de uso.
  • Diagrama de Estructura Estática (de Clases).
  • Diagrama de Interacción.

Este trabajo solamente incluye la codificación del modulo de paciente, con el fin de mostrar como se lleva a un lenguaje particular el diseño que se ha realizado en UML.

JUSTIFICACION

Standish Group, CHAOS Report nos muestra en su estudio del 2002 que el 26% de los proyectos de software son exitosos, lo que quiere decir que el 74% fallan. La razón básica por la que fallan los proyectos se determina en la etapa de análisis y diseño del sistema.

Entendiendo lo anterior, podemos decir que es necesario y obligatorio el mejorar la calidad del desarrollo de software y para esto debemos adoptar procedimientos, metodologías y herramientas que permitan una estandarización en la ingeniería de software, esto es precisamente lo que ofrecen los lenguajes de modelado de software, un lenguaje común que permite el crear una disciplina con estándares como existe en la ingeniería civil, ingeniería eléctrica, etc.

Siendo UML el estándar internacional para el modelado hemos decidido el desarrollar este tema para este proyecto, veamos algunos de los beneficios que ofrece UML:

• Contaremos con un mejor entendimiento del riesgo del proyecto antes de construir el sistema
• Mejores tiempos totales de desarrollo (de 50% o mas)
• Podremos especificar la estructura y el comportamiento del sistema y comunicarlo a todos los integrantes del proyecto
• Se documentarán las decisiones de la arquitectura del proyecto
• Se obtendrá el "plano" del sistema
• Mejor soporte a la planeación y al control del proyecto
• Un aumento en la calidad del desarrollo
• Reducción en los costos económicos

Estas son algunas de las razones por la cual es necesario adoptar UML como lenguaje de modelado, otra razón importante es el hecho de que muchas compañías a la hora de contratar servicios de desarrollo exigen que el lenguaje de modelado utilizado sea UML.

METODOLOGÍA

Tarea 1. Documentación: En esta etapa se realizarán consultas bibliográficas relacionadas con el análisis y diseño de sistemas de información con UML, a los fines de elaborar un manual de UML con sus diagramas, definición y ejemplos.

Tarea 2. Análisis de requerimientos: En esta etapa se busca la necesidad del usuario y la forma en que se va a presentar la solución.

Actividades:

• Identificar Casos de Uso del sistema
• Dar detalle a los casos de uso descritos
• Definir una interfaz inicial del sistema
• Desarrollar el Diagramas necesarios
• Desarrollar Diccionario de Datos

Tarea 3. Diseño del sistema: en esta etapa se define una subdivisión del sistema por funciones y la forma de comunicación para su interacción.

Actividades:

• Identificar la arquitectura del sistema
• 1. Definir los componentes del sistema
  2. Refinar los casos de uso (textualmente y en diagrama)

  Tarea 4. Diseño detallado: en esta etapa se adecuará el análisis a las características específicas del software.

  Actividades:

• Agregar detalles de implementación al modelo del mundo
• Desarrollar el modelo de interfaz
• Desarrollar los modelos de control, persistencia y comunicación

Medios y Materiales a utilizar:

• Hardware
• • Computador Pentium bajo Windows XP.
• Software
• • Rational Rose(Software para el modelado)

Historia del UML

La notación UML se deriva y unifica las tres metodologías de análisis y diseño Orientada a Objeto más extendidas:

• Metodología de Grady Booch para la descripción de conjuntos de objetos y sus relaciones.
• Técnica de modelado orientada a objetos de James Rumbaugh (OMT: Object-Modeling Technique).
• Aproximación de Ivar Jacobson (OOSE: Object- Oriented Software Engineering) mediante la metodología de casos de uso (use case).

El desarrollo de UML comenzó a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation empezaron a unificar sus métodos. A finales de 1995, Ivar Jacobson y su compañía Objectory se incorporaron a Rational en su unificación, aportando el método OOSE.

De las tres metodologías de partida, las de Booch y Rumbaugh pueden ser descritas como centradas en objetos, ya que sus aproximaciones se enfocan hacia el modelado de los objetos que componen el sistema, su relación y colaboración. Por otro lado, la metodología de Jacobson es más centrada a usuario, ya que todo en su método se deriva de los escenarios de uso. UML se ha ido fomentando y aceptando como estándar desde el OMG que es también el origen de CORBA, el estándar líder en la industria para la programación de objetos distribuidos. En 1997 UML 1.1 fue aprobada por la OMG convirtiéndose en la notación estándar de facto para el análisis y el diseño orientado a objetos.

Qué es UML?

UML es el primer método en publicar un meta-modelo en su propia notación, incluyendo la notación para la mayoría de la información de requisitos, análisis y diseño. Se trata pues de un meta-modelo auto-referencial (cualquier lenguaje de modelado de propósito general debería ser capaz de modelarse a sí mismo).

UML es un lenguaje estándar que sirve para escribir los planos del software, puede utilizarse para visualizar, especificar, construir y documentar todos los artefactos que componen un sistema con gran cantidad de software. UML puede usarse para modelar desde sistemas de información hasta aplicaciones distribuidas basadas en Web, pasando por sistemas empotrados de tiempo real.

UML es solamente un lenguaje por lo que es sólo una parte de un método de desarrollo software, es independiente del proceso aunque para que sea optimo debe usarse en un proceso dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental.

UML es un lenguaje por que proporciona un vocabulario y las reglas para utilizarlo, además es un lenguaje de modelado lo que significa que el vocabulario y las reglas se utilizan para la representación conceptual y física del sistema.

UML es un lenguaje que nos ayuda a interpretar grandes sistemas mediante gráficos o mediante texto obteniendo modelos explícitos que ayudan a la comunicación durante el desarrollo ya que al ser estándar, los modelos podrán ser interpretados por personas que no participaron en su diseño (e incluso por herramientas) sin ninguna ambigüedad. En este contexto, UML sirve para especificar, modelos concretos, no ambiguos y completos.

Debido a su estandarización y su definición completa no ambigua, y aunque no sea un lenguaje de programación, UML se puede conectar de manera directa a lenguajes de programación como Java, C++ o Visual Basic, esta correspondencia permite lo que se denomina como ingeniería directa (obtener el código fuente partiendo de los modelos) pero además es posible reconstruir un modelo en UML partiendo de la implementación, o sea, la ingeniería inversa.

UML proporciona la capacidad de modelar actividades de planificación de proyectos y de sus versiones, expresar requisitos y las pruebas sobre el sistema, representar todos sus detalles así como la propia arquitectura. Mediante estas capacidades se obtiene una documentación que es valida durante todo el ciclo de vida de un proyecto.

El lenguaje UML se compone de tres elementos básicos, los bloques de construcción, las reglas y algunos mecanismos comunes. Estos elementos interaccionan entre sí para dar a UML el carácter de completitud y no-ambigüedad que antes comentábamos.

Los bloques de construcción se dividen en tres partes:

• Elementos, que son las abstracciones de primer nivel.
• Relaciones, que unen a los elementos entre sí.
• Diagramas, que son agrupaciones de elementos.

Existen cuatro tipos de elementos en UML, dependiendo del uso que se haga de ellos:

• Elementos estructurales.
• Elementos de comportamiento.
• Elementos de agrupación
• Elementos de anotación.

Las relaciones, a su vez se dividen para abarcar las posibles interacciones entre elementos que se nos pueden presentar a la hora de modelar usando UML, estas son: relaciones de dependencia, relaciones de asociación, relaciones de generalización y relaciones de realización.

Se utilizan diferentes diagramas dependiendo de qué, nos interese representar en cada momento, para dar diferentes perspectivas de un mismo problema, para ajustar el nivel de detalle…, por esta razón UML soporta un gran numero de diagramas diferentes aunque, en la practica, sólo se utilicen un pequeño número de combinaciones.

UML proporciona un conjunto de reglas que dictan las pautas a la hora de realizar asociaciones entre objetos para poder obtener modelos bien formados, estas son reglas semánticas que afectan a los nombres, al alcance de dichos nombres, a la visibilidad de estos nombres por otros, a la integridad de unos elementos con otros y a la ejecución, o sea la vista dinámica del sistema.

UML proporciona una serie de mecanismos comunes que sirven para que cada persona o entidad adapte el lenguaje a sus necesidades, pero dentro de un marco ordenado y siguiendo unas ciertas reglas para que en el trasfondo de la adaptación no se pierda la semántica propia de UML. Dentro de estos mecanismos están las especificaciones, que proporcionan la explicación textual de la sintaxis y semántica de los bloques de construcción.

Otro mecanismo es el de los adornos que sirven para conferir a los modelos de más semántica, los adornos son elementos secundarios ya que proporcionan más nivel de detalle, que quizá en un primer momento no sea conveniente descubrir. Las divisiones comunes permiten que los modelos se dividan al menos en un par de formas diferentes para facilitar la comprensión desde distintos puntos de vista, en primer lugar tenemos la división entre clase y objeto (clase es una abstracción y objeto es una manifestación de esa abstracción), en segundo lugar tenemos la división interfaz / implementación donde la interfaz presenta un contrato (algo que se va a cumplir de una determinada manera) mientras que la implementación es la manera en que se cumple dicho contrato.

Por ultimo, los mecanismos de extensibilidad que UML proporciona sirven para evitar posibles problemas que puedan surgir debido a la necesidad de poder representar ciertos matices, por esta razón UML incluye los estereotipos, para poder extender el vocabulario con nuevos bloques de construcción, los valores etiquetados, para extender las propiedades un bloque, y las restricciones, para extender la semántica. De esta manera UML es un lenguaje estándar "abierto-cerrado" siendo posible extender el lenguaje de manera controlada.

Elementos Estructurales

Los elementos estructurales en UML, es su mayoría, son las partes estáticas del modelo y representan cosas que son conceptuales o materiales.

Clases

Una clase es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Una clase implementa una o más interfaces. Gráficamente se representa como un rectángulo que incluye su nombre, sus atributos y sus operaciones.

Interfaz

Una interfaz es una colección de operaciones que especifican un servicio de una determinada clase o componente. Una interfaz describe el comportamiento visible externamente de ese elemento, puede mostrar el comportamiento completo o sólo una parte del mismo. Una interfaz describe un conjunto de especificaciones de operaciones (o sea su signatura) pero nunca su implementación. Se representa con un circulo, , y rara vez se encuentra aislada sino que más bien conectada a la clase o componente que realiza.

Colaboración

Define una interacción y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos. Las colaboraciones tienen una dimensión tanto estructural como de comportamiento. Una misma clase puede participar en diferentes colaboraciones. Las colaboraciones representan la implementación de patrones que forman un sistema. Se representa mediante una elipse con borde discontinuo.

Casos de Uso

Un caso de uso es la descripción de un conjunto de acciones que un sistema ejecuta y que produce un determinado resultado que es de interés para un actor particular. Un caso de uso se utiliza para organizar los aspectos del comportamiento en un modelo. Un caso de uso es realizado por una colaboración. Se representa como en la figura 6, una elipse con borde continuo.

Clase Activa

Es una clase cuyos objetos tienen uno o más procesos o hilos de ejecución por lo y tanto pueden dar lugar a actividades de control. Una clase activa es igual que una clase, excepto que sus objetos representan elementos cuyo comportamiento es concurrente con otros elementos. Se representa igual que una clase, pero con líneas más gruesas

Componentes

Un componente es una parte física y reemplazable de un sistema que conforma con un conjunto de interfaces y proporciona la implementación de dicho conjunto. Un componente representa típicamente el empaquetamiento físico de diferentes elementos lógicos, como clases, interfaces y colaboraciones.

Nodos

Un nodo es un elemento físico que existe en tiempo de ejecución y representa un recurso

computacional que, por lo general, dispone de algo de memoria y, con frecuencia, de capacidad de procesamiento. Un conjunto de componentes puede residir en un nodo.

Estos siete elementos vistos son los elementos estructurales básico que se pueden incluir en un modelo UML. Existen variaciones sobre estos elementos básicos, tales como actores, señales, utilidades (tipos de clases), procesos e hilos (tipos de clases activas) y aplicaciones, documentos, archivos, bibliotecas, páginas y tablas (tipos de componentes).

Elementos de comportamiento

Los elementos de comportamiento son las partes dinámicas de un modelo. Se podría decir que son los verbos de un modelo y representan el comportamiento en el tiempo y en el espacio. Los principales elementos son los dos que siguen.

Interacción

Es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular para conseguir un propósito específico. Una interacción involucra otros muchos elementos, incluyendo mensajes, secuencias de acción (comportamiento invocado por un objeto) y enlaces (conexiones entre objetos). La representación de un mensaje es una flecha dirigida que normalmente con el nombre de la operación.

Maquinas de estados

Es un comportamiento que especifica las secuencias de estados por las que van pasando los objetos o las interacciones durante su vida en respuesta a eventos, junto con las respuestas a esos eventos. Una maquina de estados involucra otros elementos como son estados, transiciones (flujo de un estado a otro), eventos (que disparan una transición) y actividades (respuesta de una transición)

Elementos de agrupación

Forman la parte organizativa de los modelos UML. El principal elemento de agrupación es el paquete, que es un mecanismo de propósito general para organizar elementos en grupos. Los elementos estructurales, los elementos de comportamiento, incluso los propios elementos de agrupación se pueden incluir en un paquete.

Un paquete es puramente conceptual (sólo existe en tiempo de desarrollo). Gráficamente se representa como una carpeta conteniendo normalmente su nombre y, a veces, su contenido.

Elementos de anotación

Los elementos de anotación son las partes explicativas de los modelos UML. Son comentarios que se pueden aplicar para describir, clasificar y hacer observaciones sobre cualquier elemento de un modelo.

El tipo principal de anotación es la nota que simplemente es un símbolo para mostrar restricciones y comentarios junto a un elemento o un conjunto de elementos.

Relaciones

Existen cuatro tipos de relaciones entre los elementos de un modelo UML. Dependencia, asociación, generalización y realización, estas se describen a continuación:

Dependencia

Es una relación semántica entre dos elementos en la cual un cambio a un elemento (el elemento

independiente) puede afectar a la semántica del otro elemento (elemento dependiente). Se representa como una línea discontinua, posiblemente dirigida, que a veces incluye una etiqueta.

Asociación

Es una relación estructural que describe un conjunto de enlaces, los cuales son conexiones entre objetos. La agregación es un tipo especial de asociación y representa una relación estructural entre un todo y sus partes. La asociación se representa con una línea continua, posiblemente dirigida, que a veces incluye una etiqueta. A menudo se incluyen otros adornos para indicar la multiplicidad y roles de los objetos involucrados.

Generalización

Es una relación de especialización / generalización en la cual los objetos del elemento especializado (el hijo) pueden sustituir a los objetos del elemento general (el padre). De esta forma, el hijo comparte la estructura y el comportamiento del padre. Gráficamente, la generalización se representa con una línea con punta de flecha vacía.

Realización

Es una relación semántica entre clasificadores, donde un clasificador especifica un contrato que otro clasificador garantiza que cumplirá. Se pueden encontrar relaciones de realización en dos sitios: entre interfaces y las clases y componentes que las realizan, y entre los casos de uso y las colaboraciones que los realizan. La realización se representa como una mezcla entre la generalización y la dependencia, esto es, una línea discontinua con una punta de flecha vacía .

Diagramas

Los diagramas se utilizan para representar diferentes perspectivas de un sistema de forma que un diagrama es una proyección del mismo. UML proporciona un amplio conjunto de diagramas que normalmente se usan en pequeños subconjuntos para poder representar las cinco vistas principales de la arquitectura de un sistema.

Diagramas de Clases

Muestran un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. Estos diagramas son los más comunes en el modelado de sistemas orientados a objetos y cubren la vista de diseño estática o la vista de procesos estática (sí incluyen clases activas).

Diagrama de Clases

Ejemplo de Diagrama de Clases

Diagramas de Objetos

Muestran un conjunto de objetos y sus relaciones, son como fotos instantáneas de los diagramas de clases y cubren la vista de diseño estática o la vista de procesos estática desde la perspectiva de casos reales o prototípicos.

Diagramas de Casos de Usos

Muestran un conjunto de casos de uso y actores (tipo especial de clases) y sus relaciones. Cubren la vista estática de los casos de uso y son especialmente importantes para el modelado y organización del comportamiento.

Diagramas de Secuencia y de Colaboración

Tanto los diagramas de secuencia como los diagramas de colaboración son un tipo de diagramas de interacción. Constan de un conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar unos objetos a otros. Cubren la vista dinámica del sistema. Los diagramas de secuencia enfatizan el ordenamiento temporal de los mensajes mientras que los diagramas de colaboración muestran la organización estructural de los objetos que envían y reciben mensajes. Los diagramas de secuencia se pueden convertir en diagramas de colaboración sin perdida de información, lo mismo ocurren en sentido opuesto.

Diagramas de Estados

Muestran una maquina de estados compuesta por estados, transiciones, eventos y actividades. Estos diagramas cubren la vista dinámica de un sistema y son muy importantes a la hora de modelar el comportamiento de una interfaz, clase o colaboración.

Diagramas de Actividades

Son un tipo especial de diagramas de estados que se centra en mostrar el flujo de actividades dentro de un sistema. Los diagramas de actividades cubren la parte dinámica de un sistema y se utilizan para modelar el funcionamiento de un sistema resaltando el flujo de control entre objetos.

Diagramas de Componentes

Muestra la organización y las dependencias entre un conjunto de componentes. Cubren la vista de la implementación estática y se relacionan con los diagramas de clases ya que en un componente suele tener una o más clases, interfaces o colaboraciones

Diagramas de Despliegue

Representan la configuración de los nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos. Muestran la vista de despliegue estática de una arquitectura y se relacionan con los componentes ya que, por lo común, los nodos contienen uno o más componentes.

Diagrama de Despliegue

Arquitectura

El desarrollo de un sistema con gran cantidad de software requiere que este sea visto desde diferentes perspectivas. Diferentes usuarios (usuario final, analistas, desarrolladores, integradores, jefes de proyecto…) siguen diferentes actividades en diferentes momentos del ciclo de vida del proyecto, lo que da lugar a las diferentes vistas del proyecto, dependiendo de qué interese más en cada instante de tiempo.

La arquitectura es el conjunto de decisiones significativas sobre:

• La organización del sistema
• Selección de elementos estructurales y sus interfaces a través de los cuales se constituye el sistema.
• El Comportamiento, como se especifica las colaboraciones entre esos componentes.
• Composición de los elementos estructurales y de comportamiento en subsistemas

progresivamente más grandes.

• El estilo arquitectónico que guía esta organización: elementos estáticos y dinámicos y sus interfaces, sus colaboraciones y su composición.

La una arquitectura que no debe centrarse únicamente en la estructura y en el comportamiento, sino que abarque temas como el uso, funcionalidad, rendimiento, capacidad de adaptación, reutilización, capacidad para ser comprendida, restricciones, compromisos entre alternativas, así como aspectos estéticos. Para ello se sugiere una arquitectura que permita describir mejor los sistemas desde diferentes vistas, donde cada una de ellas es una proyección de la organización y la estructura centrada en un aspecto particular del sistema.

La vista de casos de uso comprende la descripción del comportamiento del sistema tal y como es percibido por los usuarios finales, analistas y encargados de las pruebas y se utilizan los diagramas de casos de uso para capturar los aspectos estáticos mientras que los dinámicos son representados por diagramas de interacción, estados y actividades.

La vista de diseño comprende las clases, interfaces y colaboraciones que forman el vocabulario del problema y de la solución. Esta vista soporta principalmente los requisitos funcionales del sistema, o sea, los servicios que el sistema debe proporcionar. Los aspectos estáticos se representan mediante diagramas de clases y objetos y los aspectos dinámicos con diagramas de interacción, estados y actividades.

La vista de procesos comprende los hilos y procesos que forman mecanismos de sincronización y concurrencia del sistema cubriendo el funcionamiento, capacidad de crecimiento y el rendimiento del sistema. Con UML, los aspectos estáticos y dinámicos se representan igual que en la vista de diseño, pero con el énfasis que aportan las clases activas, las cuales representan los procesos y los hilos.

La Vista de implementación comprende los componentes y los archivos que un sistema utiliza para ensamblar y hacer disponible el sistema físico. Se ocupa principalmente de la gestión de configuraciones de las distintas versiones del sistema. Los aspectos estáticos se capturan con los diagramas de componentes y los aspectos dinámicos con los diagramas de interacción, estados y actividades.

La vista de despliegue de un sistema contiene los nodos que forman la topología hardware sobre la que se ejecuta el sistema. Se preocupa principalmente de la distribución, entrega e instalación de las partes que constituyen el sistema. Los aspectos estáticos de esta vista se representan mediante los diagramas de despliegue y los aspectos dinámicos con diagramas de interacción, estados y actividades

Ciclo de Vida

Se entiende por ciclo de vida de un proyecto software a todas las etapas por las que pasa un proyecto, desde la concepción de la idea que hace surgir la necesidad de diseñar un sistema software, pasando por el análisis, desarrollo, implantación y mantenimiento del mismo y hasta que finalmente muere por ser sustituido por otro sistema.

Aunque UML es bastante independiente del proceso, para obtener el máximo rendimiento de UML se debería considerar un proceso que fuese:

Dirigido por los casos de uso, o sea, que los casos de uso sean un artefacto básico para

establecer el comportamiento del deseado del sistema, para validar la arquitectura, para las

pruebas y para la comunicación entre las personas involucradas en el proyecto.

Centrado en la arquitectura de modo que sea el artefacto básico para conceptuar, construir, gestionar y hacer evolucionar el sistema.

Un proceso iterativo, que es aquel que involucra la gestión del flujo de ejecutables del

sistema, e incremental, que es aquel donde cada nueva versión corrige defectos de la anterior e incorpora nueva funcionalidad. Un proceso iterativo e incremental se denomina dirigido por el riesgo, lo que significa que cada nueva versión se ataca y reducen los riesgos más significativos para el éxito del proyecto.

Este proceso, dirigido a los casos de uso, centrado en la arquitectura, iterativo e incremental pude descomponerse en fases, donde cada fase es el intervalo de tiempo entre dos hitos importantes del proceso, cuando se cumplen los objetivos bien definidos, se completan los artefactos y se toman decisiones sobre si pasar o no a la siguiente fase.

En el ciclo de vida de un proyecto software existen cuatro fases. La iniciación, que es cuando la idea inicial está lo suficientemente fundada para poder garantizar la entrada en la fase de elaboración, esta fase es cuando se produce la definición de la arquitectura y la visión del producto. En esta fase se deben determinar los requisitos del sistema y las pruebas sobre el mismo.

Posteriormente se pasa a la fase de construcción, que es cuando se pasa de la base arquitectónica ejecutable hasta su disponibilidad para los usuarios, en esta fase se reexaminan los requisitos y las pruebas que ha de soportar. La transición, cuarta fase del proceso, que es cuando el software se pone en mano de los usuarios. Raramente el proceso del software termina en la etapa de transición, incluso durante esta fase el proyecto es continuamente reexaminado y mejorado erradicando errores y añadiendo nuevas funcionalidades no contempladas.

Un elemento que distingue a este proceso y afecta a las cuatro fases es una iteración, que es un conjunto bien definido de actividades, con un plan y unos criterios de evaluación, que acaban en una versión del producto, bien interna o externa.

Caso Práctico

Requerimientos

Diagramas de Casos de Uso

Descripción de Casos de Uso