Diagramas de Componentes

UML define cinco estereotipos estándar que se aplican a los componentes:

• Executable: Especifica un componente que se puede ejecutar en un nodo. Library: Especifica una biblioteca de objetos estática o dinámica.
• Table: Especifica un componente que representa una tabla de una base de datos.
• File: Especifica un componente que representa un documento que contiene código fuente o datos.
• Document: Especifica un componente que representa un documento

Dependencias entre componentes


Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente se refiere a los servicios ofrecidos por otro componente.

Subsistemas


• Los distintos componentes pueden agruparse en paquetes según un criterio lógico y con vistas a simplificar la implementación
• Son paquetes estereotipados en <subsistemas>
• Los subsistemas organizan la vista de realización de un sistema
• Cada subsistema puede contener componentes y otros subsistemas
• La descomposición en subsistemas no es necesariamente una descomposición funcional
• La relación entre paquetes y clases en el nivel lógico es el queexiste entre subsistemas y componentes en el nivel físico
• Paquetes (Categorias) y clases en el nivel lógico. Paquetes (Subsistemas) y componentes en el nivel físico

El desarrollo orientado a objeto está muy relacionado con el desarrollo basado en componentes, en el sentido de que las clases con sus propiedades de encapsulación y abstracción se ven en muchas ocasiones como componentes cerrados de un sistema.  Así pues, la notación UML incluye un diagrama de componentes que según la definición del OMG “muestra las dependencias entre componentes software, incluyendo los clasificadores que los especifican (por ejemplo las clases de implementación) y los artefactos que los implementan, como los ficheros fuente, binarios, scripts, etc.”.

En muchos casos en los que podrían usarse diagramas de componentes, se usan los diagramas de despliegue (que veremos más adelante), ya que éstos nos permiten modelar además dónde va a implantarse cada componente y bajo qué configuración o parámetros. Así pues, el diagrama de componentes ha quedado tradicionalmente relegado a modelar la arquitectura del sistema a nivel lógico o de entorno de negocio

Finalmente, la lista de buenas prácticas en la representación de componentes es la siguiente:

• Aplicar los estereotipos de forma consistente.

• Aunque usemos UML 1.5, la representación de las interfaces de los componentes mediante círculos es mucho más clara que una simple flecha entre ellos.

• Ya que la interfaz es un conjunto de métodos, intentemos no representar demasiadas interfaces, es aconsejable agruparlas bajo un mismo nombre y crear después un diagrama detallado del componente.

• Los componentes pueden heredar unos de otros. En este caso, la flecha que utilizamos en los casos de uso para expresar generalización puede servir perfectamente.

• Para mejorar la comprensión de un diagrama de componentes, es preferible conectarlos siempre a través de interfaces. Es más consistente y evita confusiones o dudas sobre su interpretación.

Fuentes:

UOC Formación de posgrado. Software libre. Ingeniería del software en entornos de SL. Marzo (2005). Marc Gibert Ginestà, Álvaro Peña González. Recuperado el 20 de Noviembre 2011, de http://www.sw-computacion.f2s.com/Linux/009-Ingenieria_del_software.pdf

Ingeniería de Software. Modelo de implementación: Diagrama de componentes y despliegue. Recuperado el 20 de Noviembre 2011, de http://www.dsi.uclm.es/asignaturas/42530/pdf/M2tema12.pdf

Diagrama de Secuencia

Diagramas de Secuencia

Los diagramas de secuencia modelan el flujo de la lógica dentro del sistema de forma visual, permitiendo documentarla y validarla. Pueden usarse tanto en análisis como en diseño, proporcionando una buena base para identificar el comportamiento del sistema.

Típicamente se usan para modelar los escenarios de uso del sistema, describiendo de qué formas puede usarse. La secuencia puede expresar tanto un caso de uso completo como quizá un caso concreto del mismo contemplando algunas alternativas.

