Objeto de Aprendizaje : Introducción a UML

INTRODUCCIÓN A UML
Lenguaje de Modelado
Unificado

Qué es UML?
 El UML modela sistema mediante el uso de objetos
que forman parte de él así como, las relaciones
estáticas o dinámicas que existen entre ellos.
 UML puede ser utilizado por cualquier metodología
de análisis y diseño orientada por objetos para
expresar los diseños.

Qué es UML?
 UML es un Lenguaje de Modelado Unificado basado en
una notación gráfica la cual permite: especificar,
construir, visualizar y documentar los objetos de un
sistema programado.
 Este lenguaje es el resultado de la unificación de los
métodos de modelado orientados a objetos de Booch,
Rumbaugh (OMT: Object Modeling Technique) y
Jacobson (OOSE: Object-Oriented Sotfware
Engineering).

UML
 UML es un lenguaje de modelado que sirve para
visualizar, especificar , construir y documentar un
sistema software.
Lenguaje de modelado:
“Lenguaje cuyo vocabulario y reglas se centran en la
representación conceptual y física de un sistema” (Booch,
Jacobson y Rumbaugh).

UML para visualizar
 Símbolos con semántica bien definida.
 UML transciende al lenguaje de programación.
 Modelo explícito, que facilita la comunicación.

UML para especificar
 Especificar es equivalente a construir modelos que
cumplan las condiciones de no ambigüedad y
completitud.
 UML cubre la especificación del análisis, diseño e
implementación de un sistema software.

UML para construir
 Es posible hacer
corresponder
con los lenguajes
de programación
(Java, C#,
B.Datos, etc.).
Modelo
UML
Ingeniería Directa
Ingeniería Inversa
CÓDIGO

UML para documentar
 UML cubre la documentación de un sistema:
– Requisitos
– Arquitectura
– Diseño
– Código fuente
– Planificación
– Pruebas
– Prototipos
– Versiones

UML “aglutina” enfoques OO
UML
Rumbaugh
Jacobson
Meyer
Harel
Wirfs-Brock
Fusion
Embly
Gamma et. al.
Shlaer-Mellor
Odell
Booch
Pre- and Post-conditions
State Charts
Responsabilities
Operation descriptions,
message numbering
Singleton classes
Frameworks, patterns,
notes
Object life cycles

Historia de UML
Nov ‘97 UML aprobado por el OMG
1998
1999
2000
UML 1.2
UML 1.3
UML 1.4
2001 UML 2.0
Revisiones
menores

Actualizaciones de UML
 UML 1.3 es una versión madura de UML a la que se le han
añadido una serie de pequeñas revisiones, las cuales
corrigen o mejoran la especificación base (UML 1.2).
 UML 1.4 incorpora ciertas modificaciones sobre el estándar
en base a los comentarios recogidos de los usuarios
finales y de los fabricantes de software compatible con
UML.
 UML 2.0 promete la puesta a punto del estándar para
poder integrarse con el desarrollo basado en componentes
que demanda el mercado.

UML 2.0
 Arquitectura: refinamiento del núcleo del estándar para que
esté en consonancia con el resto de estándares del mercado.
 Personalización: mejora de los mecanismos de extensibilidad y
personalización.
 Componentes: mejor soporte para el desarrollo basado en
componentes (CORBA, EJB, COM+).
 Mecanismos generales: nuevos mecanimos para el control de
las versiones dentro del modelo, así como el intercambio de
los metadatos del mismo con XMI (XML Metadad Interchange).

 Un proceso de desarrollo de software debe ofrecer un conjunto
de modelos que permitan expresar el producto desde cada
una de las perspectivas de interés
 El código fuente del sistema es el modelo más detallado del
sistema (y además es ejecutable). Sin embargo, se requieren
otros modelos ...
 Cada modelo es completo desde su punto de vista del
sistema, sin embargo, existen relaciones de trazabilidad entre
los diferentes modelos
Modelos y Diagramas

Modelos y Diagramas
 Modelo: captura una vista de un sistema del mundo real. Es una
abstracción de dicho sistema, considerando un cierto propósito.
 Diagrama: representación gráfica de una colección de elementos
de modelado, a menudo dibujada como un grafo con vértices
conectados por arcos.

Vista de Diseño
Vista de
Procesos
Vista de
Despliegue
Vista de
Implementación
Vista de los
Casos de Uso
Organización de Modelos

