|
En la primer parte hemos establecido que UML es
un lenguaje para especificar los artefactos y
las interacciones de un sistema de software.
También hemos visto que trata con 6 dominios
principales – desde modelos de Casos Uso, a
través de modelos dinámicos y lógicos hasta el
modelo de despliegue físico final – y que los
mecanismos de extensión se han incluido para
permitir las adiciones especializadas a la
notación del modelo.
Entonces... ¿Cómo debe usar UML?
El UML se usa normalmente como una parte de un proceso de desarrollo de software, con el soporte de la
herramienta CASE apropiada, para definir
los requisitos, las interacciones y los
elementos del sistema de software propuesto. La
naturaleza exacta del proceso depende de la
metodología del desarrollo usada. El siguiente
es un ejemplo del siguiente proceso
| 1. |
Captura un
Modelo del Proceso de Negocio. Este se usará para definir las actividades y procesos de alto
nivel que ocurren en una organización y
proveen una base para el modelo de
Casos de Uso. El
Modelo del Proceso de Negocios
normalmente capturará más de lo que
implementaría un sistema de software (Es
decir, este incluye procesos manuales y
otros). |
| 2. |
Traza un
Modelo de Casos de Uso
al Modelo del Proceso de Negocio para definir exactamente que funcionalidad intenta proveer
desde la perspectiva del usuario de
negocios. Mientras cada Caso de Uso se
agrega, crea un vínculo trazable desde
los procesos de negocios apropiados al
Caso de Uso (es decir, una conexión de
realización). Este trazado claramente
establece que funcionalidad proveerá el
nuevo sistema para cumplir con los
requisitos del negocio establecido en el
modelo del proceso. Este también asegura
que no existe ningún Caso de Uso sin un
propósito. |
| 3. |
Refine los Casos de Uso – incluye
requisitos, restricciones, clasificación
de complejidad, notas y escenarios. Esta
información ambiguamente describe lo que
hace el Caso de Uso, como se ejecuta y
las restricciones en esta ejecución. Se
asegura de que el Caso de Uso todavía
reúne los requisitos del proceso de
negocio. Incluye la definición de las
pruebas del sistema para cada Caso de
Uso y así definir el criterio de
aceptación para cada Caso de Uso.
También incluye algunos scripts de
pruebas de aceptación del usuario para
definir como el usuario probará esta
funcionalidad y cuales son los criterios
de aceptación. |
| 4. |
Desde las entradas y las salidas del
Modelo
del Proceso de Negocio y los detalles de
los casos de uso, comienza a estructurar
un modelo de dominio (objetos de negocio
de alto nivel), diagrama de secuencia,
diagrama de colaboración y los modelos
de la interfaz de usuario. Estos
describen las “cosas” en el nuevo
sistema, la manera en que esas partes
interactúan y la interfaz que un usuario
usará para ejecutar los escenarios de
los casos de uso. |
| 5. |
Desde el modelo de dominio, el modelo de la
interfaz de usuario y los diagramas del
escenario crean el
Modelo de Clase. Esta es
una especificación precisa de los
objetos en el sistema, sus datos o
atributos y su comportamiento u
operaciones. Los objetos del dominio se
pueden abstraer en las jerarquías de la
clase usando herencias. Los mensajes del
diagrama del escenario normalmente
trazarán las operaciones de la clase. Si
se usa un marco existente o patrón del
diseño, es posible importar elementos
del modelo existentes para usarlos en el
nuevo sistema. Para cada clase define
pruebas de unidad y pruebas de
integración para probar completamente i)
que la clase funciona como se
especifican internamente y que ii) la
clase interactúe con otras clases
relacionadas y los componentes como se
espera. |
| 6. |
Mientras la clase del modelo se desarrolla,
se puede fraccionar en paquetes y
componentes discretos. Un componente
representa una porción despegable del
software que recolecta el comportamiento
y datos de una o más clases, y expone
una interfaz estricta a otros
consumidores de sus servicios. Así un
Modelo del Componente se compila para
definir el empaquetamiento lógico de las
clases. Para cada componente define
pruebas de integración para confirmar
que la interfaz del componente reúne la
especificación dada en relación con
otros elementos del software. |
| 7. |
Concurrentemente con el trabajo que ya
realizó, se deberían capturar y
documentar requisitos adicionales. Por
ejemplo – los requisitos funcionales,
requisitos de desempeño, requisitos de
seguridad, responsabilidades, liberar
planos y más. Colecta estos dentro del
modelo y los mantiene al día mientras
madura el modelo. |
| 8. |
El
Modelo de Despliegue
define la arquitectura física del
sistema.
Este trabajo puede comenzar
tempranamente para capturar las
características de despliegue físico –
que hardware, sistemas operativos,
capacidades de la red, software de
interfaces y soporte conformarán el
nuevo sistema, donde se desplegará y que
parámetros aplica para recuperarse de
los desastres, confiabilidad, copias de
seguridad y soporte. Mientras el modelo
se desarrolla la arquitectura física se
actualizará para reflejar el sistema
actual propuesto. |
| 9. |
Construye el sistema: Toma piezas discretas
del modelo y asigna uno o más
desarrolladores. En una compilación
dirigida por Casos de Uso, esto
significará asignar un Caso de Uso a un
equipo de desarrollo, y hacer que ellos
construyan pantallas, objetos de
negocio, tablas de base de datos, y los
componentes relacionados necesarios para
ejecutar ese Caso de Uso. Mientras cada
Caso de Uso se construye, éste debería
estar acompañado por pruebas de sistema,
integración y unidad completas. Una
construcción dirigida del componente
puede ver componentes del software
discretos asignados a los equipos de
desarrollo para su construcción. |
| 10. |
Rastrea los defectos que emergen en la fase
de pruebas contra los elementos del
modelo relacionados – ej. Defectos de
prueba del sistema contra los Casos de
Uso, defectos de prueba de unidad contra
las clases etc. Rastrea cualquier cambio
contra los elementos del modelo
relacionado para administrar “scope
creep”. |
| 11. |
Actualiza y refine el modelo mientras
procede el trabajo – siempre evaluando
el impacto de cambios y mejoras del
modelo en trabajos posteriores. Usa una
aproximación iterativa para trabajar a
través del diseño en fragmentos
discretos, siempre evaluando la
compilación actual, los requisitos
posteriores y cualquier descubrimiento
que aparece durante el desarrollo. |
| 12. |
Entrega del software completo a un proceso
de prueba y al entorno de producción. Si
se realiza una entrega en fases, luego
ésta migración del software de
construcción desde la prueba a la
producción puede ocurrir varias veces en
la vida del producto. |
Tener en
cuenta que el proceso anterior es necesariamente
corto en descripción, deja mucho sin decir y
puede ser que no corresponda a su forma de
trabajo y que no siga el proceso que ha
adoptado. Esto se ha proporcionado como un
ejemplo de como se puede usar UML para soportar
un proyecto de desarrollo de software. |