También son una buena herramienta para explorar la lógica de una operación compleja o los elementos implicados en la prestación de un servicio. Nos pueden ayudar a identificar cuellos de botella en la fase de diseño, detectar cuáles van a ser las clases más complejas de implementar y decidir cuáles de ellas van a necesitar diagramas de estados (que veremos más adelante) para facilitar su implementación.
Se componen de los siguientes elementos:
• Objeto: instancia de una clase que podemos empezar a identificar como participante en la secuencia de operaciones que representa este caso de uso.
• Actor: los actores pueden comunicarse con los objetos, por lo tanto formarán parte de este diagrama.
• Vida del objeto: indicamos la existencia de un objeto a lo largo
del tiempo mediante una línea discontinua. El fin del mismo se indica mediante un aspa.
• Activación: indicamos cuándo el objeto está realizando una tarea concreta.
• Mensaje: la comunicación entre objetos y sus activaciones.

Una de las características de los diagramas de secuencia es que casi no necesitan aclaraciones en cuanto a su notación. En la parte superior, vemos los participantes en la secuencia (también denominados “clasificadores” que implementan la misma). En general siempre será un actor el que inicie la secuencia, y el resto de participantes pueden ser objetos (representados con una caja en la que escribiremos el nombre del objeto), otros actores, o quizá un caso de uso completo.

Cada participante tiene un intervalo en el que éste está activo en la secuencia, que se indica mediante un rectángulo sobre la línea discontinua que representa la vida del objeto. El rectángulo empiezacuando el objeto recibe un mensaje (representado mediante una flecha que incorpora el nombre de la llamada) y termina cuando éste devuelve su última respuesta (representada mediante una flecha discontinua). Los mensajes suelen incluir números de secuencia que facilitan la comprensión del diagrama y el seguimiento del orden en que se producen los mensajes. A veces un error puede provocar una línea discontinua de retorno hasta el primer participante, de forma similar a cómo se propagaría una excepción. Así pues, las líneas de retorno pueden incluir también etiquetas para indicar si representan un error o no. Finalmente, un aspa al final de la vida del objeto indica que éste puede destruirse.

Finalmente, enumeramos un conjunto de buenas prácticas en la representación de diagramas de secuencia:
• El orden entre los mensajes y los participantes debe ser siempre de izquierda a derecha y de arriba abajo para facilitar la comprensión del diagrama.
• El nombre de los actores debe ser consistente con los casos de uso.
• El nombre de los objetos debe ser consistente con los diagramas de clases.
• Incluir notas en las secuencias.
• Sólo incluir el aspa de destrucción del objeto en casos en que proporcione información sobre cuándo debe destruirse, en caso contrario “ensuciaremos” el diagrama innecesariamente.

Fuentes:

Popkin Software and Systems. Modelado de Sistemas con UML. Un estudio a fondo de UML. Diagramas de Secuencia. Recuperado el 20 de Noviembre 2011, de http://www.ibiblio.org/pub/linux/docs/LuCaS/Tutoriales/doc-modelado-sistemas-UML/multiple-html/c12.html

UOC Formación de posgrado. Software libre. Ingeniería del software en entornos de SL. Marzo (2005). Marc Gibert Ginestà, Álvaro Peña González. Recuperado el 20 de Noviembre 2011, de http://www.sw-computacion.f2s.com/Linux/009-Ingenieria_del_software.pdf

Diagrama de Caso de Uso

Diagramas de Casos de Uso

Un modelo de casos de uso es descrito en UML como un diagrama de casos de uso (diagrama use-case) y dicho modelo puede ser dividido en varios diagramas de caso de uso. Un diagrama de casos de uso contiene elementos de modelo para el sistema, los actores y los casos de uso y muestra las diferentes relaciones tales como generalización, asociación y dependencia entre estos elementos. El diagrama de caso de uso debe ser fácil de entender por el usuario final.

Un caso de uso representa la funcionalidad completa tal y como la percibe un actor. Un caso de uso en UML es definido como un conjunto de secuencias de acciones que un sistema ejecuta y que permite un resultado observable de valores para un actor en particular. Gráficamente se representan con una elipse y tiene las siguientes características:

• Un caso de uso siempre es iniciado por un actor. 
• Un caso de uso provee valores a un actor. 
• Un caso de uso es completo.

Los casos de uso son una herramienta esencial en la toma de requisitos del sistema. Nos permiten expresar gráficamente las relaciones entre los diferentes usos del mismo y sus participantes o actores. El resultado es un conjunto de diagramas muy fácilmente entendibles tanto por el cliente, como por los analistas del proyecto.
No definen todos los requisitos (por ejemplo, tipos de datos, interfaces externas, rendimiento, etc.) pero sí que representan el hilo conductor que los vincula a todos con los actores del sistema.

Se componen de los siguientes elementos:

• Actores: representan los roles que juegan los usuarios u otros sistemas en el sistema del problema. Identificar a los actores de un caso de uso pasa por averiguar quién está involucrado en cada requisito concreto, quién se beneficiará de cada funcionalidad o quién proveerá o usará la información.

• Caso de uso: son las acciones que pueden tener lugar en el sistema que queremos modelar. Para identificarlas, puede ser útil preguntarse cuáles son las tareas y responsabilidades de cada actor, si habrá actores que recibirán información del sistema, etc.

• Relaciones: indican actividad o flujo de información.

• Límite del sistema: define el ámbito donde se produce el caso de uso que estamos representando y que va a ser tratado por el sistema. Los actores no son parte del sistema y por lo tanto están fuera de sus límites.

La etiqueta <<incluye>> entre dos casos de uso indica que uno tiene la funcionalidad de otro como parte integrante suya.

La etiqueta <<extiende>> indicará que un caso de uso amplía la funcionalidad de otro.

La etiqueta <<generaliza>> indica también una relación padre e hijo similar a la extensión, con la diferencia de que actúan exactamente igual en cuanto a reglas de negocio se refiere.

Dado el alto nivel al que estamos modelando el sistema en esta fase, es importante tener presentes algunas buenas prácticas con respecto a la interpretación y creación de diagramas de casos de uso:

• Empezar los nombres de los casos de uso con un verbo.

• Aunque no hay forma de indicar el orden en que un actor aplicará los casos de uso, suele ser más intuitivo representarlos en orden descendiente, situando los más importantes en la parte superior del diagrama.

• Situar a los actores principales en la parte superior del diagrama también ayuda a su comprensión y a generalizar de forma más entendible.

• Nombrar a los actores con sustantivos relacionados con las reglas de negocio, de acuerdo con los roles que representan. No con su cargo o posición en el sistema.

• Anteponer “Sistema” o <<sistema>> a los actores que sean procesos externos.

• Para representar eventos que ocurren de forma programada, podemos introducir un actor de sistema “Tiempo” para modelar sus casos de uso.

• La etiqueta <<incluye>> no es obligatoria. Es aconsejable incluirla sólo si en un punto específico la lógica del caso de uso incluido es necesaria.

• No debe abusarse de la etiqueta <<extiende>>, ya que dificulta la comprensión del caso.

• La generalización de clases suele identificarse porque una sola condición del caso de uso (en el ejemplo, el método de envío), cambia por completo su lógica interna, pero no así las reglas de negocio del sistema.

• Debe evitarse representar más de dos niveles de asociaciones de casos de uso en un mismo diagrama. Si nos encontramos en esta situación, hay muchas probabilidades de que estemos haciendo una representación funcional de lo que ocurre en el caso de uso. Debemos concentrarnos sólo en los requisitos de uso, ya que la descomposición funcional es parte de la fase de diseño.

• Situar los casos incluidos a la derecha del caso que los incluye ayuda a comprender mejor el diagrama. De la misma forma, es más intuitivo situar los casos que extienden debajo del caso padre, al igual que los casos que heredan o generalizan.

• Es útil intentar expresar con “es como” la generalización de actores para comprobar si los estamos modelando correctamente.