Diagramas de UML
Use Case
Diagrams
Use Case
Diagrams
Diagramas de
Casos de Uso
Scenario
Diagrams
Scenario
Diagrams
Diagramas de
Colaboración
State
Diagrams
State
Diagrams
Diagramas de
Componentes
Component
DiagramsComponent
DiagramsDiagramas de
Distribución
State
Diagrams
State
Diagrams
Diagramas de
Objetos
Scenario
Diagrams
Scenario
Diagrams
Diagramas de
Estados
Use Case
Diagrams
Use Case
Diagrams
Diagramas de
Secuencia
State
Diagrams
State
Diagrams
Diagramas de
Clases
Diagramas de
Actividad
Modelo

Mecanismos comunes en UML
Especificaciones. Es más que un lenguaje
gráfico (semántica detrás de la notación).
Adornos. Detalles sobre un clase, nivel de
acceso de sus métodos, notas.
Divisiones Comunes: Clase/Objecto o
Interfaz/Implementación.
Extensibilidad. Estereotipos, valores etiquetados
o restricciones.

Casos de Usos
 Un diagrama de Casos de Uso muestra la distintas
operaciones que se esperan de una aplicación o
sistema y cómo se relaciona con su entorno (usuario
u otras aplicaciones).
 Es una herramienta esencial para la captura de
requerimientos y para la planificación y control de un
proyecto interactivo.

Casos de Usos
 Los casos de Uso Se representa en el diagrama por
una elipse que denota un requerimiento
solucionando por el sistema.
 Cada caso de uso de uso es una operación
completa desarrollada por los actores y por el
sistema en un diálogo.
 El conjunto de casos de uso representa la totalidad
de operaciones desarrolladas por el sistema.

Casos de Usos
 Actor: Es un usuario del sistema, que necesita o
usa alguno de los casos de uso. Un usuario puede
jugar más de un rol. Un solo actor puede actuar en
muchos casos de uso; recíprocamente, un caso de
uso puede tener varios actores. Los actores no
necesitan ser humanos pueden ser sistemas
externos que necesitan alguna información del
sistema actual.

Casos de Usos
 También se puede encontrar tres tipos de
relaciones, como son:
– Comunica (comunicates) Entre un actor y un
caso de uso, denota la participación del actor en
el caso de uso determinado.

Casos de Usos
 Usa (uses): Relación entre dos casos de
uso, denota la inclusión del comportamiento
de un escenario en otro. Se utiliza cuando se
repite un caso de uso en dos o más casos
de uso separados. Frecuentemente no hay
actor asociado con el caso de uso común.

Casos de Usos
 Extiende (extends): Relación entre dos
casos, denota cuando un caso de uso es
una especialización de otro. Se usa cuando
se describe una variación sobre el normal
comportamiento.

Casos de Usos
 Técnicas comunes de modelado:
– Modelado del contexto del sistema (utilidad
similar a los DFD).
– Modelado de los requisitos de un sistema.
– Modelado del proceso de test y estrés del
sistema.

Conceptos básicos orientación a objetos
 Clase
 Objeto
 Herencia
 Interfaz
 Polimorfismo de clases
 Clases y atributos estáticos
 Clases y atributos finales
 Clases y métodos abstractos

Diagrama de clases
 Un diagrama de clases o estructura estática muestra
el conjunto de clases y objeto importantes que
forman parte de un sistema, junto con las relaciones
existentes entre clases y objetos. Muestra de una
manera estática la estructura de información del
sistema y la visibilidad que tiene cada una de las
clases, dada por sus relaciones con los demás en el
modelo.

Diagrama de clases
 Usos comunes del diagrama:
– Modelado del vocabulario del sistema.
– Modelado de colaboraciones simples.
– Modelado de un esquema lógico de base de
datos.
– Modelado de un conjunto de clases de test.

Diagrama de clases
 Clase: representa un conjunto de entidades que
tienen en común propiedades, operaciones,
relaciones y semántica.
 Una clase es un constructor que define la estructura
y comportamiento de una colección de objeto
denominados instancia de la clase.
 En UML la clase está representada por un
rectángulo con tres divisiones internas, son los
elementos fundamentales del diagrama.

Diagrama de clases
 Atributo: Representa una propiedad de una entidad.
Cada atributo de un objeto tiene un valor que pertenece
a un dominio de valores determinado.
 Las sintaxis de una atributo es:
