Transcript Clase modelo

Análisis del Proyecto
M.C. Juan Carlos Olivares Rojas
Marzo 2010
Competencias
• Específica: aplica técnicas de análisis para
mitigar los riesgos y mejorar la calidad del
software.
• Genéricas
• Instrumentales: Capacidad de análisis y
síntesis, Capacidad de organizar y planificar,
Conocimientos básicos de la carrera,
Comunicación oral y escrita en su propia
lengua, Habilidades de gestión de información,
Solución de problemas, Toma de decisiones.
Competencias
• Interpersonales: Capacidad crítica y autocrítica,
Capacidad de trabajar en equipo interdisciplinario,
Capacidad de comunicarse con profesionales de
otras áreas, Compromiso ético.
• Sistémicas:
Habilidades
de
investigación,
Capacidad de adaptarse a nuevas situaciones,
Capacidad de generar nuevas ideas (creatividad),
Liderazgo, Capacidad para diseñar y gestionar
proyectos, Iniciativa y espíritu emprendedor,
Preocupación por la calidad, Búsqueda del logro.
Saberes
• Análisis de Riesgos* (visto al final de la unidad
2)
• Control de Calidad
• Metodología OpenUP (Proceso Unificado)
• Técnicas de Análisis
Evidencias
• 10% Actividades realizadas en el salón de
clases evaluables
• 30% Desarrollo del proyecto (seguimiento de
actividades en base a su planeación)
• 60% Actividad de Evaluación Final (TeóricoPráctico)
Otra categoría de riesgos
Riesgos conocidos
Tipos de
Riesgos
Riesgos
Riesgos
Son aquellos que se pueden descubrir
con una cuidadosa evaluación del plan
del proyecto de su entorno técnico
Son
aquellos
que
predecibles podemos extrapolar de
proyectos anteriores o de
nuestra experiencia
Son
impredecibles extremadamente
difíciles de identificar
*Los riesgos se deben identificar y tratar de minimizarlos
**Se deben priorizar los riesgos
Ejemplo de Riesgos
Riesgo
Tipo de riesgo
Rotación del personal
Proyecto
Cambio de administración
Proyecto
Hardware indisponible
Proyecto
Cambio de requerimientos
Proyecto y producto
Retrasos en la especificación
Proyecto y producto
Subestimación del tamaño
Proyecto y producto
Bajo desempeño de la
herramienta CASE
Producto
Cambio de tecnología
Negocio
Competencia del producto
Negocio
Ejemplo de Riesgos
TIPO DE RIESGO
EJEMPLOS DE POSIBLES RIESGOS
o
Tecnología: se derivan de
tecnología de SW o HW
o
la base de datos que se utiliza en el sistema no puede procesar tantas
transacciones por segundo como se esperaba
los componentes de software a reutilizar tienen defectos que limitan su
funcionalidad
Personal: asociadas al equipo de
desarrollo
o
o
imposible contratar personal con los conocimientos requeridos
personal clave enfermo o no disponible en momentos críticos
Organizacionales: al entorno
donde se desarrolla el
software
o
o
la organización se reestructura y una nueva administración se responsabiliza del
proyecto
los problemas financieros de la organización reducen el presupuesto del proyecto
Herramientas: asociado a
herramientas case y de
apoyo
o
o
las herramientas CASE generan código ineficiente
las distintas herramientas CASE no se pueden integrar
Requerimientos: derivado de los
cambios requeridos por el
cliente
o
o
cambios de requerimientos que precisan modificaciones en el diseño
los clientes no comprenden el impacto de los cambios en los requerimientos
Estimación: derivado de los
estimados administrativos y
los recursos requeridos
o
o
o
el tiempo requerido para desarrollar el software está subestimado
la tasa de reparación de defectos está subestimada
el tamaño del software está subestimado
Riesgos en OpenUP
Riesgos
técnicos
Riesgos No
técnicos
1. Riesgos relacionados con nuevas
tecnologías.
2. Riesgos relativos a la arquitectura.
3. Riesgos relativos a construir el sistema
adecuado, es decir, que cumpla con
su objetivo y con sus usuarios.
4. Riesgos relativos al rendimiento.
1. Gente sin experiencia en el proyecto
2. El calendario propuesto del cliente es muy
corto.
3. El cliente no realiza las aprobaciones en el
tiempo establecido
4. Existan terceras personas subcontratadas
con las que no se ha trabajado antes.
Control de Riesgos
Riesgo
Estrategia
Problemas financieros de la
organización
Preparar un documento breve para la dirección de la empresa que muestra que el
proyecto hace contribuciones muy importantes a las metas del negocio
Problemas de reclutamiento
organizar cursos de capacitación para el personal ya existente, investigar la
posibilidad de contratar en otras regiones o países
Enfermedad del personal
reorganizar el equipo de tal forma que se solapen el trabajo y los miembros del
equipo comprendan el trabajo de los demás
Componentes defectuosos
reemplazar los componentes defectuosos con los comprados de fiabilidad conocida
Cambios en los requerimientos
rastrear la información para valorar el impacto de los requerimientos, maximizar la
información oculta en ellos
Reestructuración organizativa
preparar un documento breve para la dirección de la empresa que muestra que el
proyecto hace contribuciones muy importantes a las metas del negocio
Rendimiento de la base de datos
Tiempo de desarrollo subestimado
investigar la posibilidad de comprar una base de datos con el rendimiento preciso
alertar al cliente de las dificultades potenciales y las posibilidades de retraso
¿Qué tiene más calidad?
• Los dos tienen la
misma calidad
siempre y cuando
cumplan con sus
requerimientos
Para ello
debemos probar
sus
especificaciones
Calidad
del software
Introducción
• La calidad es un concepto muy asbtracto de
definir.
• Algunas definiciones básicas de calidad:
• Cualidad o conjunto de cualidades de una
persona o cosa que permiten compararla con
otras de su especie.
• Enfocadas
al
requerimientos.
cumplimiento
de
los
Calidad
del software
Introducción
• Orientados hacia la satisfacción del cliente.
• Orientados hacia la productividad (0 defectos)
• Tipos de Calidad
GESTIÓN DE
LA CALIDAD
Calidad
del software
Introducción
• Algunos ejemplos de falta de calidad en el
software:
• El programa no está probado
• El sistema operativo está incompleto
• No están escritos los requisitos
• Estamos fuera de tiempo en un proyecto
Control de Calidad
• Es una actividad que se debe desarrollar a lo
largo del proceso de desarrollo de software, el
cual incluye:
– Políticas de calidad
– Métodos y herramientas de software efectivo
– Revisiones Técnicas Formales
– Prueba Multiescalares
– Documentación
– Manejo de métricas e indicadores
– etc.
Control de Calidad
• La calidad debe de ser mensurable.
• La garantía o aseguramiento de la calidad (QA
, Quality Assurance) sólo se puede realizar a
través de un proceso de seguimiento, por lo
tanto la calidad también se planea en el sentido
de las técnicas que se usarán para lograr el
éxito del proyecto.
• La calidad como todo proceso tiene costo, pero
es más costoso no tener calidad.
Control de Calidad
• El proceso más básico de control de calidad es
la inspección, que en el área de desarrollo de
software son los RTF.
• Los RTF sirven de filtro para detectar y corregir
defectos. Generalmente se aplican en la etapa
de diseño que es donde hay más errores de
desarrollo (50-60%).
• Se debe de revisar al producto no al personal.
Control de Calidad
• El proceso más básico de control de calidad es
la inspección, que en el área de desarrollo de
software son los RTF.
• Los RTF sirven de filtro para detectar y corregir
defectos. Generalmente se aplican en la etapa
de diseño que es donde hay más errores de
desarrollo (50-60%).
• Se debe de revisar al producto no al personal.
Control de Calidad
• Se debe tener una agenda (plan de trabajo)
• Se deben evitar impugnaciones
• Los problemas se enuncian más no se
resuelven en ese momento
• Deben existir reuniones periódicas
• El control de calidad por excelencia es el
control estadístico.
OpenUP
• Originado como resultado de la compra de
Rational creador de RUP por parte de IBM.
• UP es toda una metodología para el desarrollo
de software:
Requisitos del usuario
Proceso de desarrollo
de software
Sistema de software
• Se caracteriza por ser una forma disciplinada de
asignar tareas y responsabilidades en una empresa
de desarrollo (quién hace qué, cuándo y cómo).
OpenUP
• Su objetivo es Asegurar la producción de software de
calidad dentro de plazos y presupuestos predecibles.
Dirigido por casos de uso, centrado en la arquitectura,
iterativo (mini-proyectos) e incremental (versiones).
• También es considerado un producto:
• Desarrollado y mantenido por la comunidad libre
• Actualizado constantemente para tener en cuenta las
mejores prácticas de acuerdo con la experiencia.
OpenUP
• Aumenta la productividad de los desarrolladores
mediante acceso a:
• Base de conocimiento, plantillas y herramientas.
• Se centra en la producción y mantenimiento de
modelos del sistema más que en producir
documentos.
• UP es una guía de cómo usar UML de la forma más
efectiva.
• Existen herramientas de apoyo a todo el proceso:
Modelamiento visual, programación, pruebas, etc.
OpenUP
• UP pretende implementar las mejores prácticas
actuales en ingeniería de software:
•
•
•
•
•
•
Desarrollo iterativo del software
Administración de requerimientos
Uso de arquitecturas basadas en componentes
Modelamiento visual del software
Verificación de la calidad del software
Control de cambios
OpenUP
• Desarrollo Iterativo:
• El software moderno es complejo y novedoso. No es
realista usar un modelo lineal de desarrollo como el
de cascada.
• Un proceso iterativo permite una comprensión
creciente de los requerimientos a la vez que se va
haciendo crecer el sistema.
• UP sigue un modelo iterativo que aborda las tareas
más riesgosas primero. Con esto se logra reducir los
riesgos del proyecto y tener un subsistema ejecutable
tempranamente.
OpenUP
• Administración de Requerimientos:
• Obtener los requerimientos
• Organizarlos
• Documentar requerimientos
restricciones
de
funcionalidad
• Rastrear y documentar decisiones
• Captar y comunicar requerimientos del negocio
y
OpenUP
• Arquitectura basada en Componentes:
• El proceso se basa en diseñar tempranamente una
arquitectura base ejecutable.
•
•
•
•
•
La arquitectura debe ser:
Flexible
Fácil de modificar
Intuitivamente comprensible
Promueve la reutilización de componentes
OpenUP
• Modelamiento visual de la estructura y el
comportamiento de la arquitectura y los componentes.
•
•
•
•
•
•
Bloques de construcción:
Ocultan detalles
Permiten la comunicación en el equipo de desarrollo
Permiten analizar la consistencia:
entre las componentes
entre diseño e implementación
OpenUP
• Verificación de cualidades:
• No sólo la funcionalidad es esencial, también el
rendimiento y la confiabilidad.
• UP ayuda a planificar, diseñar, implementar, ejecutar
y evaluar pruebas que verifiquen estas cualidades.
• El aseguramiento de la calidad es parte del proceso
de desarrollo y no la responsabilidad de un grupo
independiente.
OpenUP
• Control de Cambios:
• Los cambios son inevitables, pero es necesario
evaluar si éstos son necesarios y rastrear su impacto.
• UP indica como controlar, rastrear y monitorear los
cambios dentro del proceso iterativo de desarrollo.
OpenUP
• UP divide el proceso de desarrollo en ciclos, teniendo
un producto al final de cada ciclo.
• Cada ciclo se divide en cuatro Fases:
•
•
•
•
Inicio
Elaboración
Construcción
Transición
• Cada fase concluye con un hito bien definido donde
deben tomarse ciertas decisiones.
OpenUP
• Fases de UP
OpenUP
• Fase de Inicio
• Se establece la oportunidad y alcance el proyecto.
• Se identifican todas las entidades externas con las
que se trata (actores) y se define la interacción a un
alto nivel de abstracción:
• Identificar todos los casos de uso
• Describir algunos en detalle
OpenUP
• La oportunidad del negocio incluye:
•
•
•
•
Criterios de éxito
Identificación de riesgos
Estimación de recursos necesarios
Plan de las fases incluyendo hitos
– Productos:
– Un documento de visión general:
•
•
•
•
•
Requerimientos generales del proyecto
Características principales
Restricciones
Modelo inicial de casos de uso (10% a 20 % listos).
Glosario.
OpenUP
• Caso de negocio:
•
•
•
•
Contexto
Criterios de éxito
Pronóstico financiero
Identificación inicial de riesgos.
• Plan de proyecto.
• Uno o más prototipos.
OpenUP
• Hito:
Objetivos del
Ciclo de Vida
Inicio
Elaboración
Construcción
Transición
– Las partes interesadas deben acordar el alcance y la
estimación de tiempo y costo.
– Comprensión de los requerimientos plasmados en
casos de uso.
OpenUP
• Fase de Elaboración
• Objetivos:
•
•
•
•
Analizar el dominio del problema
Establecer una arquitectura base sólida
Desarrollar un plan de proyecto
Eliminar los elementos de mayor riesgo para el desarrollo
exitoso del proyecto
• Visión de “una milla de amplitud y una pulgada de
profundidad” porque las decisiones de arquitectura
requieren una visión global del sistema.
OpenUP
• Productos:
• Es la parte más crítica del proceso
• Se puede decidir si vale la pena seguir adelante
• A partir de aquí la arquitectura, los requerimientos y
los planes de desarrollo son estables.
• Ya hay menos riesgos y se puede planificar el resto
del proyecto con menor incertidumbre.
OpenUP
• Se construye
contemple:
una
arquitectura
ejecutable
que
• Los casos de uso críticos
• Los riesgos identificados
• Modelo de casos de uso (80% completo) con
descripciones detalladas.
• Otros requerimientos no funcio-nales o no asociados
a casos de uso.
• Descripción de la Arquitectura del Software.
OpenUP
• Un prototipo ejecutable de la arquitectura.
• Lista revisada de riesgos y del caso de negocio.
• Plan de desarrollo para el resto del proyecto.
• Un manual de usuario preliminar.
OpenUP
• Hito:
Arquitectura de
Ciclo de Vida
Concepción
•
•
•
•
Elaboración
Construcción
Transición
Condiciones de éxito de la elaboración:
¿Es estable la visión del producto?
¿Es estable la arquitectura?
¿Las pruebas de ejecución demuestran que los
riesgos han sido abordados y resueltos?
• ¿Es el plan del proyecto algo realista?
• ¿Están de acuerdo con el plan todas las personas
involucradas?
OpenUP
• Construcción:
• En esta fase todas las componentes restantes se
desarrollan e incorporan al producto. Todo es probado
en profundidad.
• El énfasis está en la producción eficiente y no ya en la
creación intelectual.
• Puede hacerse construcción en paralelo, pero esto
exige una planificación detallada y una arquitectura
muy estable.
OpenUP
• Productos:
• El producto de software integrado y corriendo en la
plataforma adecuada.
• Manuales de usuario.
• Una descripción del “release” actual.
OpenUP
Capacidad
Operacional
• Hito:
Concepción
Elaboración
Construcción
Transición
• Se obtiene un producto Beta que debe decidirse si
puede ponerse en ejecución sin mayores riesgos.
• Condiciones de éxito:
• ¿El producto está maduro y estable para instalarlo en
el ambiente del cliente?
• ¿Están los interesados listos para recibirlo?
OpenUP
• Transición:
• El objetivo es traspasar el software desarrollado a la
comunidad de usuarios.
• Una vez instalado surgirán nuevos elementos que
implicarán nuevos desarrollos (ciclos).
• Incluye:
• Pruebas Beta para validar el producto con las expectativas
del cliente
• Ejecución paralela con sistemas antiguos
OpenUP
• Conversión de datos
• Entrenamiento de usuarios
• Distribuir el producto
• Los objetivos de la fase de transición:
• Obtener autosuficiencia de parte de los usuarios.
• Concordancia en los logros del producto de parte de
las personas involucradas.
• Lograr el consenso cuanto antes para liberar el
producto al mercado.
OpenUP
• Hito:
Concepción
Elaboración
Construcción
Transición
Producto
• En esta etapa se obtiene el software final.
OpenUP
• Definiciones:
• Un trabajador define el comportamiento y las
responsabilidades de un individuo.
• Es como un “sombrero” que la persona usa durante el
proyecto:
• Una persona puede tener varios sombreros
• Es el rol que desempeña en un momento dado
• Responsabilidades:
• Hacer una serie de actividades
• Ser el responsable de una serie de artefactos
OpenUP
• Actividades:
• Una actividad es una unidad de trabajo que se asigna
a un trabajador. Ej.:
• Crear o modificar un artefacto
• Una actividad lleva entre un par de horas y un par de
días, involucra un solo trabajador y un número
pequeño de artefactos.
OpenUP
• Las actividades se consideran en la planificación y
evaluación del progreso del proyecto.
•
•
•
•
•
Ejemplos:
Planificar una iteración - Administrador de proyecto
Encontrar actores y casos de uso - Analista
Revisar el diseño - Revisor de diseño
Ejecutar pruebas de performance - Ing. de pruebas de
performance
OpenUP
• Asignación de Actividades:
Trabajador
Actividad
Pablo
Diseñador
Diseño de Objetos
María
Autor de Casos de Uso
Detallar un Caso de Uso
José
Diseñador de Casos de Uso
Diseñar un Caso de Uso
Silvia
Revisor de Diseño
Revisar el Diseño
Arquitecto
Análisis de Arquitectura
Diseño de Arquitectura
Recurso
Eduardo
OpenUP
• Artefactos:
• Elementos de información producidos, modificados o
usados por el proceso.
• Son los productos tangibles del proyecto.
• Son usados por los trabajadores para realizar nuevas
actividades y son el resultado de esas actividades.
OpenUP
• Flujos de Trabajo:
• Una lista de actividades, trabajadores y artefactos
constituye un proceso.
• Un flujo de trabajo es una secuencia de actividades
que produce un resultado valioso.
• No siempre es posible representar flujos de trabajo.
OpenUP
• Flujos de Trabajo:
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
OpenUP
• Flujos de Trabajo Esenciales:
Flujos de Trabajo
de Ingeniería
Flujos de Trabajo
de Apoyo
OpenUP
• Existen
habitualmente
problemas
de
comunicación entre ingenieros de software e
ingenieros de negocios.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
• UP proporciona un lenguaje y proceso común
para estos dos ámbitos.
• Para el modelamiento del negocio se usan
“business use cases” (casos de uso del
negocio):
• La forma en que el software dará apoyo al
negocio.
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
OpenUP
• Requerimientos:
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
• Los desarrolladores y clientes deben acordar
qué es lo que el sistema debe hacer:
Arquitecto
Análisis de
Casos de Uso
•
•
•
•
•
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
Relevar requerimientos
Documentar funcionalidad y restricciones
Documentar decisiones
Identificar actores
Identificar casos de uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
OpenUP
• Los casos de uso describen la funcionalidad.
• Los requerimientos no funcionales se incluyen
en una especificación complementaria.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
I
m
p r
im
ir
I
n f
o r
Diseñador
C lie n t
e
Revisor de
Diseño
O
R e c ic la r
Revisar el
A d
Análisis
m
Revisar el
in is
Diseño
t
Revisar la
rArquitectura
a r
p e r
a
D e p ó
OpenUP
• Análisis y Diseño:
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
• Descripción de cómo se implementará el
sistema: un plano
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
• Debe:
• Ejecutar las tareas y funciones descritas en los
casos de uso
• Satisfacer todos los requerimientos
• Flexible a cambios
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
OpenUP
• El diseño se
arquitectura.
centra
Análisis de
Arquitectura
Diseño de
Arquitectura
en
la
Describir
Concurrencia
noción
de
Describir
Distribución
Arquitecto
• Diseñar y validar la arquitectura es una tarea
esencial.
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
• El modelo de diseño consta de
• Clases estructuradas en paquetes
• Diseños de subsistemas con interfaces
definidas (componentes)
• Forma de colaboración entre las clases.
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
OpenUP
• Implementación
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
• Propósito:
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
• Definir la organización del código
• Implementar clases y objetos en forma de
componentes (fuente, ejecutables, etc.)
• Probar las componentes desarrolladas
• Integrar las componentes en un sistema
ejecutable
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
OpenUP
• Pruebas:
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
• Propósito:
• Verificar la interacción entre los objetos
• Verificar
la
integración
apropiada
de
componentes
• Verificar que se satisfacen los requerimientos
• Identificar los defectos y corregirlos antes de la
instalación
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
OpenUP
• UP describe como planear y ejecutar estas
pruebas.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
• UP propone probar las componentes desde el
principio:
• Confiabilidad, funcionalidad y performance
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
• Las pruebas de regresión son importantes en
desarrollos iterativos.
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
OpenUP
• Distribución:
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
• Producir un producto y hacerlo llegar a sus
usuarios finales.
Arquitecto
Análisis de
Casos de Uso
•
•
•
•
•
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
Incluye varias actividades:
Producir un “release”
Empaquetar el software
Distribuir el software
Instalar el software
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
OpenUP
• Administración de Proyectos:
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
• Es el arte de balancear objetivos contrarios,
manejar riesgos y producir software que
satisface a clientes y usuarios.
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
• UP incluye:
Análisis de
Objetos
Diseño de
Objetos
Diseñador
• Un framework para manejo de proyectos de
software
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
OpenUP
• Guías para planificación, provisión de personal,
ejecución y monitoreo de planes
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
• Un framework para manejar riesgos
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
• Administración de Configuración y del Cambio:
Análisis de
Objetos
Diseño de
Objetos
• Forma de controlar los artefactos producidos
por las personas que trabajan en el proyecto.
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
OpenUP
• Algunos problemas habituales:
• Actualizaciones simultáneas
• Múltiples versiones
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
•
•
•
•
Análisis de
Casos de Uso
Diseño de
Casos de Uso
UP da guías para:
Desarrollos en paralelo
Automatizar la construcción
Administrar defectos
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
OpenUP
• Ambiente:
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
• Ambiente y herramientas de desarrollo que
harán posible llevar a cabo el proyecto.
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
• UP guía en la configuración de un ambiente de
proceso apropiado a cada proyecto.
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
Modelado
•
Es la primera fase creativa del desarrollo de
proyectos. Se compone de lo qué es análisis
y diseño.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
•
Análisis de
Casos de Uso
Diseño de
Casos de Uso
El modelado parte de lo que es la Ingeniería
de Requerimientos y devuelve un modelo que
puede ser construido (implantable a través de
lenguajes de programación).
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
Modelado
• En análisis estructurado se utiliza la técnica de
Diagrama de Flujo para especificar procesos,
Diagrama Entidad-Relación para especificar
datos y diagramas de transición de estados
para control. Diagramas de contexto o de Flujo
de Datos Nivel 1 para indicar arquitectura.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
• Para el modelado de datos se recomienda
definir todos los objetos (entidades) y definir
sus atributos.
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
Modelado
• El diseño es la primera parte del desarrollo de
cualquier proyecto.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
• Etimológicamente significa componer, por lo
que se obtiene la solución que habrá de
implantarse.
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
• Todas las cosas siempre tienen primero una
creación mental.
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
Modelado
• El diseño en proyectos informáticos presenta
cuatro apartados: datos, arquitectura, interfaz y
procedimientos.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
• El diseño de datos se encarga de transformar
el modelo de información obtenido en el
proceso de análisis en estructuras de datos. Se
pueden utilizar diagramas entidad-relación pero
especificados a mayor detalle.
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
Modelado
• El diseño arquitectónico tiene la finalidad de
comprobar las relaciones con los diferentes
módulos o macrorequisitos del sistema
(subsistemas).
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
• El diseño de interfaz define como se comunica
el software consigo mismo y hacia el exterior.
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
Modelado
• El diseño procedimental o basado en
componentes consiste en la traducción de cada
uno de los elementos obtenidos en la
especificación de procesos, datos y transición
hacia elementos implantables a través de
computadoras.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
Modelado
• El proceso de diseño sirve de base para la
codificación del sistema. Se deben seguir
algunas recomendaciones para su mejor
desarrollo como las siguientes:
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
• Se deben especificar todos los elementos
explícitos e implícitos del modelo de análisis.
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
Modelado
• El diseño deber servir de guía para que cual
integrante del proyecto pueda construir y
entender el software.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
• El diseño debe de dar una completa idea de lo
que es el software.
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
• El diseño debe presentar uniformidad e
integración. Se deben definir reglas y estilos
que deben seguir los miembros del equipo.
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
Modelado
• El diseño debe estar estructurado, de tal forma
que permita cambios.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
• El diseño no es escribir código, ni codificar es
diseñar.
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
• Al diseñar se deben tomar en cuenta Factores
de Calidad Externos (velocidad, Fiabilidad,
utilidad) y Factores de Calidad Interno
(abstracción, refinamiento, modularidad).
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
UML
•
UML (Unified Modelling Language), lenguaje
de modelado unificado. Fue desarrollado en
1997 al fusionar las metodologías de Ivar
Jacobson, Jame Rumbaugh y Grady Booch.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
Análisis de
Casos de Uso
•
Diseño de
Casos de Uso
Es un lenguaje visual, su premisa básica
radica en que una imagen vale más que 1,000
líneas de código.
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
UML
• Al ser UML un lenguaje posee gramáticas y
alfabetos que definen como deben de
estructurarse cada una de las palabras válidas
del lenguaje.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
• Un modelo es una representación de la
realidad. No sólo se modela software sino
prácticamente cualquier actividad.
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
UML
• Es el lenguaje estándar para modelar proyectos
de software.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
• La versión más actual del lenguaje es la 2.2
definida en 2009.
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
• Los métodos que se fusionaron para crear UML
fueron OMT (Rumbaugh), Objectory (Jacobson)
y el método Booch.
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
UML
• Casi el 80% de los proyectos de software
fallan.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
• Nadie construye una casa sin un plano.
Análisis de
Casos de Uso
Diseño de
Casos de Uso
• Actualmente existen muchas herramientas que
auxilian el proceso de modelado como Visio,
ArgoUML, Rational Rose, Together, etc.
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
Modelos
• Los modelos deben ser más baratos que la
realidad.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
• Es más fácil para una persona entender un
diagrama que las líneas de código fuente de un
programa.
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
• Los diagramas al igual que el texto consumen
tiempo.
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
Modelos
• Se deben construir modelos que sean
representativos
para
que
sean
útiles
(imaginense hacer un documento de 100 hojas
que nadie va a leeer)
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
• UML define varios tipos de diagramas los
cuales pueden ser extensibles.
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
UML
• UML tiene 5 diferentes vistas con diferentes
diagramas en cada una de ellas.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
• Vista usuario: representa el sistema (producto)
desde la perspectiva del usuario. Se suele
utilizar diagramas de casos de uso.
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
UML
• Vista estructural: modela los datos y la
funcionalidad del sistema; es decir, la
estructura estática (clases y relaciones).
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
• Vista de implementación: Los aspectos
estructurales y de comportamiento se
representan aquí tal y como van a ser
implementados. (Diagrama de actividades y
estados)
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
UML
• Vista del comportamiento: representa los
aspectos dinámicos o de comportamiento del
sistema. También muestra las interacciones o
colaboraciones entre los diversos elementos
estructurales descritos en vistas anteriores.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
• Vista del entorno: aspectos estructurales de
comportamiento en el que el sistema a
implementar se representa (diagramas de
componentes y despliegue).
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
UML
• Los diagramas más utilizados en UML son:
Análisis de
Arquitectura
•
•
•
•
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Diagramas de casos de uso
Diagramas de actividades
Diagramas de clases
Diagramas de interacción
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
Análisis de
Objetos
– Diagramas de secuencia
Diseñador
– Diagramas
de colaboración
Revisor de
Diseño
Revisar el
Análisis
Diseño de
Objetos
Revisar el
Diseño
Revisar la
Arquitectura
UML
• Diagramas de estado
• Diagramas de componentes
• Otros diagramas
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
– Diagrama de topología
delDiseño
despliegue
Análisis de
de
Casos de Uso
Casos de Uso
Diseñador de
Casos de Uso
• Los diagramas deben de reflejar lo que se
pretende modelar
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
Preguntas Frecuentes
• ¿Cuántos diagramas debo crear? No existe
una respuesta específica.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
• ¿Debo hacer diagramas de todo tipo? No, sólo
se deben utilizar los diagramas que mejor
reflejen el modelado de la problemáticao.
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
Preguntas Frecuentes
• ¿Qué tan grande debe de ser un diagrama?
Entre más grande sea un diagrama mayor es la
confusión. Se deben realizar diagramas bien
detallados, pero no tan detallados.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
• ¿Cuánto texto debe complementar el modelo?
Entre menos texto mejor, son como los
comentarios del código fuente: pocos pero
claros.
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
Recomendaciones
• Algunas recomendaciones para el modelado de
software son:
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
• No tenga a los programadores esperando los
modelos.
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
• Trabajar
de
una
macrovista
microvista(enfoque Top-Down).
Análisis de
Objetos
a
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
una
Recomendaciones
• Se debe documentar en forma económica.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
• Si es obvio no se debe de modelar.
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
• Hacer hincapié en la especialización.
Diseñador de
Casos de Uso
Análisis de
Objetos
• Utilizar patrones de diseño.
Diseño de
Objetos
Diseñador
• Refactorizar.
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
Recomendaciones
•
Es la primera fase creativa del desarrollo de
proyectos. Se compone de lo qué es análisis
y diseño.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
•
Análisis de
Casos de Uso
Diseño de
Casos de Uso
El modelado parte de lo que es la Ingeniería
de Requerimientos y devuelve un modelo que
puede ser construido (implantable a través de
lenguajes de programación).
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
Software
•
Se necesita de una aplicación para móviles
que permita la captura de requerimientos a
través de casos de uso.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
•
Análisis de
Casos de Uso
Diseño de
Casos de Uso
La aplicación deberá de
múltiples dispositivos móviles
una interfaz de usuario
minimicé el uso del teclado
dedo.
Diseñador de
Casos de Uso
Análisis de
Objetos
funcionar en
y deberá tener
amigable que
o del stylus o
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
Software
•
La aplicación deberá integrarse al sistema
existente de requerimientos de la empresa a
través de Internet.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
•
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Al momento de establecer un nuevo caso de
uso se deberá especificar el nombre en forma
textual. La descripción del escenario se hará
a través de grabación de audio o bien a través
de texto utilizando una interfaz acotada de
comandos en lenguaje natural (por ejemplo
en la funcionalidad)
Diseñador de
Casos de Uso
Análisis de
Objetos
Diseño de
Objetos
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
Software
•
La aplicación deberá generar el modelado
visual del caso de uso donde el usuario
deberá seleccionar componente actor y darle
su nombre así como agregar de la descripción
textual los casos de uso y las relaciones de
dependencia.
Análisis de
Arquitectura
Diseño de
Arquitectura
Describir
Concurrencia
Describir
Distribución
Arquitecto
Análisis de
Casos de Uso
Diseño de
Casos de Uso
Diseñador de
Casos de Uso
•
Análisis de
Objetos
Diseño de
Objetos
Se puede contar a su vez con una descripción
gráfica del caso de uso.
Diseñador
Revisor de
Diseño
Revisar el
Análisis
Revisar el
Diseño
Revisar la
Arquitectura
Diseño Modular Efectivo
• La independencia funcional se mide en base a
dos criterios: cohesión y acoplamiento.
• Cohesión: es una extensión del principio de
ocultamiento de información,
es deseable
tener una alta cohesión. Esta se obtiene
cuando un módulo realiza una tarea sencilla sin
depender de otros módulos
Diseño Modular Efectivo
• El acoplamiento es una medida de
interconexión de los módulos. Es necesario
tener un bajo acoplamiento. El acoplamiento se
mide en las relaciones que guardan los
módulos con sus interfaces de entrada y salida.
• Hay tres tipos de acoplamiento: común, de
datos y control.
Diseño Arquitectónico
• El concepto de Arquitectura de Software tiene
mucho tiempo de antigüedad, pero no fue hasta
la década de los 1990s que comenzó a
utilizarse de manera formal.
• Analizando los sistemas se puede observar que
existen patrones que se repiten conformando lo
que se conoce como estilos arquitectónicos.
Diseño Arquitectónico
• Un estilo arquitectónico define un conjunto de
familias de patrones de software con una
determinada estructura y restricciones.
• Generalmente los patrones de diseño y
arquitectura definen soluciones para medios
repetitivos.
• La arquitectura de software es una abstracción
del sistema que nos permite ver su estructura y
su relaciones.
Diseño Arquitectónico
• La Arquitectura Centrada en Datos tiene como
componente principal un repositorio, del cual
surgen los demás componentes.
• Las Arquitecturas Estratificadas son de las más
utilizadas en la actualidad, dado que dividen las
actividades y responsabilidades de sistemas
por capas.
• El software más elaborado como los sistemas
operativos, software de base, sistemas
distribuidos y otros maneja variantes de esta
Diseño Arquitectónico
• Se definen las estructuras de datos generales y
globales.
• Se anotan todas las limitaciones/restricciones
del sistema.
• Se debe refinar el diseño hasta que esté
completo. Se recomienda completar la
arquitectura con el Diseño de Interfaces.
Diseño de Interfaz de Usuario
• El diseño de interfaces se refiere al estudio de
las relaciones entre los usuarios y las
computadoras para que un sistema se pueda
ejecutar.
• El diseño de una interfaz puede definir el éxito
de cualquier proyecto, ya que la utilización de
cualquier interfaz de usuario depende de
factores humanos.
Diseño de UI
• Existen algunas reglas de oro para el buen
diseño de Interfaces de Usuario:
• Dar el control al usuario
• Reducir la carga de memoria del usuario
• Construir una interfaz consecuente
Diseño Procedimental
• Se pueden utilizar mecanismos como los
diagramas de flujo, los diagramas de caja (NSChapin), Lenguaje de Diseño de Programación
(Pseudocódigo).
• El diseño procedimental debe de ser:
• Simple (leer, usar y entender)
• Modular
• Fácil de editar
Documentación del Diseño
• Diseño de Datos:
– Objetos de Datos
– Estructuras de archivos y base de datos (estructura
lógica, métodos de acceso, datos)
• Diseño arquitectónico:
– Revisión de datos y flujos de control
– Estructura del Programa
Documentación del Diseño
• Diseño de Interfaz:
– Especificación HMI
– Normas de diseño de la HMI
– Diseño de la interfaz externa (con datos y sistemas
externos)
– Normas de diseño de la interfaz interna.
• Diseño procedimental:
– Los pasos siguientes se deben hacer para cada
módulo.
Documentación del Diseño
– Descripción del proceso
– Descripción de la interfaz
– Descripción del lenguaje de diseño
– Módulos usados
– Estructuras de datos internas
• Referencias cruzadas de requisitos: esta
sección es opcional, sirve para llevar el control
de donde se están satisfaciendo los
requerimientos del modelo de análisis.
Documentación del Diseño
• Recursos de prueba:
– Directrices para las pruebas
– Estrategias de integración
– Consideraciones especiales
• Notas especiales:
– Apéndices
Diagramas de actividades
• Es la versión UML de un diagrama de flujo.
• Se usan para analizar los procesos y realizar la
ingeniería de los mismos.
• Es una excelente herramienta para analizar
problemas.
Diagramas de actividades
• Son
diagramas
que
representan
carácterísticas de los procesos.
• Estos
diagramas
deben
implementación del sistema.
facilitar
las
la
• Van enfocados a los expertos del dominio
(programadores y analistas).
Diagrama de actividades
• Pueden modelar procesos lineales y paralelos.
• Los diagramas deben ser más simples que
detallados.
• Los elementos principales son: nodo inicial,
flujo, actividades, conectores.
Diagramas de actividades
• Se pueden utilizar clavijas para conectar dos
nodos de acción.
• Los nodos de decisión son importantes para
bifurcar el flujo de actividades.
• Los nombres y los verbos nos sirven para
determinar las clases y los métodos.
Diagramas de actividades
• Los casos de uso son candidatos a desarrollar
diagramas de actividades.
• Las condiciones previas y posteriores se
manejan con el uso de guardianes.
• Los nodos de decisión también sirven para
fusionar diversos flujos en uno solo.
Diagramas de actividades
• Los carriles sirven para delimitar quien es el
responsable de una serie de actividades.
• Los carriles formalmente se llaman partición de
actividades y puede haber varios siempre y
cuando no se encimen.
• Se puede modelar el tiempo a través de
señales.
Diagramas de Actividades
Diagramas de clases
• Se usan para mostrar las clases de un sistema
y las relaciones entre ellas.
• Muestran la vista estática del sistema; no
describen los comportamientos ni la forma en
como interactuan las clases del sistema.
Diagramas de clases
• Los elementos del lenguaje son unos
rectángulos denominados clases y los
conectores representan las relaciones.
• Las clases pueden tener comportamientos y
atributos. Lo difícil no es encontrar las clases
sino definir sus relaciones
Diagramas de clases
• Un diagrama de objetos es similar a un
diagrama de clases pero representa un
comportamiento dinámico.
• Los objetos se distinguen al subrayar el nombre
de la clase.
• Las interfaces son clases abstractas puras.
Diagramas de clases
• Las interfaces se usan cuando las partes de las
cosas tienen facetas semánticamente similares
pero no tienen genealogía relacionada.
• Se utiliza el estereotipo interface. Los tipos de
datos pueden variar dependiendo de la
implementación.
Diagramas de clases
• El símbolo + se usa para describir datos
públicos. El símbolo - para datos privados y #
un dato no es ni público ni privado (protegido).
• Para acceder a datos privados y/o protegidos
se deben utilizar métodos get/set
Diagramas de clases
• Los atributos funcionan como asociación. La
multiplicidad de las relaciones es importante.
• Si los valores superiores e inferiores de las
relaciones son iguales (1..1) se pone un solo
número (1).
Diagramas de clases
• Es común hablar de elementos opcionales,
obligatorios, de un solo valor y valores múltiples.
• El 80% de los diagramas de clase utilizan
relaciones simples.
• Si existe una flecha en la asociación se dice
que ésta es dirigida o direccional.
Diagramas de clase
• La agregación se representa con un diamante
hueco; mientras que la composición es un
diamante relleno.
• La generalización o herencia se refiere a una
relación del tipo es un.
• En una relación de herencia la clase hijo
hereda las carácterísticas de la clase padre.
Diagramas de clase
• Las relaciones de realización se utilizan en
interfaces para definir que la clase hija
implementará esa interfaz. Se utiliza una línea
punteada con un diamante parecido a la
herencia.
• Las relaciones de dependencia se dan entre
dos clases denominadas cliente y proveedor.
Se representa con una línea punteada con
flecha sencilla.
Diagramas de clase
• Los paquetes tienen la apariencia de una
carpeta de archivos. Se usa para representar
un nivel más avanzado de abstracción. Se
utilizan para organizar las clases, generalmente
representan un espacio de nombres.
• Los espacios de nombres solucionan el
problema de tener clases diferentes con el
mismo nombre.
Diagramas de clase
• Algunas
herramientas
soportan
la
documentación del modelo, pero no forma
parte del estándar.
• UML tiene datos primitivos: Integer, Boolean,
String y UnlimitedNatural, pero se pueden
utilizar otros tipos de datos definidos por el
estereotipo primitivo, solo hay que definir sus
componentes y sus operadores.
Diagramas de clases
• Los espacios de nombre se anteponen al de la clases
con el operador de alcance: ::
• Existen dos modalidades para el desarrollo de
software orientado a objetos: consumo (Visual Basic)
y Producción (Visual C++).
• La técnica de nombres son clases, verbos son
métodos sólo funciona en el 20% de los casos.
Diagramas de clases
• Se recomienda realizar un análisis de dominio
ya que nos ayuda a encontrar clases frontera,
de control y entidad.
• Las clases frontera interconectan elementos
del exterior con elementos del interior. Las
clases
de
entidad
representan
datos
(generalmente persistentes). Las clases de
control representan interacciones entre el
sistema.
Diagramas de clases
• La refactorización y los patrones de diseño
ayudan a mejorar los diagramas de clases.
• La herencia múltiple se puede modelar en UML
pero no es recomendable hacerlo. Es mejor
usar la composición o herencia de interfaces.
• “El mal se encuentra en los detalles”.
Diagramas de Clases
Diagramas de secuencia
• Muestran la parte dinámica del sistema.
• Muestran los mensajes que se envían las clases con
respecto al tiempo.
• Los diagramas de secuencia muestran un orden a
través del tiempo.
• Un diagrama de secuencia es más fácil de leer que
uno de colaboración.
Diagramas de secuencia
• Existen muchos diagramas en UML que resultan
redundantes, ya que dicen exactamente lo mismo
pero en diferente forma.
• Los elementos esenciales son las líneas de vida y los
mensajes.
• La línea de vida representa un ejemplo de clase
Diagramas de secuencia
• Las líneas de vida pueden ser actores u objetos.
• La activación de una línea de vida se hace a
través de un rectangulo sobre la línea de vida.
Un objeto puede crearse y destruirse varias
veces dentro de la ejecución de un sistema.
Diagramas de secuencia
• Los mensajes forman una parte importante de
este diagrama. Si se tiene una flecha triangular
representa un mensaje síncrono, si se tiene
una flecha abierta se representa un mensaje
asíncrono, los mensajes de retorno se
representan con flechas punteadas, mientras
que un mensaje anidado inicia y termina en la
misma línea de vida.
Diagramas de secuencia
• Los marcos de interacción o fragmentos
combinados son nuevos en UML 2.
• Son regiones rectangulares que se usan para
organizar los diagramas de interacción.
• Los marcos de interacción más comunes son:
alt, bucle, neg, opt, par, ref, regio rod
Diagramas de secuencia
• En un futuro no tan lejano, los diseños deberán
ser tan detallados como los circuitos eléctricos.
• En algunos casos es mejor usar diagramas de
colaboración, debido a la sencillez de su diseño.
Diagramas de Secuencia
Diagramas de interacción
• También muestran la parte dinámica del sistema.
• Organizan las clases y los mensajes en forma
espacial. Como no lleva ordenación del tiempo los
mensajes se enumeran.
• Los diagramas de secuencia e interacción son
complementarios y en algunos casos no es
aconsejable utilizar ambos.
Diagramas de colaboración
• También se les llama
comunicación en UML 2.
diagrama
de
• Los elementos son un rectángulo llamado
papel clasificador que representa los objetos,
conectores y una secuencia que indica los
mensajes. En UML la secuencia se numera
como 1, 1.1, 1.2, … en lugar de 1, 2, 3
Diagramas de colaboración
• Un diagrama de interacción se puede pasar a
código. Los objetos son instancias de clases y
los mensajes son métodos, los cuales se
codifican en la clase del receptor no del
llamador.
• En diagramas donde existen muchos mensajes
se necesitan de más notas para poder explicar
el diagrama.
Diagramas de colaboración
Diagramas de estado
• Muestra el estado cambiante de un objeto.
• UML es un lenguaje relativamente sencillo ya
que utilizando poco vocabulario se puede
realizar la mayoría del modelado de un sistema.
Diagramas de estado
• Sirven para representar máquinas de estados
(e.g. autómatas).
• Son ideales para representar procesos de red y
de tiempo real.
• La creación de diagramas de interfaces
gráficas de usuarios no es parte del estándar
UML.
Diagramas de estado
• Los diagramas de estado y actividades
comparten mucha de la simbología por lo que
se les suele confundir con frecuencia.
• Los estados son activos cuando se ejecutan su
actividad de entrada. Se vuelven inactivos
después de ejecutar su actividad de salida
Diagramas de estado
• Las actividades comunes son algo que sucede
de manera instantánea; mientras que una
actividad inicia con el prefijo “hacer/” es una
actividad de hacer.
• Un estado simple no está dividido en regiones.
En un estado compuesto cada región
representa una subactividad.
Diagramas de estado
• Las transacciones son líneas dirigidas que
conectan estados. Pueden ocurrir en base a
algún mecanismo de disparo.
• Las máquinas de estado de protocolo se
utilizan para describir interfaces.
Diagramas de estado
Diagramas de componentes
• Muestra los subsistemas del producto final.
• No es un diagrama ampliamente utilizado en
UML.
• Existen dos métodos para el diseño basado en
componentes: diseño componentes-interfaz
(arriba abajo) y a partir de clases.
Diagramas de componentes
• El símbolo de componente cambió en UML 2 a
un diagrama más simple.
• Se utiliza generalmente para modelar sistemas
muy grandes.
• Sistemas basados en red y distribuidos pueden
modelarse bien con este diagrama.
Diagrama de despliegue
• Se utiliza para modelar la forma en como lucirá
el sistema cuando se ponga en uso.
• Los nodos representan componentes físicos
que pueden ser computadoras, sistemas
operativos, entornos, servidores, etc.
• Ayudan al proceso de instalación de un sistema
Diagrama de despliegue
• Los artefactos son las cosas que se están
desplegando. Usan el estereotipo artefacto y
pueden ser achivos exe, dll, HTML, .jar, scripts,
etc.
• Dentro de cada nodo se suele describir algunas
carácterísticas propias.
Referencias
• (ITM 2007) Material de Libro de Texto de la
materia de Planificación y Modelado, Instituto
Tecnológico de Morelia.
• (Sánchez, M. 2009) Material del Curso de
Planificación y Modelado.
Dudas