Fuentes:

Facultad de Ingeniería de la UNAM. Temas especiales e computación. Diagrama de casos de uso. Ing. Carlos Alberto Román Zamitiz. Recuperado el 20 de Noviembre 2011, de http://profesores.fib.unam.mx/carlos/aydoo/uml.html

UOC Formación de posgrado. Software libre. Ingeniería del software en entornos de SL. Marzo (2005). Marc Gibert Ginestà, Álvaro Peña González. Recuperado el 20 de Noviembre 2011, de http://www.sw-computacion.f2s.com/Linux/009-Ingenieria_del_software.pdf

Cuadro Comparativo Herramientas UML

Herramientas Diagramas UML
Dia con Dia2Code	Umbrello	ArgoUML
Ø  Es un programa ejecutable desde línea de comandos. Ø  Soporte de lenguaje de programación Python y PHP. Ø  La generación de código selectivo. Ø Manejo de Estereotipo: interfaces, clases abstractas. Ø  Plantilla y manipulación de paquetes. Ø  Módulos personalizados de generador de código que se cargan en la marcha. Ø  Genera código para: Ada, C, C++, Java, PHP, PHP5, Ruby, SQL. Ø Soporte para Java Beans(TM): se crean automáticamente métodos para acceder y modificar cada atributo.	Ø  Orientada totalmente al modelado UML. Ø  Herramientas destacables como la barra lateral izquierda. Ø  Generación de código con disponibilidad de un asistente. Ø  Código fuente de clases generadas bastante completo. Ø  Comentarios en formato JavaDoc. ØImportar clases a partir de sus ficheros fuente.  ØLenguajes de programación soportados PHP4, PHP5, Perl, XMLSchema.  ØEs software Libre. Ø  Sin Binario Actualizado para Windows.	Ø  Generación de código no ofrece tantas opciones. Ø  No soporta la inclusión de ficheros de licencia o cabeceras. Ø  Diseño de aplicaciones orientadas a objetos. Ø  Presenta una cheklist con la que se puede mejorar el diseño para cualquier elemento del modelo. Ø  Ofrece críticas en aspectos como la notación, uso de patrones de diseño, la inclusión de constructores. Ø  No genera código ni para constructor, métodos y atributos. Ø  Importación de ficheros fuente al modelo de modo para aprovechar clases en los diferentes diagramas. Ø  Es software libre.

Fuente:

UOC Formación de posgrado. Software libre. Ingeniería del software en entornos de SL. Marzo (2005). Marc Gibert Ginestà, Álvaro Peña González. Recuperado el 20 de Noviembre 2011, de http://www.sw-computacion.f2s.com/Linux/009-Ingenieria_del_software.pdf

Evaluación comparativa de herramientas CASE para UML desde el punto de vista notacional

Desde que UML (Unified Modeling Language) se ha establecido como un estándar de facto para el modelado orientado a objetos de sistemas informáticos, multitud de empresas se han lanzado a la carrera de conquistar el mercado de herramientas de apoyo a la ingeniería del software.

Al realizar este tipo de búsqueda sobre herramientas CASE podemos encontrar varios resultados en el que destacan los que proporciona Objects by Design en el cual se detallan las siguientes características:

Ø  Empresa

Ø  Producto

Ø  Versión y fecha

Ø  Plataforma (Windows, Java VM, Linux,

Ø  Unix, etc.).

Ø  Precio (desde $0 hasta $10.000).

El simple examen de estas características se revela insuficiente para fundamentar una elección acertada, ya que lamentablemente con demasiada frecuencia las promesas del fabricante resultan incumplidas en el producto real.

UML es un lenguaje visual de modelado para "visualizar, especificar, construir y documentar los artefactos de un sistema software", UML es ante todo un lenguaje gráfico que estandariza la forma de crear diagramas, el significado preciso de los mismos, y las relaciones existentes entre ellos.