– Visibilidad <nombre>: tipo = valor { propiedades}
 Donde visibilidad es uno de los siguientes:
– + público.
– # protegido.
– - privado.

Diagrama de clases
 Operación: El conjunto de operaciones que
describen el comportamiento de los objetos de una
clase. La sintaxis de una operación en UML es:
 Visibilidad nombre (lista de parámetros): tipo que
retorna { propiedades}

Diagrama de clases
Nombre de la clase
Atributos
Métodos

Diagrama de clases
 Responsabilidades: Contrato u obligación de una
clase, asignada en el momento del diseño.
 Clase Producto:
– Registrar el código de la publicación.
– Mantener estructura del producto plantilla.

Diagrama de clases
 Técnicas de modelado:
– Modelado del vocabulario de un sistema a partir de
las descripciones funcionales.
– Modelado de la distribución de responsabilidades en
un sistema.
– Modelado de cosas que no son software (hardware,
personas, etc).
– Modelado de tipos primitivos.

Diagrama de clases
 Objeto: es una instancia de una clase. Se
caracteriza por tener una identidad única, un estado
definido por un conjunto de valores de atributos y un
comportamiento representado por sus operaciones y
métodos.
 Asociación (rol, multiplicidad, calificador):
representan las relaciones entre instancias de clase.
Una asociación es una línea que une dos o más
clases.

Diagrama de clases
 Nombre: Identifica la asociación entre los objetos,
caracterizándola.
 Rol: Identificado como un nombre a los finales de la
línea, describe la semántica de la relación en el sentido
indicado. Cada asociación tiene dos roles; cada rol es
una dirección en la asociación. El rol puede estar
representado en el nombre de la clase.

Diagrama de clases
 Multiplicidad: Describe la cardinalidad de la
relación, es decir, cuanto objetos de esa clase
pueden participar en la relación dada. Tipos:

Diagrama de clases
 Dependencia: Es una relación donde existen entidades
independientes y otras dependientes, lo que implica que
cambiar el elemento independiente puede requerir
cambios en los dependientes. Se representa con una
línea punteada direccional, indicando el sentido de la
dependencia.

Diagrama de clases
 Los tipos de asociaciones entre clases
presentes en un diagrama estático son:
– Asociación binaria.
– Asociación n-aria.
– Composición.
– Generalización.
– Refinamiento.

Diagrama de clases
 Asociación Binaria: Representa una relación
sencilla entre dos clases, no muy fuerte (es decir,
no se exige dependencia existencial ni
encapsulamiento). Se indica como una línea sólida
que une dos clases.
 Asociación n-aria: Es una asociación entre tres o
más clases. Se representa como un diamante del
cual salen líneas de asociación a las clases.

Diagrama de clases
 Composición: Es una asociación fuerte que
implica:
– Dependencia existencial. El elemento
dependiente desaparece al destruirse el que lo
contiene y, si es de cardinalidad 1, es creado al
mismo tiempo.
– Hay una pertenencia fuerte. Se puede decir que
el objeto contenido es parte constitutiva y vital del
que lo contiene.

Diagrama de clases
– Los objetivos contenidos no son compartidos, esto
es, no hacen parte del estado de otro objeto.
 Se denota dibujando un rombo del lado de la
clase que contiene a la otra en la relación.

Diagrama de clases
 Agregación: Relaciona una clase ya
ensamblada con una clase componente. Es
también una relación de composición menos
fuerte (no se exige dependencia existencial)
y se denota por un rombo sin rellenar en un
o de los extremos.

Diagrama de clases
 Generalización: es un proceso de abstracción en el
cual un conjunto de clases existentes, que tienen
atributos y métodos comunes, es referido por una
clase genérica a un nivel mayor de abstracción. La
relación de generalización denota una relación de
herencia entre clases. Se representa dibujando un
triángulo sin rellenar en el lado de la superclase. La
subclase hereda todos los atributos y mensajes
descritos en la superclase.

Diagrama de clases
 Refinamiento: Es una relación que
representa la especificación completa de
algo que ya ha sido especificado con cierto
nivel de detalle. Por ejemplo, una clase del
diseño es un refinamiento de una clase de
análisis.

Diagrama de clases
– Modelado de dependencias simples.
– Modelado de herencia simple.
– Modelado de relaciones estructurales
(composiciones y agregaciones).
– Modelado de comentarios.

Diagrama de interacción
 Estos son modelos que describen como los
grupos de objetos que colaboran en algunos
ambientes. Por lo general, un diagrama de
interacción captura el comportamiento de un
único caso de uso.
 Hay dos tipos de diagramas de interacción:
diagramas de secuencia y diagramas de
colaboración.

 Un diagrama de secuencia muestra la interacción de
un conjunto de objetos de una aplicación a través
del tiempo. Esta descripción es importante porque
puede dar detalle a los casos de uso, aclarándolos
al nivel de mensajes de los objetos existentes, como
también muestra el uso de los mensajes de las
clases diseñadas en el contexto de una operación.

 Elementos básicos del diagrama de
interacción:
– Objetos o actores para cada entidad.
– Enlaces entre los objetos.
– Procedimientos a invocar entre los objetos.
– Mensajes entre los objetos.

 Un objeto se representa como una línea vertical punteada
(línea de vida), con un rectángulo de encabezado y con
rectángulo a través de la línea principal que denotan la
activación, es decir, el período de tiempo en el cual el objeto se
encuentra desarrollando alguna operación.
 El rectángulo de encabezado contiene el nombre del objeto y
el de su clase, en un formato nombreObjeto: nombreClase. El
envío de mensajes entre objetos se denotan mediante una
línea sólida dirigida, desde el objeto que emite el mensaje
hacia el objeto que lo ejecuta.

 Diagramas de Colaboración:
– Es una forma de representar interacción entre los objetos,
es decir, las relaciones entre ellos y la secuencia de los
mensajes de las iteraciones que están indicadas por un
número A diferencia de los diagramas de secuencia,
pueden mostrar el contexto de la operación (cuáles objetos
son atributos, cuáles temporales, etc) y ciclos en la
ejecución. Muestra como varios objetos colaboran en un
solo caso de uso.

– Modelado dinámico del sistema.
– Implementación de un caso de uso en concreto para
cada diagrama.
– Modelado del flujo de control por ordenación temporal
(secuencia).
– Modelado del flujo de control por organización
(colaboración).

Diagrama de estados
 Diagrama de Estados:
– Muestra el conjunto de estado por los cuales
pasa un objeto durante su vida en una aplicación
junto con los cambios que permiten pasar de un
estado a otro. Esta representado principalmente
por los siguientes elementos:
 Estado.
 Elemento.
 Transición.

Diagrama de estados
 Estado: Identifica un período de tiempo del objeto
(no instantáneo) en el cual el objeto esta esperando
alguna operación, tiene cierto estado característico o
puede recibir cierto tipo de estímulos.

Diagrama de estados
 Partes que componen un estado:
– Nombre
– Acciones de entrada y de salida.
– Transiciones internas.
– Subestados.
– Eventos diferidos.

Diagrama de estados
 Eventos: Es una ocurrencia que puede causar la
transición de un estado a otro de un objeto. Esta,
puede ser una:
– Condición que toma el de verdadero o falso.
– Recepción de una señal de otro objeto en el modelo.
– Recepción de un mensaje.
– Paso de cierto período de tiempo, después de entrar al
estado o de cierta hora y fecha particular.

Diagrama de estados
 Transición: Es una relación entre estados de un
fuente a un destino.
 Partes que componen una transición:
– Estado de origen.
– Evento de disparo.
– Condición de guarda.
– Acción.
– Estado de destino.

Diagrama de estados
 Otros elementos:
– Subestados. Secuenciales o no, resultan en una nueva
máquina de estados.
– Estados de historia.
– Estados de historia. Permiten a un conjunto de estados o
subestados de un objeto, recordar el estado que estaba
activo en su última ejecución. Si no existe historia, se
comenzaría por el estado inicial.
– Subestados concurrentes.

Diagrama de estados
– Modelado de la vida de un objeto. Este tipo de
diagramas se asocian directamente a una clase.

Diagrama de Actividades
 Un diagrama de actividades es un caso especial de
un diagrama de estados en el cual casi todos los
estados son estados de acción (identifican que
acción se ejecuta al esta en él ) y casi todas las
transiciones son enviadas al terminar la acción
ejecutada en el estado anterior.
 Generalmente modelan los pasos de un algoritmo y
puede dar detalle a un caso de uso, un objeto o un
mensaje en un objeto.

 Sirven para representar transiciones internas, sin
hacer mucho énfasis en transiciones o eventos
externos.
 Los elementos que conforman el diagrama son:
– Acción
– Transición.
– Objetos

 Estado de Acción: representa un estado