Lo primero que podemos esperar de una herramienta es que facilite la tarea de dibujar diagramas, su corrección sintáctica, y la coherencia entre los distintos diagramas. Esto se ve obstaculizado debido al estándar que presenta UML el cual presenta todavía de ciertas inconsistencias.

Herramientas UML

La popularidad que ha ido adquiriendo el modelado de sistemas software con diagramas UML se encuentra vinculada a la existencia de herramientas CASE para UML que faciliten su gestión. Estas herramientas se pueden clasificar siguiendo los criterios como lo son: gráfica, sintáctica, semántica.

ü  Herramientas Gráficas

Las herramientas meramente gráficas son aquéllas que proporcionan algún tipo de ayuda para dibujar diagramas UML (como plantillas de formas predefinidas, etc.), de modo que resultan algo más convenientes que otras herramientas genéricas de dibujo. El problema es que no imponen prácticamente ningún tipo de restricción en lo que el usuario puede dibujar, de modo que se facilita la construcción de diagramas UML, pero no se garantiza en absoluto su corrección sintáctica.

ü  Herramientas Sintácticas

Las herramientas sintácticas son aquéllas que, en general, sólo permiten dibujar diagramas correctos según las reglas notacionales de UML. No obstante, en general estas herramientas no construyen internamente un modelo a la vez que los diagramas que lo expresan, de modo que los diagramas quedan desconectados unos de otros: de alguna manera, son diagramas correctos pero sin significado, sin un referente común.

ü  Herramientas Semánticas

Aquellas que tratan de garantizar la construcción de un modelo que esté correctamente expresado en diagramas que además sean coherentes entre sí.

Ciertamente, existen otras capacidades que habitualmente el usuario final espera encontrar en la herramienta buscada, de modo que tenga utilidad real en su entorno de producción.

Ø  Integración con herramientas ofimáticas

Ø  Posibilidad de trabajo multiusuario

Ø  Exportación en formato XMI

Ø  Integración dentro del entero proceso de desarrollo de software, desde la obtención de requisitos de usuario hasta la generación automática de código

Ø  Reutilización de todo tipo de artefactos software

Las herramientas CASE para MDA (llamadas Model Driven Architecture Tools) contemplan una nueva filosofía de desarrollo de sistemas software donde la utilización de modelos y su transformación constituyen el núcleo central.

Estudio Comparativo Inicial

El método consiste básicamente en formular una serie de cuestiones sobre la fidelidad de las herramientas a la notación de UML, y contabilizar el número de respuestas afirmativas y negativas obtenidas por cada herramienta. El método seguido para encontrar un conjunto de preguntas relevantes ha sido el siguiente:

·         Se selecciona un conjunto de diagramas significativos, ordenados por tipo de diagrama, que reflejen la totalidad de la notación de UML.

·         Se intenta representar estos diagramas utilizando las herramientas seleccionadas.

·         Cuando se detecta algún problema con una herramienta concreta, se formula de modo sintético la pregunta correspondiente y se anota la respuesta negativa proporcionada por esta herramienta.

·         La misma pregunta se plantea a las demás herramientas, de modo que se pueda establecer la comparación entre ellas.

·         Finalmente, se recopila en una tabla la lista de preguntas con las correspondientes respuestas afirmativas o negativas proporcionadas por todas las herramientas.

Estudio comparativo mejorado

En lugar de responder a cada pregunta meramente con Sí o No, anotamos cuatro posibles respuestas:

N: la herramienta no puede representar la característica especificada.

G: se puede representar gráficamente la característica especificada, pero ésta no queda registrada en el modelo subyacente.

M: no se puede representar gráficamente la característica especificada, pero sí es posible hacerlo en el modelo subyacente.

S: la herramienta sí puede representar la característica especificada, tanto de modo gráfico como en el modelo subyacente.

Valoración final y resultados