con acción interna, con lo menos una
transición que indica la culminación de la
acción (por medio de un evento implícito).
– Permite modular un paso dentro del algoritmo. Se
representan por un rectángulo con bordes
redondeados.

 Estado de Actividad: Estado más general
que permite su descomposición en otro
diagrama de actividades interno, de nivel
más bajo.
– Su representación, en cuanto a la notación, es la
misma que el de Acción.

 Casos especiales:
– Estado inicial. Representa el punto de entrada del
diagrama de actividades.
– Estado final. Su existencia depende de si el
diagrama es cíclico.
– Ítem de decisión. Representado con un rombo,
permite tomar bifurcaciones condicionales.

 Casos especiales:
– Carriles o “Swim Lanes”. Permiten acotar el área a
las cuales las actividades están asociadas
(departamentos, módulos del sistema, etc).
– Flujos con objetos. Hacer explícita la relación con una
entidad en concreto.

 Transición: Es la relación entre dos estados
y se encuentran unidos por flechas;
indicando que un objeto que está en el
primer estado realizará una acción
especificada y entrará en el segundo estado
cuando un evento implícito ocurra y unas
condiciones especificas sean satisfechas.

 Tipos de transiciones:
– Bifurcaciones condicionales. Permiten tomar
distintos caminos dentro del diagrama en función
de una condición o “guarda”.
– División y unión. Permiten representar el
paralelismo en la ejecución de actividades.

– Modelado de un flujo de trabajo o Workflow. Uso intensivo de
estados de actividad, swim lanes y bifurcaciones
condicionales.
– Modelado de una operación concreta que resulta muy
complicada. Uso intensivo de transiciones (simples o
paralelas) y de estados de acción.

Diagrama de componentes
 Los diagramas de componentes describen los
elementos físicos reemplazables 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, librerías, bibliotecas cargadas
dinámicamente, etc.
 Las relaciones de dependencia se utilizan en los
diagramas de componentes para indicar que un
componente utiliza los servicios ofrecidos por otro
componente

– Modelado de ejecutables y bibliotecas.
– Modelado de tablas, archivos y documentos.
– Modelado y diseño de un API.
– Modelado del código fuente.
– Planificación de versiones ejecutables para su implementación
con Nant.

Diagrama de despliegue
 Los diagramas de despliegue muestran la
disposición física de los distintos nodos que
componen un sistema y el reparto de los
componentes sobre dichos nodos

 La vista de despliegue representa la disposición de las
instancias de componentes de ejecución en instancias de
nodos conectados por enlaces de comunicación.
 Un nodo es un recurso de ejecución tal como
– Dispositivos
– Procesadores
– Memoria
 Los nodos se interconectan mediante soportes bidireccionales
que pueden a su vez estereotiparse.

 Los nodos se interconectan mediante
soportes bidireccionales que pueden a su
vez estereotiparse.
 Esta vista permite determinar las
consecuencias de la distribución y la
asignación de recursos.

– Modelado de procesadores y dispositivos.
– Modelado de distribución de componentes.

RUP: El Proceso Unificado de Rational

Proceso Unificado de Rational
 Orígenes
– Modelo original Objectory definido por Ivan
Jacobson (1987)
– Rational Software compra la empresa de
Objectory (1995)
– Surge la primera versión de UML (1997)
– Se publica la primera versión del Proceso
Unificado de Rational - RUP (junio 1998)

Casos de uso
 Dirigido por casos de uso
– Se centra en la funcionalidad que el sistema debe poseer para
satisfacer las necesidades de un usuario (persona, sistema
externo, dispositivo) que interactua con él
– Casos de uso como el hilo conductor que orienta las actividades de
desarrollo
Casos de Uso
Análisis
Recopilar,
Clarificar y
Validar los
requerimientos
Diseño
Realizar los
casos de uso
Pruebas
Verificar que se
satisfacen los
casos de uso
<<realiza>> <<verifica>>
<<defineNecesidades>>

Arquitectura
 Centrado en la arquitectura
– Concepto similar a la arquitectura de un edificio
 Varios planos con diferentes aspectos del edificio
 Tener una imagen completa del edificio antes que comience la construcción
– Arquitectura en software
 Diferentes vistas del sistema: estructural, funcional, dinámico, etc.
 Plataforma en la que va a operar
 Determina la forma del sistema
– Arquitectura: determina la forma del sistema
– Casos de uso: determinan la función del sistema