Las trece herramientas evaluadas pueden agruparse en tres secciones. Cuatro de ellas destacan como "las mejores": seCAKE, Enterprise Architect, Visio 2003 Professional y, muy especialmente, MagicDraw. Podemos distinguir también la sección de "las peores", con las tres herramientas que han obtenido la menor puntuación, habiendo una diferencia significativa respecto a la siguiente en la clasificación: Rational Rose, Visible Analyst y Argo UML.

Dadas las limitaciones de espacio, no es posible incluir aquí esta lista de preguntas, pero el lector interesado puede consultar la lista completa, así como las respuestas obtenidas con cada herramienta, en el informe complementario. Las preguntas aparecen clasificadas en seis categorías, correspondientes a seis tipos de diagrama (Estructura, Casos de uso, Interacción, Estados, Actividad, Implementación).

Trabajos futuros y conclusiones

Naturalmente, cuando las herramientas comerciales empiecen a adaptarse a la nueva versión 2.0 del estándar de UML, habrá que reformular la lista de criterios obtenidos y repetir las evaluaciones para las nuevas versiones de las herramientas ya estudiadas.

Otra posible mejora sería dar mayor peso a unos criterios que a otros en la evaluación global. Por último, podemos concluir que la fidelidad a la notación estándar de UML no lo es todo en la tarea de seleccionar una herramienta CASE, pero parece ser un aspecto sorprendentemente descuidado por bastantes herramientas, algunas de ellas con una notoria implantación en el mercado.

Fuentes: 

Gonzalo Génova Fuster, José Miguel Fuentes Torres, María Cruz Valiente Blázquez (mayo-junio 2006). Tecnología de Objetos secciones técnicas. Evaluación comparativa de herramientas CASE para UML desde el punto de vista notacional  Obtenido en Octubre, 2011, de Depto. de Informática, Universidad Carlos III de Madrid

El lenguaje Unificado de Modelado (UML)

En todas las disciplinas de la Ingeniería se hace evidente la importancia de los modelos ya que describen el aspecto y la conducta de "algo". Ese "algo" puede existir, estar en un estado de desarrollo o estar, todavía, en un estado de planeación. Es en este momento cuando los diseñadores del modelo deben investigar los requerimientos del producto terminado y dichos requerimientos pueden incluir áreas tales como funcionalidad, performance y confiabilidad. Además, a menudo, el modelo es dividido en un número de vistas, cada una de las cuales describe un aspecto específico del producto o sistema en construcción.

El modelado sirve no solamente para los grandes sistemas, aun en aplicaciones de pequeño tamaño se obtienen beneficios de modelado, sin embargo es un hecho que entre más grande y más complejo es el sistema, más importante es el papel de que juega el modelado por una simple razón: "El hombre hace modelos de sistemas complejos porque no puede entenderlos en su totalidad".

UML es una técnica para la especificación sistemas en todas sus fases. Nació en 1994 cubriendo los aspectos principales de todos los métodos de diseño antecesores y, precisamente, los padres de UML son Grady Booch, autor del método Booch; James Rumbaugh, autor del método OMT e Ivar Jacobson, autor de los métodos OOSE y Objectory. La versión 1.0 de UML fue liberada en Enero de 1997 y ha sido utilizado con éxito en sistemas construidos para toda clase de industrias alrededor del mundo: hospitales, bancos, comunicaciones, aeronáutica, finanzas, etc.

El Lenguaje Unificado de Modelado prescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan. Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación. 

UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas. 

· Diagramas de Casos de Uso para modelar los procesos 'business'. 

· Diagramas de Secuencia para modelar el paso de mensajes entre objetos. 

· Diagramas de Colaboración para modelar interacciones entre objetos. 

· Diagramas de Estado para modelar el comportamiento de los objetos en el sistema. 

· Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones. 

· Diagramas de Clases para modelar la estructura estática de las clases en el sistema. 

· Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema. 

· Diagramas de Componentes para modelar componentes. 

· Diagramas de Implementación para modelar la distribución del sistema. 

UML es una consolidación de muchas de las notaciones y conceptos más usadas orientados a objetos. Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologías orientadas a objetos más populares. 