Modelo que implementa
 Iterativo e incremental
– Descomposición de un proyecto grande en mini-proyectos
– Cada mini-proyecto es una iteración
– Las iteraciones deben estar controladas
– Cada iteración trata un conjunto de casos de uso
 Ventajas del enfoque iterativo
– Detección temprana de riesgos
– Administración adecuada del cambio
– Mayor grado de reutilización
– Mayor experiencia para el grupo de desarrollo

Estructura
Dinámica
 Ciclo: cada ciclo una nueva versión del producto
 Fase: Etapas de un ciclo que finalizan en un HITO
 Iteración: Proceso de ingeniería sobre una funcionalidad
limitada del sistema
Estática - Flujos de trabajo
 Artefactos
 Actividades
 Roles

Estructura
 Roles QUIÉN?
 Actividades CÓMO?
 Artefactos QUÈ?
 Flujo de Trabajo CUÁNDO?
realiza
responsable de
diseñador
diseño de caso
de uso
diagrama de
secuencia

Roles
 Definición del comportamiento y responsabilidades
de los participantes
 Propietario de una serie de artefactos
Recurso Rol Actividad Artefacto
Diseñador Diseño de Objetos DC
Analista Definición de CU DCU
Dominio
Diseñador Diseño de CU DS
Funcional
Patricia
Juan
Mónica
Pedro

Actividades
 Unidad de trabajo que puede ejecutar un individuo en un rol
específico
 Tiene un propósito claro y se expresa en términos de actualizar
artefactos
 La granularidad de la actividad es generalmente de horas o
pocos días
 Ejemplos de actividades
– Planear una iteración (administrador del proyecto)
– Encontrar caso de uso y actores (analista del dominio)
– Revisión del diseño (probador)

Artefactos
 Pieza de información producida, modificada y
utilizada en un proceso
 Productos tangibles del proyecto
 Utilizados por los roles como entrada para la
realización de sus actividades
 Resultado de las actividades realizadas por los roles
 Metamodelo: Clase rol tiene como métodos las
actividades y como parámetros los artefactos

Flujos de trabajo
 Forma de describir significativamente la secuenciencias
de actividades que producen resultados y las
interacciones entre cargos
 En términos de UML se puede utilizar: diagrama de
actividades, de secuencia, de colaboración
 En RUP hay nueve tipos de flujos de trabajo
– De ingeniería
 Negocio, Requerimiento, Análisis, Diseño, Pruebas, Liberación
– De soporte
 Administración del proyecto, Administración del cambio,
Ambiente

Dimensión dinámica
Concepción Elaboración Construcción Transición
ciclofase
Iter. 1 Iter. 2 Iter. 3 Iter. 4 Iter. 5 Iter. 6
hito 1 hito 2 hito 3 hito 4
Hito: punto en el tiempo en donde se evaluan objetivos
logrados y se pueden tomar decisiones críticas

Desarrollo iterativo
Ciclo de
desarrollo 1
Ciclo de
desarrollo 2
Ciclo de
desarrollo n
Perfeccionar
el plan
Sincronizar
Artefactos
Análisis Diseño Construcción Pruebas
Construcción

Fase de concepción
 Objetivo: definir la razón de ser y el alcance del
proyecto. Estudio de oportunidad.
– Visión = QUÉ + PARA QUÉ + CUÁNTO
 Actividades
– Especificación de los criterios de éxito del proyecto
– Definición de los requerimientos
– Estimación de los recursos necesarios
– Cronograma inicial de fases
 Artefactos
– Documento de definición del proyecto

Fase de elaboración
 Objetivo: establecer un plan de proyecto y una arquitectura
correcta del sistema
 Actividades
– Análisis del dominio del problema
– Definición de la arquitectura básica
– Análisis de riesgos
– Planificación del proyecto
 Artefactos
– Modelo del dominio
– Modelo de procesos
– Modelo funcional de alto nivel
– Arquitectura básica

Fase de construcción
 Objetivo: desarrollar el sistema a lo largo de
una serie de iteraciones
 Actividades
– Análisis
– Diseño
– Codificación
– Pruebas (individuales, de integración)

Objeto de Aprendizaje : Introducción a UML

Más contenido relacionado

La actualidad más candente (20)

Destacado (9)

Similar a Objeto de Aprendizaje : Introducción a UML (20)

Último (20)

Objeto de Aprendizaje : Introducción a UML