En 1996, el Object Management Group (OMG), un pilar estándar para la comunidad del diseño orientado a objetos, publicó una petición con propósito de un metamodelo orientado a objetos de semántica y notación estándares. UML, en su versión 1.0, fue propuesto como una respuesta a esta petición en enero de 1997. Hubo otras cinco propuestas rivales. Durante el transcurso de 1997, los seis promotores de las propuestas, unieron su trabajo y presentaron al OMG un documento revisado de UML, llamado UML versión 1.1. Este documento fue aprobado por el OMG en Noviembre de 1997. El OMG llama a este documento OMG UML versión 1.1. El OMG está actualmente en proceso de mejorar una edición técnica de esta especificación, prevista su finalización para el 1 de abril de 1999.

FASES DEL DESARROLLO DE UN SISTEMA 

Las fases del desarrollo de sistemas que soporta UML son: Análisis de requerimientos, Análisis, Diseño, Programación y Pruebas. 

Análisis de Requerimientos 

UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A través del modelado de casos de uso, los actores externos que tienen interés en el sistema son modelados con la funcionalidad que ellos requieren del sistema (los casos de uso). Los actores y los casos de uso son modelados con relaciones y tienen asociaciones entre ellos o éstas son divididas en jerarquías. Los actores y casos de uso son descritos en un diagrama use-case. Cada use-case es descrito en texto y especifica los requerimientos del cliente: lo que él (o ella) espera del sistema sin considerar la funcionalidad que se implementará. Un análisis de requerimientos puede ser realizado también para procesos de negocios, no solamente para sistemas de software. 

Análisis 

La fase de análisis abarca las abstracciones primarias (clases y objetos) y mecanismos que están presentes en el dominio del problema. Las clases que se modelan son identificadas, con sus relaciones y descritas en un diagrama de clases. Las colaboraciones entre las clases para ejecutar los casos de uso también se consideran en esta fase a través de los modelos dinámicos en UML. Es importante notar que sólo se consideran clases que están en el dominio del problema (conceptos del mundo real) y todavía no se consideran clases que definen detalles y soluciones en el sistema de software, tales como clases para interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc. 

Diseño 

En la fase de diseño, el resultado del análisis es expandido a una solución técnica. Se agregan nuevas clases que proveen de la infraestructura técnica: interfaces de usuario, manejo de bases de datos para almacenar objetos en una base de datos, comunicaciones con otros sistemas, etc. Las clases de dominio del problema del análisis son agregadas en esta fase. El diseño resulta en especificaciones detalladas para la fase de programación. 

Programación 

En esta fase las clases del diseño son convertidas a código en un lenguaje de programación orientado a objetos. Cuando se crean los modelos de análisis y diseño en UML, lo más aconsejable es trasladar mentalmente esos modelos a código. 

Pruebas 

Normalmente, un sistema es tratado en pruebas de unidades, pruebas de integración, pruebas de sistema, pruebas de aceptación, etc. Las pruebas de unidades se realizan a clases individuales o a un grupo de clases y son típicamente ejecutadas por el programador. Las pruebas de integración integran componentes y clases en orden para verificar que se ejecutan como se especificó. Las pruebas de sistema ven al sistema como una "caja negra" y validan que el sistema tenga la funcionalidad final que le usuario final espera. Las pruebas de aceptación conducidas por el cliente verifican que el sistema satisface los requerimientos y son similares a las pruebas de sistema.

Fuentes:

Facultad de Ingeniería de la UNAM. Temas especiales e computación. El Lenguaje de Modelado Unificado (UML). Ing. Carlos Alberto Román Zamitiz. Recuperado el 20 de Noviembre 2011, de http://profesores.fib.unam.mx/carlos/aydoo/uml.html

Popkin Software and Systems. Modelado de Sistemas con UML. ¿Qué es UML? Recuperado el 20 de Noviembre 2011, de http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/doc-modelado-sistemas-uml.pdf