Está en la página 1de 232

Introducción a la Ingeniería de

Software
El Software y la Ingeniería de
Software
CONTENIDO

2
Contenido
Contenido
Contenido
METODOLOGÍA

6
Distribución de los temas por
semana
• Semana 1 – La Ingeniería de Software
• Semana 2 – Ingeniería de Procesos de Software
• Semanas 3 y 4 – Ingeniería de Requisitos
• Semana 5 – Examen Primer Parcial
• Semanas 6 y 7 – Ingeniería de Diseño
• Semana 8 – Garantía de la Calidad de Software
• Semana 9 – Examen Segundo Parcial
• Semanas 10 y 11 – Técnicas de Pruebas del Software
• Semana 12 – Gestión y Estimación de Proyectos de
Software
• Semana 13 – Métricas de Proyectos
• Semana 14 – Examen Final
Actividades
• Práctica 1 - El Software y la Ingeniería de Software (3 puntos)
• Práctica 2 - Ingeniería de Procesos de Software (3 puntos)
• Práctica 3 - Ingeniería de Requisitos (Parte I) (3 puntos)
• Práctica 4 - Ingeniería de Requisitos (Parte II) (3 puntos)
• Práctica 5 - Ingeniería del Diseño (Parte I) (3 puntos)
• Práctica 6 - Ingeniería del Diseño (Parte II) (3 puntos)
• Práctica 7 - Garantía de la Calidad de Software (3 puntos)
• Práctica 8 - Técnicas de Pruebas del Software (Parte I) (3 puntos)
• Práctica 9 - Técnicas de Pruebas del Software (Parte II) (3 puntos)
• Práctica 10 - Gestión y Estimación Proyectos de Software (4 puntos)
• Práctica 11 - Métricas de Software (4 puntos)
• Exposiciones (5 puntos)
EVALUACIÓN

9
Resumen
• Prácticas: 40 puntos
• Exámenes: 60 puntos
Profe, deme esos dos
puntitos para la C, a favol…

Práctica final (4 puntos)


BIBLIOGRAFÍA

12
¿CONOCIMIENTOS PREVIOS?

14
¿EXPECTATIVAS?

15
Es el conjunto de los programas de cómputo,
procedimientos, reglas, documentación y datos
asociados, que forman parte de las operaciones
de un sistema de computación.

Extraído del estándar 729 del IEEE

Ingeniería es el conjunto de conocimientos y


técnicas científicas aplicadas al desarrollo,
implementación, mantenimiento y
perfeccionamiento de estructuras (tanto
físicas como teóricas) para la resolución de
problemas que afectan la actividad cotidiana
La ingeniería de software está formada por un de la sociedad.
proceso, un conjunto de métodos (prácticas) y
un arreglo de herramientas que permite a los
profesionales elaborar software de cómputo de
alta calidad.
Ley de las consecuencias inesperadas, cualquier acción humana, especialmente
las que envuelven o afectan a grupos humanos extensos, tendrá consecuencias
no anticipadas o calculadas.
Papel dual del Software
Características del Software

Se construye a
la medida; se
construye por
componentes

El software
no se
desgasta pero
sí se deteriora

El software se
desarrolla o modifica
con intelecto; no se
manufactura
Software Heredado
• Programas viejos - Longevidad
• Múltiples modificaciones
• Soporte de las funciones centrales de negocios –
Críticos
• Mala calidad
• No son susceptibles de extenderse
• Código confuso
• Documentación mala o inexistente
• Casos y resultados de prueba que nunca se archivaron
• Historial de cambio mal administrado
Por qué evoluciona el Software?

• Para que cumpla las necesidades de los nuevos


ambientes del cómputo y de la tecnología.
• Implementar nuevos requerimientos del
negocio
• Para hacerlo operable con otros sistemas o
bases de datos modernos.
• La arquitectura del software debe rediseñarse
para hacerla viable dentro de un ambiente de
redes.
Debe hacerse ingeniería con el software en todas sus formas y a través de todos
sus dominios de aplicación.
La ingeniería de software es el
establecimiento y uso de principios
fundamentales de la ingeniería con objeto
de desarrollar en forma económica software
que sea confiable y que trabaje con
eficiencia en máquinas reales. Fritz Bauer
Capas de la ingeniería de software
¿Cuáles son los
elementos de un
proceso de software?
Actividades estructurales del Proceso

• Comunicación
• Planeación
• Modelado
• Construcción
• Despliegue
Principios generales
• Dar valor a sus usuarios
• Todo diseño debe ser tan simple como sea
posible, pero no más
• Una visión clara es esencial para el éxito de un
proyecto de software
• Siempre establezca especificaciones, diseñe e
implemente con la seguridad de que alguien más
tendrá que entender lo que usted haga
• Un sistema con larga vida útil tiene más valor
• Planee por anticipado la reutilización
• ¡Piense!
Mitos del Software

Mitos de la Mitos del Mitos del


administración cliente desarrollador
Cualquier Corregir un defecto
proyecto
de Adaptar un sistema heredado a un
Software se ambiente de negocios cambiante
inicia por Extender las funciones y
alguna características
necesidad Crear un producto, servicio o
del Negocio sistema nuevos
Introducción a la Ingeniería de
Software
Conceptos y principios del análisis
(Parte I)
Conceptos y principios del análisis

Conceptos
¿Qué es la práctica de la
ingeniería de software?

Principios

Métodos
Herramientas
Principios Fundamentales
• Nivel del proceso
− Establecen un fundamento filosófico que guía al equipo de software
cuando:
 Realiza actividades estructurales y actividades sombrilla
 Navega por el flujo del proceso
 Elabora un conjunto de productos del trabajo de la ingeniería de software

• Nivel de la práctica
− Definen un conjunto de valores y reglas que sirven como guía cuando:
 Se analiza un problema
 Se diseña una solución
 Se implementa y prueba ésta
 Se entrega el software a la comunidad de usuarios
Principios que guían el proceso
• Ser ágil
− Son los principios básicos del desarrollo ágil los
que deben gobernar el enfoque
− Economía de acción:
 Mantener el enfoque técnico tan sencillo como sea
posible
 Hacer los productos del trabajo que se generan tan
concisos como se pueda
 Tomar las decisiones localmente, siempre que sea
posible
• Centrarse en la calidad
Principios que guían el proceso
• Estar listo para adaptar
– Adapte su enfoque a las restricciones impuestas por el problema, la gente y el proyecto
en sí
• Formar un equipo eficaz
– El objetivo son las personas
– Forme un equipo con organización propia en el que haya confianza y respeto mutuos
• Establecer mecanismos para la comunicación y coordinación
• Administrar el cambio
– Deben establecerse mecanismos para administrar la forma en la que los cambios se
solicitan, evalúan, aprueban e implementan
• Evaluar el riesgo
– Es esencial establecer planes de contingencia
• Crear productos del trabajo que agreguen valor para otros
– Asegúrese de que el producto del trabajo imparte la información necesaria sin
ambigüedades u omisiones
Principios que guían la práctica
• Divide y vencerás
– Separación de entidades, un problema grande es más fácil de resolver si se
divide en un conjunto de elementos
• Entender el uso de la abstracción
– Abstracción: Simplificación de algún elemento complejo de un sistema usado
para comunicar significado en una sola frase
– El objetivo de una abstracción es eliminar la necesidad de comunicar detalles
• Buscar la coherencia
– Principio de coherencia: Sugiere que un contexto familiar hace que el software
sea más fácil de usar. Considerar el aspecto ergonómico
• Centrarse en la transferencia de información
– La información fluye a través de una interfaz
– Debe ponerse atención especial al análisis, diseño, construcción y prueba de
las interfaces
Principios que guían la práctica
• Construir software que tenga modularidad eficaz
– Cada módulo debe centrarse exclusivamente en un aspecto bien delimitado
del sistema
– Cohesivo en su función
– Restringido en el contenido que representa
– Interconectados en forma relativamente sencilla, poco acoplamiento
• Buscar patrones
– Objetivo de los patrones
 Crear un cúmulo de bibliografía para resolver problemas recurrentes
 Crear un lenguaje compartido
 Acumular con éxito el cuerpo de conocimientos que define nuestra comprensión de
las buenas arquitecturas que satisfacen las necesidades de sus usuarios
• Cuando sea posible, representar el problema y su solución desde
varias perspectivas diferentes
• Tener en mente que alguien dará mantenimiento al software
PRINCIPIOS QUE GUÍAN TODA
ACTIVIDAD ESTRUCTURAL
Principios de Escuchar Centrarse en las palabras del hablante en lugar
de formular su respuesta a dichas palabras
comunicación
Si algo no está claro, pregunte para aclararlo,
pero evite las interrupciones constantes

Antes de comunicarse, Dedique algún tiempo a entender el problema


antes de reunirse con otras personas
prepararse

Alguien debe facilitar la Mantenga la conversación en movimiento

actividad. Facilitador que: Mediador en cualquier conflicto

Garantice que se sigan otros principios

Es mejor la comunicación
cara a cara
PRINCIPIOS QUE GUÍAN TODA
ACTIVIDAD ESTRUCTURAL
Principios de Tomar notas y documentar las decisiones
comunicación
Perseguir la colaboración

Permanecer centrado; hacer módulos con Abandonar un tema sólo después de que se
la discusión haya resuelto

Si algo no está claro, hacer un dibujo


a) Una vez que se acuerde algo, b) Si no
es posible ponerse de acuerdo en algo, c)
Si una característica o función no está Avanzar
clara o no puede aclararse en el
momento
La negociación no es un concurso o un Negociar funciones y características,
juego. Funciona mejor cuando las dos prioridades y fechas de entrega
partes ganan La negociación demandará el compromiso
de todas las partes
PRINCIPIOS QUE GUÍAN TODA
ACTIVIDAD ESTRUCTURAL
• Principios de planeación
– Entender el alcance del proyecto
 El alcance da un destino al equipo de software
– Involucrar en la actividad de planeación a los participantes del
software
– Reconocer que la planeación es iterativa
 Los modelos de proceso iterativo incrementales dictan que debe repetirse
la planeación después de la entrega de cada incremento de software, con
base en la retroalimentación recibida de los usuarios
– Estimar con base en lo que se sabe
 El objetivo de la estimación es obtener un índice del esfuerzo, costo y
duración de las tareas, con base en la comprensión que tenga el equipo
sobre el trabajo que va a realizar
– Al definir el plan, tomar en cuenta los riesgos
PRINCIPIOS QUE GUÍAN TODA
ACTIVIDAD ESTRUCTURAL
• Principios de planeación (cont.)
– Ser realista
 Las personas no trabajan 100% todos los días
– Ajustar la granularidad cuando se defina el plan
 Granularidad, nivel de detalle que se adopta cuando se desarrolla un plan
– Definir cómo se trata de asegurar la calidad
 Si se realizan revisiones técnicas, deben programarse
 Si se usará programación por parejas, debe definirse en forma explícita en el
plan
– Describir cómo se busca manejar el cambio
 Debe identificarse la forma en la que van a recibirse los cambios a medida que
avanza el trabajo de la ingeniería de software
– Dar seguimiento al plan con frecuencia y hacer los ajustes que se
requieran
• Evaluar diariamente el avance
• Cuando se detecten desviaciones, hay que ajustar el plan en consecuencia
PRINCIPIOS QUE GUÍAN TODA
ACTIVIDAD ESTRUCTURAL
V N
Representar
i Información i
s v
t e
a l

del Construcción más


Arquitectura y
Comportamiento
Funciones

C de Software T
l é
i c
e n
n i
t Características
c
e o

Principios de Modelado
PRINCIPIOS QUE GUÍAN TODA
ACTIVIDAD ESTRUCTURAL

Dominio
de la Arquitectura
Información

Modelos
Modelos
de de
Requerimientos
Dominio Dominio Interfaz de
Diseño Nivel de
de
Comportamiento Funcional usuario componente

Principios de Modelado
PRINCIPIOS QUE GUÍAN TODA
ACTIVIDAD ESTRUCTURAL
Principios de modelado
• El equipo de software tiene como objetivo principal elaborar software, no crear
modelos
• Viajar ligero, no crear más modelos de los necesarios
• Tratar de producir el modelo más sencillo que describa al problema o al software
• Construir modelos susceptibles al cambio
• Ser capaz de enunciar un propósito explícito para cada modelo que se cree
• Adaptar los modelos que se desarrollan al sistema en cuestión
• Tratar de construir modelos útiles, pero olvidarse de elaborar modelos perfectos
• No ser dogmático respecto de la sintaxis del modelo. Si se tiene éxito para
comunicar contenido, la representación es secundaria
• Si su instinto dice que un modelo no es el correcto a pesar de que se vea bien en
el papel, hay razones para estar preocupado
• Obtener retroalimentación tan pronto como sea posible
PRINCIPIOS QUE GUÍAN TODA
ACTIVIDAD ESTRUCTURAL
• Principios de modelado de los Requerimientos
– Debe representarse y entenderse el dominio de información de un problema
 Datos que fluyen hacia el sistema
 Datos que fluyen fuera del sistema
 Almacenamientos de datos que recaban y organizan objetos persistentes de datos
– Deben definirse las funciones que realizará el software
– Debe representarse el comportamiento del software
 Interacción con el ambiente externo
 Entradas que dan los usuarios finales
 Control de los datos efectuado por un sistema externo
 Vigilancia de datos reunidos en una red

– Los modelos que representen información, función y comportamiento deben


dividirse de manera que revelen los detalles en forma estratificada
 Divide y vencerás
 Partición o separación de entidades
– El trabajo de análisis debe avanzar de la información esencial hacia la
implementación en detalle
PRINCIPIOS QUE GUÍAN TODA
ACTIVIDAD ESTRUCTURAL
• Principios del modelado del diseño
– El diseño debe poderse rastrear hasta el modelo de
requerimientos
– Siempre tomar en cuenta la arquitectura del sistema
que se va a construir
• Interfaces
• Estructuras de datos
• Flujo de control
• Comportamiento del
programa
• Pruebas
• Mantenimiento

La arquitectura
del software
PRINCIPIOS QUE GUÍAN TODA
ACTIVIDAD ESTRUCTURAL
• Principios del modelado del diseño (cont.)
– El diseño de los datos es tan importante como el de las funciones de
procesamiento
 Ayuda a simplificar el flujo del programa
 Hace más fácil el diseño e implementación de componentes de software
 Hace más eficiente el procesamiento conjunto
– Las interfaces deben diseñarse con cuidado
– El diseño de la interfaz de usuario debe ajustarse a las necesidades
del usuario final
 Debe resaltar la facilidad de uso
– El diseño en el nivel de componentes debe tener independencia
funcional
 Cohesiva, centrarse en una y sólo una función o subfunción
PRINCIPIOS QUE GUÍAN TODA
ACTIVIDAD ESTRUCTURAL
• Principios del modelado del diseño (cont.)
– Los componentes deben estar acoplados con holgura entre sí y con el
ambiente externo
 El acoplamiento de componentes debe mantenerse tan bajo como sea
razonable

– Las representaciones del diseño (modelos) deben entenderse con


facilidad
 Propósito del diseño, comunicar información a los profesionales que
generarán el código, a los que probarán el software y a otros que le darán
mantenimiento en el futuro

– El diseño debe desarrollarse en forma iterativa. El diseñador debe


buscar más sencillez en cada iteración
PRINCIPIOS QUE GUÍAN TODA
ACTIVIDAD ESTRUCTURAL
• Principios de construcción
– Codificación
• Creación directa de lenguaje de programación en
código fuente
• Generación automática de código fuente
– Pruebas
• De integración
• De validación
• De aceptación
Principios de codificación
• Principios de preparación
– Entender el problema que se trata de resolver.
– Comprender los principios y conceptos básicos del
diseño.
– Elegir un lenguaje de programación que satisfaga las
necesidades del software que se va a elaborar y el
ambiente en el que operará.
– Seleccionar un ambiente de programación que
disponga de herramientas que hagan más fácil su
trabajo.
– Crear un conjunto de pruebas unitarias
Principios de codificación
• Principios de programación
– Restringir sus algoritmos
– Programación por parejas
– Seleccionar estructuras de datos que satisfagan las
necesidades del diseño
– Entender la arquitectura del software
– Mantener la lógica condicional tan sencilla como sea
posible
– Crear lazos anidados
– Seleccionar nombres significativos para las variables
– Escribir código que se documente a sí mismo
– Crear una imagen visual
Principios de codificación
• Principios de validación
– Recorrido del código
– Pruebas unitarias y corregir errores detectados
– Rediseñar el código
Principios de codificación
• Objeto de la prueba:
Encontrar un error ¿Cuáles son los
• Caso de prueba: objetivos de probar el
Probabilidad de software?
encontrar un error no
detectado hasta el
momento
• Prueba exitosa:
Descubre un error no
detectado hasta el
momento
Principios de codificación
• Principios de la prueba
– Todas las pruebas deben poder rastrearse hasta
los requerimientos del cliente
– Las pruebas deben planearse mucho antes de que
den comienzo
– El principio de Pareto se aplica a las pruebas de
software

Componentes

Errores
Principios de codificación
• Principios de la prueba (cont.)
– Las pruebas deben comenzar “en lo pequeño” y
avanzar hacia “lo grande”
– No son posibles las pruebas exhaustivas
Principios de construcción

• Entrega
• Apoyo
• Retroalimentación

Actividad del
despliegue
Principios de construcción
Principios de despliegue
• Deben manejarse las expectativas de los clientes
• Debe ensamblarse y probarse el paquete completo que
se entregará
• Antes de entregar el software, debe establecerse un
régimen de apoyo
• Se deben proporcionar a los usuarios finales materiales
de aprendizaje apropiados
• El software defectuoso debe corregirse primero y
después entregarse
COMPRENSIÓN DE LOS
REQUERIMIENTOS

Es la peor de las pesadillas. Un cliente


entra a la oficina, toma asiento, lo
mira a uno fijamente a los ojos y dice:
“Sé que cree que entiende lo que
digo, pero lo que usted no entiende
es que lo que digo no es lo que quiero
decir.”
Ingeniería de Requerimientos
• Espectro amplio de tareas y técnicas que llevan a entender los
requerimientos
• Se definen las necesidades del negocio, se describen los escenarios de uso,
se delinean las funciones y características y se identifican las restricciones
del proyecto
• Proporciona el mecanismo apropiado para:
– Entender lo que desea el cliente,
– Analizar las necesidades,
– Evaluar la factibilidad,
– Negociar una solución razonable,
– Especificar la solución sin ambigüedades,
– Validar la especificación y
– Administrar los requerimientos a medida de que se transforman en un
sistema funcional
Ingeniería de Requerimientos
• Tareas:
– Concepción
• Se identifica una necesidad del negocio o se
descubre un nuevo mercado o servicio potencial
• Se establece el entendimiento básico del
problema, las personas que quieren una solución,
la naturaleza de la solución que se desea, así como
la eficacia de la comunicación y colaboración
preliminares entre los otros participantes y el
equipo de software
Ingeniería de Requerimientos
• Tareas (cont.)
– Indagación
• Preguntar al cliente, a los usuarios y a otras personas
cuáles son los objetivos para el sistema o producto

Problemas de alcance, la frontera de


los sistemas está mal definida ¿Por qué es difícil
Problemas de entendimiento, los llegar al entendimiento
clientes o usuarios no están claro de lo que quiere
completamente seguros de lo que se
necesita
el cliente?
Problemas de volatilidad, los
requerimientos cambian con el
tiempo
Ingeniería de Requerimientos
• Tareas (cont.)
– Elaboración
• Se centra en desarrollar un modelo refinado de los
requerimientos que identifique distintos aspectos de la
función del software, su comportamiento e información
• Creación y mejora de escenarios de usuario que describan
cómo interactuará el usuario final con el sistema
• Extraer clases de análisis
• Se definen los atributos de cada clase de análisis
• Se identifican los servicios que requiere cada clase de
análisis
• Se identifican las relaciones y colaboración entre clases
• Se producen varios diagramas adicionales
Ingeniería de Requerimientos
• Tareas (cont.)
– Negociación
• Se pide a clientes, usuarios y otros participantes que
ordenen sus requerimientos según su prioridad y que
después analicen los conflictos
• Se evalúa su costo y riesgo, y se enfrentan los conflictos
internos

– Especificación
• Documento escrito
• Conjunto de modelos gráficos
• Modelo matemático formal
• Conjunto de escenarios de uso
• Prototipo
Ingeniería de Requerimientos
• Tareas (cont.)
– Validación
• Analiza la especificación a fin de garantizar que
– Todos ellos han sido enunciados sin ambigüedades
– Se detectaron y corrigieron las inconsistencias, las omisiones y los errores
– Los productos del trabajo se presentan conforme a los estándares
establecidos para el proceso, el proyecto y el producto
• El mecanismo principal de validación de los requerimientos es la
revisión técnica

– Administración de los requerimientos


• Conjunto de actividades que ayudan al equipo del proyecto a
identificar, controlar y dar seguimiento a los requerimientos y a
sus cambios en cualquier momento del desarrollo del proyecto
Etapas requeridas para establecer
las bases que permiten entender
los requerimientos de software

Identificación Reconocer los Hacer las


Trabajar hacia
de los múltiples primeras
la colaboración
participantes puntos de vista preguntas
¿Quién está detrás
de la solicitud de
este trabajo?
¿Es usted la
persona indicada ¿Quién usará la
para responder solución?
estas preguntas?
¿Cuáles preguntas
ayudarían a tener un
¿Puede otra ¿Cuál será el
persona dar beneficio
entendimiento preliminar
información económico de una del problema?
adicional? solución exitosa?

¿Qué problemas ¿Hay otro origen


resolvería esta para la solución que
solución? se necesita?
Indagación de los requerimientos
• Recabación de los requerimientos en forma
colaborativa
– Tanto ingenieros de software como otros participantes
dirigen o intervienen en las reuniones
– Se establecen reglas para la preparación y participación
– Se sugiere una agenda con suficiente formalidad para
cubrir todos los puntos importantes, pero con la suficiente
informalidad para que estimule el libre flujo de ideas
– Un “facilitador controla la reunión
– Se utiliza un “mecanismo de definición”
La meta es identificar el problema, proponer elementos de la solución, negociar
distintos enfoques y especificar un conjunto preliminar de requerimientos de la
solución
Indagación de los requerimientos
• Despliegue de la función de calidad (DFC)
– Técnica de administración de la calidad que traduce las necesidades
del cliente en requerimientos técnicos para el software
– Se concentra en maximizar la satisfacción del cliente a partir del
proceso de ingeniería del software
– Pone el énfasis en entender lo que resulta valioso para el cliente y
luego despliega dichos valores en todo el proceso de ingeniería
– Identifica tres tipos de requerimientos
 Requerimientos normales. Objetivos y metas que se establecen para un producto o
sistema durante las reuniones con el cliente. Si estos requerimientos están
presentes, el cliente queda satisfecho
 Requerimientos esperados. Están implícitos en el producto o sistema y quizá sean
tan importantes que el cliente no los mencione de manera explícita. Su ausencia
causará mucha insatisfacción
 Requerimientos emocionantes. Estas características van más allá de las
expectativas del cliente y son muy satisfactorias si están presentes.
Indagación de los requerimientos
Escenarios de uso
• Proporcionan la descripción de la manera en la que se utilizará el sistema

Indagación de los productos del trabajo


• Un enunciado de la necesidad y su factibilidad
• Un enunciado acotado del alcance del sistema o producto
• Una lista de clientes, usuarios y otros participantes
• Una descripción del ambiente técnico del sistema
• Una lista de requerimientos y las restricciones del dominio que se aplican a
cada uno
• Un conjunto de escenarios de uso que dan perspectiva al uso del sistema o
producto en diferentes condiciones de operación
• Cualesquiera prototipos desarrollados para definir requerimientos.
DESARROLLO DE CASOS DE USO
• Un caso de uso narra una historia estilizada
sobre cómo interactúa un usuario final con
el sistema en circunstancias específicas
• Ilustra el software o sistema desde el punto
de vista del usuario final
• Actores, cualquier cosa que se comunique
con el sistema o producto y que sea externo
a éste
– Actores principales, interactúan para
lograr la función requerida del sistema y
obtienen el beneficio previsto de éste
– Actores secundarios, dan apoyo al
sistema, de modo que los primarios
puedan hacer su trabajo.
¿Qué se necesita saber a fin de
desarrollar un caso de uso eficaz?
• ¿Quién es el actor principal y quién(es) el(los) secundario(s)?
• ¿Cuáles son los objetivos de los actores?
• ¿Qué precondiciones deben existir antes de comenzar la historia?
• ¿Qué tareas o funciones principales son realizadas por el actor?
• ¿Qué excepciones deben considerarse al describir la historia?
• ¿Cuáles variaciones son posibles en la interacción del actor?
• ¿Qué información del sistema adquiere, produce o cambia el actor?
• ¿Tendrá que informar el actor al sistema acerca de cambios en el
ambiente externo?
• ¿Qué información desea obtener el actor del sistema?
• ¿Quiere el actor ser informado sobre cambios inesperados?
Elaboración del modelo de los
requerimientos
• Objetivo del modelo del análisis
– Describir los dominios de información, función y comportamiento que se
requieren para un sistema basado en computadora

• Elementos del modelo de requerimientos


– Elementos basados en el escenario, el sistema se describe desde el punto de
vista del usuario con el empleo de un enfoque basado en el escenario
– Elementos basados en clases, cada escenario de uso implica un conjunto de
objetos que se manipulan cuando un actor interactúa con el sistema. Se
clasifican en clases: conjunto de objetos que tienen atributos similares y
comportamientos comunes
– Elementos de comportamiento, tiene un efecto profundo en el diseño que se
elija y en el enfoque de implementación que se aplique
– Elementos orientados al flujo, el sistema acepta entradas en varias formas,
aplica funciones para transformarla y produce salidas en distintos modos
El diagrama de estado es un método de representación del comportamiento de un sistema que
ilustra sus estados y los eventos que ocasionan que el sistema cambie de estado

Un estado es cualquier modo de comportamiento observable desde el exterior


Elaboración del modelo de los
requerimientos
• Patrones de análisis
– Sugieren soluciones dentro del dominio de la
aplicación que pueden volverse a utilizar cuando se
modelen muchas aplicaciones
– Beneficios
1. Aceleran el desarrollo de los modelos de análisis abstracto
que capturan los principales requerimientos del problema
concreto, debido a que proveen modelos de análisis
reutilizables con ejemplos, así como una descripción de
sus ventajas y limitaciones

2. Facilitan la transformación del modelo de análisis en un


modelo del diseño, sugiriendo patrones de diseño y
soluciones confiables para problemas comunes
Requerimientos de las negociaciones
• Objetivo
– Desarrollar un plan del proyecto que satisfaga las
necesidades del participante y que al mismo tiempo refleje
las restricciones del mundo real que se hayan establecido
al equipo del software

• Actividades
– Identificación de los participantes clave del sistema o
subsistema
– Determinación de las “condiciones para ganar” de los
participantes
– Negociación de las condiciones para ganar de los
participantes a fin de reconciliarlas en un conjunto de
condiciones ganar-ganar para todos los que intervienen
Cuando se revisan los requerimientos,
¿qué preguntas deben plantearse?
• ¿Es coherente con los objetivos generales del sistema o producto?
• ¿Se han especificado en el nivel apropiado de abstracción?
• ¿Es realmente necesario?
• ¿Está acotado y no es ambiguo?
• ¿Hay una fuente clara?
• ¿Hay requerimientos en conflicto con otros?
• ¿Es asequible en el ambiente técnico que albergará el sistema o producto?
• ¿Puede someterse a prueba?
• ¿Refleja de manera apropiada la información, la función y el comportamiento del
sistema que se va a construir?
• ¿Se ha “particionado” en forma que exponga información cada vez más detallada
sobre el sistema?
• ¿Se ha usado el patrón para simplificar el modelo de éstos? ¿Se han validado todos
los patrones de manera apropiada? ¿Son consistentes todos los patrones con los
requerimientos del cliente?
Introducción a la Ingeniería de
Software
Conceptos y principios del análisis
(Parte II)
Modelado de los requerimientos
• Utiliza una combinación de texto y diagramas para
ilustrarlos en forma que sea relativamente fácil de
entender y de revisar para corregir, completar y hacer
congruente.
• Da como resultado:
– La especificación de las características operativas del
software
– Indica la interfaz de éste y otros elementos del sistema
– Establece las restricciones que limitan al software
• Permite al profesional construir sobre los
requerimientos básicos establecidos durante las tareas
de concepción, indagación y negociación
Modelado de los requerimientos
Tipos de modelo:
• Modelos basados en el escenario desde el punto de vista de
distintos “actores” del sistema
• Modelos de datos, ilustran el dominio de información del
problema
• Modelos orientados a clases, representan clases orientadas a
objetos y la manera en la que las clases colaboran para cumplir
con los requerimientos del sistema
• Modelos orientados al flujo, representan los elementos
funcionales del sistema y la manera como transforman los datos
a medida que se avanza a través del sistema
• Modelos de comportamiento, ilustran el modo en el que se
comporta el software como consecuencia de “eventos” externos
Caso de Uso

Modelos Basados en el Escenario


Diagrama de Actividades

Modelos Basados en el Escenario


Diagrama de Carril (swimlane)

Modelos Basados en el Escenario


Modelo Relacional

Modelo E-R

Modelos de Datos
Modelos Orientados a Clase
Diagrama CRC

Modelos Orientados a Clase


Diagrama de Paquetes

Modelos Orientados a Clase


Modelos Orientados al Flujo
Diagrama de Secuencia

Diagrama de Estado

Modelos Orientados al Comportamiento


Objetivos y filosofía general

Durante el modelado de los requerimientos,


la atención se centra en qué, no en cómo
• ¿Qué interacción del usuario ocurre en una
circunstancia particular?
• ¿Qué objetos manipula el sistema?
• ¿Qué funciones debe realizar el sistema?
• ¿Qué comportamientos tiene el sistema?
• ¿Qué interfaces se definen?
• ¿Qué restricciones son aplicables?
Objetivos y filosofía general

Objetivos principales:
• Describir lo que requiere el cliente

• Establecer una base para la creación de un


diseño de software

• Definir un conjunto de requerimientos que


puedan validarse una vez construido el software
Reglas prácticas del análisis
• El modelo debe centrarse en los requerimientos que sean visibles dentro del
problema o dentro del dominio del negocio

• Cada elemento debe agregarse al entendimiento general de los requerimientos del


software y dar una visión del dominio de la información, de la función y del
comportamiento del sistema

• Hay que retrasar las consideraciones de la infraestructura y otros modelos no


funcionales hasta llegar a la etapa del diseño

• Debe minimizarse el acoplamiento a través del sistema

• Es seguro que el modelo de requerimientos agrega valor para todos los


participantes

• Mantener el modelo tan sencillo como se pueda


Análisis del dominio
El análisis del dominio del software
• Es la identificación, análisis y especificación de los
requerimientos comunes, a partir de un dominio de
aplicación específica, normalmente para usarlo varias veces
en múltiples proyectos dentro del dominio de la aplicación

La meta
• Encontrar o crear aquellas clases o patrones de análisis que
sean aplicables en lo general, de modo que puedan volverse
a usar
Enfoques del modelado de
requerimientos
• Análisis estructurado, considera que los datos y los procesos
que los transforman son entidades separadas
– Los objetos de datos, se modelan de modo que se definan
sus atributos y relaciones
– Los procesos, se modelan en forma que se muestre cómo
transforman a los datos a medida que los objetos que se
corresponden con ellos fluyen por el sistema

• Análisis orientado a objetos, se centra en la definición de las


clases y en la manera en la que colaboran uno con el otro para
cumplir los requerimientos
Modelado basado en escenarios
• Creación de un caso preliminar de uso
– Caso de uso
• Capta las interacciones que ocurren entre los productores y
consumidores de la información y el sistema en sí
– ¿Sobre qué escribir?
• Las reuniones para recabar los requerimientos, el DEC, y
otros, se utilizan para:
 Identificar a los participantes
 Definir el alcance del problema
 Especificar los objetivos operativos generales
 Establecer prioridades
 Delinear todos los requerimientos funcionales conocidos
 Describir las cosas que serán manipuladas por el sistema
Mejora de un caso de uso preliminar
¿El actor puede emprender
otra acción en este punto?
¿Es posible que el actor ¿Cómo examino los cursos
encuentre alguna condición alternativos de acción?
de error en este punto?
¿Cuál podría ser?
¿Es posible que el actor
encuentre otro
comportamiento? ¿Cuál
sería?
• Escenarios secundarios, forman parte del caso de uso
original, pero representan comportamientos alternativos
Mejora de un caso de uso preliminar

• Excepción
– Describe una situación que ocasiona que el sistema
presente un comportamiento algo distinto
– Debe describirse dentro del caso de uso si el software
la puede detectar y debe manejarla una vez detectada
– ¿Existen casos en los que ocurra alguna “función de
validación” durante este caso de uso?
– ¿Hay casos en los que una función (o actor) de soporte
falle en responder de manera apropiada?
– ¿El mal desempeño del sistema da como resultado
acciones inesperadas o impropias?
Escritura de un caso de uso formal
Excepciones
Disparador • Identifican las
Objetivo en • Identifica el situaciones
contexto evento o detectadas
condición que cuando se
• Identifica el “hace que mejora el caso
alcance general comience el caso de uso
del caso de uso de uso” preliminar

Precondición Escenario
• Describe lo que • Enlista las
se sabe que es acciones
verdadero antes específicas que
de que inicie el requiere el actor,
caso de uso y las respuestas
apropiadas del
sistema
Modelos UML que proporcionan el
caso de uso
• El diagrama de actividad UML
– Representa las acciones y decisiones que
ocurren cuando se realiza cierta función
– Gráfica del flujo de interacción dentro de
un escenario específico
• Rectángulos redondeados para denotar
una función específica del sistema,
• Flechas para representar flujo a través de
éste
• Rombos de decisión para ilustrar una
ramificación de las decisiones
• Líneas continuas para indicar que están
ocurriendo actividades en paralelo
Modelos UML que proporcionan el
caso de uso
• Diagramas de canal
– Representa el flujo de
acciones y decisiones e
indica qué actores
efectúan cada una de
ellas
– Las responsabilidades se
representan con
segmentos paralelos que
dividen el diagrama en
forma vertical
Conceptos de modelado de datos
• Modelo de datos
– Un ingeniero o analista de software define:
• Objetos de datos que se procesan dentro del sistema
• Relación entre ellos
• Otro tipo de información que sea pertinente para las
relaciones

– Diagrama entidad-relación
• Representa los datos que se introducen, almacenan,
transforman y generan dentro de una aplicación
Conceptos de modelado de datos
algo que tiene varias
propiedades o atributos
• Objetos de datos diferentes

– Representación de información compuesta que


debe ser entendida por el software
• Entidad externa, cosa, ocurrencia, evento, rol
• Unidad organizacional, lugar, estructura
– Un objeto de datos contiene sólo datos
– Puede representarse en forma de tabla
• Atributos, encabezados de la tabla
• Instancias, cuerpo de la tabla
Conceptos de modelado de datos
• Atributos de los datos
– Definen las propiedades de un objeto de datos
– Características
1) Nombrar una instancia del objeto de datos
2) Describir la instancia
3) Hacer referencia a otra instancia en otra tabla
– Atributo identificador, se convierte en una “llave”
cuando se desea encontrar una instancia del objeto de
datos
• Relaciones
– Los objetos de datos están conectados entre sí de
diferentes maneras
El modelado basado en clases
• Representa
– Objetos que manipulará el sistema
– Operaciones que se aplicarán a los objetos para efectuar la
manipulación
– Relaciones entre los objetos
– Colaboraciones que tienen lugar entre las clases definidas
• Elementos
– Clases
– Objetos
– Atributos
– Operaciones
– Modelos clase-responsabilidad-colaborador (CRC)
– Diagramas de colaboración
– Paquetes
El modelado basado en clases
• Identificación de las clases de análisis
– Se determinan subrayando cada sustantivo o frase
que las incluya para introducirlo en una tabla
simple
– Deben anotarse los sinónimos
– Espacio de solución, si la clase (sustantivo) se
requiere para implementar una solución
– Espacio del problema, si la clase sólo es necesaria
para describir la solución
El modelado basado en clases
Entidades
externas

Estructuras Cosas

¿Cómo se
manifiestan
las clases?
Ocurrencias
Lugares
o eventos

Unidades
organizacionales Roles
El modelado basado en clases
• ¿Cómo determino si una clase potencial debe, ser una clase
de análisis?
– Información retenida. La clase potencial será útil durante
el análisis sólo si debe recordarse la información sobre ella
para que el sistema pueda funcionar.
– Servicios necesarios. La clase potencial debe tener un
conjunto de operaciones identificables que cambien en
cierta manera el valor de sus atributos
– Atributos múltiples
– Atributos comunes
– Operaciones comunes
– Requerimientos esenciales
El modelado basado en clases
• Especificación de atributos
– Describen una clase que ha sido seleccionada para
incluirse en el modelo de requerimientos
• Definición de las operaciones
– Definen el comportamiento de un objeto
– Se dividen en cuatro categorías principales:
1) Operaciones que manipulan datos en cierta manera
2) Operaciones que realizan un cálculo
3) Operaciones que preguntan sobre el estado de un objeto
4) Operaciones que vigilan un objeto en cuanto a la
ocurrencia de un evento de control
El modelado basado en clases
• Modelado clase-responsabilidad-colaborador
– Proporciona una manera sencilla de identificación
y organización de las clases que son relevantes
para los requerimientos de un sistema o producto
– Responsabilidades, son los atributos y operaciones
relevantes para la clase
– Colaboradores, son aquellas clases que se
requieren para dar a una clase la información
necesaria a fin de completar una responsabilidad
Modelado clase-responsabilidad-
colaborador
• Clases-Categorías
– Clases de entidad, se extraen directamente del
enunciado del problema
– Clases de frontera, se utilizan para crear la interfaz
que el usuario mira y con la que interactúa cuando
utiliza el software. Se diseñan con la
responsabilidad de administrar la forma en la que
se presentan a los usuarios los objetos de entidad
– Clases de controlador, administran una “unidad de
trabajo” de principio a fin
Modelado clase-responsabilidad-
colaborador
• Responsabilidades-Lineamientos
– La inteligencia del sistema debe estar distribuida entre
las clases para enfrentar mejor las necesidades del
problema
– Cada responsabilidad debe enunciarse del modo más
general posible
– La información y el comportamiento relacionado con
ella deben residir dentro de la misma clase
– La información sobre una cosa debe localizarse con
una sola clase, y no distribuirse a través de muchas
– Cuando sea apropiado, las responsabilidades deben
compartirse entre clases relacionadas
Modelado clase-responsabilidad-
colaborador
• Colaboraciones
– Se identifican determinando si una clase puede
cumplir cada responsabilidad
– Relación es-parte-de, todas las clases que forman
parte de una clase agregada
– Relación tiene-conocimiento-de, cuando una clase
debe adquirir información de otra
– Relación depende-de, significa que dos clases
tienen una dependencia que no se determina por
tiene-conocimiento-de ni por es-parte-de
El modelado basado en clases
• Asociaciones y dependencias
– Asociación, define una relación entre clases
– Multiplicidad, define cuántas de una clase se
relacionan con cuántas de otra clase
– Relación de dependencia, una clase cliente depende
de algún modo de la clase servidor
– Estereotipo, “mecanismo extensible” dentro del UML
que permite definir un elemento especial de
modelado con semántica y especialización
determinadas. En UML se representan entre
paréntesis dobles angulares
El modelado basado en clases
• Paquetes de análisis
– Se utiliza para ensamblar un conjunto de
clases relacionadas
– Categorización, se clasifican distintos
elementos del modelo de análisis de
manera que se agrupen en un paquete
al que se da un nombre representativo
– El signo más (suma) que precede al
nombre de la clase de análisis en cada
paquete, indica que las clases tienen
visibilidad pública, por lo que son
accesibles desde otros paquetes
– El signo menos (resta) indica que un
elemento queda oculto desde todos los
demás paquetes
– El símbolo # señala que un elemento es
accesible sólo para los paquetes
contenidos dentro de un paquete dado
Requerimientos que modelan las
estrategias
Análisis estructurado
• Considera como entidades separadas los datos y los procesos que los
transforman
• Los objetos de datos se modelan en una forma que define sus
atributos y relaciones
• Los procesos que manipulan objetos de datos se modelan de una
forma que muestra cómo transforman los datos cuando los objetos
de datos fluyen por el sistema

Análisis orientado a objetos


• Se centra en la definición de clases y en el modo en el que colaboran
una con otra para cumplir con los requerimientos del cliente
Modelado orientado al flujo
Diagrama de flujo de datos

• Adopta un punto de vista del tipo entrada-proceso-


salida para el sistema
• Objetos de datos entran al sistema, son
transformados por elementos de procesamiento y
los objetos de datos que resultan de ello salen del
software
• Permite desarrollar modelos del dominio de la
información y del dominio funcional.
Modelado orientado al flujo
Creación de un modelo de flujo de datos
• El nivel 0 del diagrama debe ilustrar el software o sistema como
una sola burbuja
• Debe anotarse con cuidado las entradas y salidas principales
• La mejora debe comenzar por aislar procesos candidatos, objetos
de datos y almacenamiento de éstos, para representarlos en el
siguiente nivel
• Todas las flechas y burbujas deben etiquetarse con nombres
significativos
• De un nivel a otro, debe mantenerse la continuidad del flujo de
información
• Debe mejorarse una burbuja a la vez
Modelado orientado al flujo
• Creación de un modelo de flujo de control
– Para aplicaciones “motivadas” por eventos y no por datos,
información de control en lugar de reportes o pantallas, información
con mucha atención en el tiempo y el desempeño
– Lineamientos:
 Enlistar todos los sensores que son “leídos” por el software
 Enlistar todas las condiciones de interrupción
 Enlistar todos los “interruptores” que son activados por un operador
 Enlistar todas las condiciones de los datos
 Revisar todos los “aspectos de control” como posibles entradas o salidas de
especificación del control, según el análisis gramatical de sustantivos y verbos que
se aplicó a la narración del procesamiento
 Describir el comportamiento de un sistema con la identificación de sus estados,
identificar cómo se llega a cada estado y definir las transiciones entre estados
 Centrarse en las posibles omisiones
Modelado orientado al flujo
• La especificación de control
– Representa de dos maneras distintas el comportamiento
del sistema
– Contiene:
 Diagrama de estado, especificación secuencial del
comportamiento
 Tabla de activación del programa, especificación combinatoria del
comportamiento
– Describe el comportamiento del sistema, pero no da
información acerca del funcionamiento interno de los
procesos que se activan como resultado de dicho
comportamiento
Modelado orientado al flujo
• La especificación del proceso
– Se utiliza para describir todos los procesos del
modelo del flujo que aparecen en el nivel final de
la mejora
– Incluye:
 Texto narrativo
 Descripción del lenguaje de diseño del programa del
algoritmo del proceso
 Ecuaciones matemáticas
 Tablas o diagramas de actividad UML
Creación de un modelo de
comportamiento
• Modelo de comportamiento
– Indica la forma en la que responderá el software a eventos
o estímulos externos
– Deben seguirse los pasos siguientes:
1. Evaluar todos los casos de uso para entender por completo la
secuencia de interacción dentro del sistema
2. Identificar los eventos que conducen la secuencia de interacción
y que entienden el modo en el que éstos se relacionan con
objetos específicos
3. Crear una secuencia para cada caso de uso
4. Construir un diagrama de estado para el sistema
5. Revisar el modelo de comportamiento para verificar la exactitud
y consistencia
Creación de un modelo de
comportamiento
Identificar los eventos con el caso de uso

• Un evento ocurre siempre que el sistema y un actor


intercambian información

• Un evento no es la información que se intercambia,


sino el hecho de que se intercambió la información

• Un caso de uso se estudia para efectos del intercambio


de información
Creación de un modelo de
comportamiento
• Representaciones de estado
– Caracterizaciones diferentes de los estados
1. El estado de cada clase cuando el sistema ejecuta su
función
2. El estado del sistema según se observa desde el exterior
cuando realiza su función
– El estado de una clase tiene características tanto
pasivas como activas
– Estado pasivo, estado actual de todos los atributos de
un objeto
– Estado activo, de un objeto indica el estado actual del
objeto conforme pasa por una transformación o
procesamiento continuos
Creación de un modelo de
comportamiento
• Representaciones de estado (cont.)
– Diagramas de secuencia
• Indica la forma en la que los eventos provocan
transiciones de un objeto a otro
• Representación del modo en el que los eventos causan
el flujo de uno a otro como función del tiempo
• Versión taquigráfica del caso de uso
• Todos los eventos que causan transiciones entre
objetos del sistema se recopilan en un conjunto de
eventos de entrada y de salida
Patrones para el modelado de
requerimientos
Patrones de software
• Mecanismo para capturar conocimiento del dominio, en forma que
permita que vuelva a aplicarse cuando se encuentre un problema nuevo
• Con frecuencia incorpora una clase, función o comportamiento dentro
del dominio de aplicación

Descubrimiento de patrones de análisis


• Basados en el escenario (casos de uso)
• Orientados a datos (el modelo de datos)
• Basados en clases
• Orientados al flujo
• Comportamiento
Modelado de requerimientos para
webapps
• ¿Cuánto análisis es suficiente? Depende de:
– Tamaño y complejidad del incremento de la
webapp
– Número de participantes
– Tamaño del equipo de la webapp
– Grado en el que los miembros del equipo han
trabajado juntos antes
– Medida en la que el éxito de la organización
depende directamente del éxito de la webapp
Modelado de requerimientos para
webapps
Entrada del modelado de los requerimientos

• Participantes
• Categorías de usuario
• el contexto del negocio
• Las metas definidas de información y aplicación
• Requerimientos generales de webapps
• Los escenarios de uso
Modelado de requerimientos para
webapps
Salida del modelado de los requerimientos
• Modelo de contenido: identifica el espectro completo de contenido que
dará la webapp. El contenido incluye datos de texto, gráficos e imágenes,
video y sonido
• Modelo de interacción: describe la manera en que los usuarios
interactúan con la webapp
• Modelo funcional: define las operaciones que se aplicarán al contenido
de la webapp y describe otras funciones de procesamiento que son
independientes del contenido pero necesarias para el usuario final
• Modelo de navegación: define la estrategia general de navegación para
la webapp
• Modelo de configuración: describe el ambiente e infraestructura en la
que reside la webapp
Modelado de requerimientos para
webapps
• Modelo del contenido de las webapps
– Incluye elementos estructurales que dan un punto de vista importante de los requerimientos del
contenido de una webapp
 Objetos del contenido
 Clases de análisis
 Entidades visibles para el usuario
– El contenido puede desarrollarse antes de la implementación de la webapp, mientras ésta se
construye o cuando ya opera
– Se incorpora por referencia de navegación en la estructura general de la webapp
– Objeto de contenido
 Descripción de un producto en forma de texto
 Pueden almacenarse como archivos separados, incrustarse directamente en páginas web u obtenerse en forma
dinámica de una base de datos
 Es cualquier aspecto de información cohesiva que se presente al usuario final
 Se determinan directamente a partir de casos de uso, estudiando la descripción del escenario respecto de
referencias directas e indirectas al contenido
– Árbol de datos
 Representa una jerarquía de información que se utiliza para describir un componente
 Se desarrolla como un esfuerzo para definir relaciones jerárquicas entre los objetos de contenido y para dar un
medio de revisión del contenido a fin de que se descubran las omisiones e inconsistencias antes de que
comience el diseño
 Sirve como base para diseñar el contenido
Modelado de requerimientos para
webapps
• Modelo de la interacción para webapps
– Se compone de los elementos siguientes:
 Casos de uso
 Diagramas de secuencia
 Diagramas de estado
 Prototipos de la interfaz de usuario
– El formato de la interfaz de usuario, el contenido que presenta, los
mecanismos de interacción que implementa y la estética general de
las conexiones entre el usuario y la webapp tienen mucho que ver con
la satisfacción de éste y con el éxito conjunto del software
– Aunque se afirme que la creación de un prototipo de interfaz de
usuario es una actividad de diseño, es una buena idea llevarla a cabo
durante la creación del modelo de análisis
Modelado de requerimientos para
webapps
• Modelo funcional para las webapps
– Enfrenta dos elementos de procesamiento de la webapp,
cada uno de los cuales representa un nivel distinto de
abstracción del procedimiento:
1) Funciones observables por los usuarios que entrega la webapp a
éstos
2) Las operaciones contenidas en las clases de análisis que
implementan comportamientos asociados con la clase
– En un nivel más bajo de abstracción del procedimiento,
describe el procesamiento que se realizará por medio de
operaciones de clase de análisis
– En el nivel de análisis, los diagramas de actividades deben
usarse sólo donde la funcionalidad sea relativamente
compleja
Modelado de requerimientos para
webapps

• Lista de atributos del lado del


Modelos de servidor y del lado del cliente
configuración
• Diagrama de despliegue UML, se
para las utiliza en situaciones en las que
webapps deben considerarse arquitecturas
de configuración compleja
Modelado de requerimientos para
webapps
• Modelado de la navegación
– Se considera cómo navegará cada categoría de usuario de un elemento de la webapp a otro
– La mecánica de navegación se define como parte del diseño
– Debe centrarse la atención en los requerimientos generales de navegación
– Preguntas:
• ¿Ciertos elementos deben ser más fáciles de alcanzar que otros? ¿Cuál es la prioridad de presentación?
• ¿Debe ponerse el énfasis en ciertos elementos para forzar a los usuarios a navegar en esa dirección?
• ¿Cómo deben manejarse los errores en la navegación?
• ¿Debe darse prioridad a la navegación hacia grupos de elementos relacionados y no hacia un elemento
específico?
• ¿La navegación debe hacerse por medio de vínculos, acceso basado en búsquedas o por otros medios?
• ¿Debe presentarse a los usuarios ciertos elementos con base en el contexto de acciones de navegación previas?
• ¿Debe mantenerse un registro de usuarios de la navegación?
• ¿Debe estar disponible un mapa completo de la navegación en cada punto de la interacción del usuario?
• ¿El diseño de la navegación debe estar motivado por los comportamientos del usuario más comunes y
esperados o por la importancia percibida de los elementos definidos de la webapp?
• ¿Un usuario puede “guardar” su navegación previa a través de la webapp para hacer expedito el uso futuro?
• ¿Para qué categoría de usuario debe diseñarse la navegación óptima?
• ¿Cómo deben manejarse los vínculos externos hacia la webapp? ¿Con la superposición de la ventana del
navegador existente? ¿Como nueva ventana del navegador? ¿En un marco separado?
Introducción a la Ingeniería de
Software
Ingeniería del Diseño
Ingeniería del Diseño
• Principios:
– Resistencia: Un programa no debe tener ningún error que impida su
funcionamiento.
– Funcionalidad: Un programa debe se apropiado para los fines que
persigue.
– Belleza: La experiencia de usar el programa debe ser placentera.

• Objetivo:
– Producir un modelo o representación que tenga Resistencia,
Funcionalidad y Belleza.
– Esto se logra a través de dos elementos:
o Diversificación y convergencia, las cuales se basan en:
 Experiencia
 Principios
 Criterios
 Proceso de iteración
Ingeniería del Diseño
El diseño de software se ubica en el área técnica de la
ingeniería de software y se aplica sin importar el modelo
del proceso que se utilice

El diseño de software comienza una vez que se han


analizado y modelado los requerimientos

El diseño de software es la última acción de la ingeniería


de software dentro de la actividad de modelado y prepara
la etapa de construcción
Ingeniería del Diseño
Modelo de Análisis
Elementos basados en Elementos orientados al
escenarios flujo
• Casos de uso - texto • Diagramas de flujo de Diseño en el nivel de
• Diagramas de caso de uso datos
• Diagramas de actividad • Diagramas de flujo de componentes
• Diagramas de carril control
• Narrativas de
procesamiento Diseño de interfaz

Elementos basados en Elementos de Diseño arquitectónico


clases comportamiento

• Diagramas de clase • Diagramas de estado


• Paquetes de análisis • Diagramas de secuencia Diseño de datos/ clase
• Modelos CRC
• Diagramas de colaboración

Modelo del Diseño


Ingeniería del Diseño

Por qué es tan importante el diseño?


• La importancia del diseño del software puede describirse con una sola
palabra calidad.
• Es la etapa en la que se fomentará la calidad en la ingeniería de
software.
• Proporciona las representaciones del software susceptibles de evaluar
respecto de la calidad.
• Es la única forma en que, de manera exacta, un requisito del cliente se
puede convertir en un sistema o producto de software terminado.
• Sirve como fundamento para todas las actividades subsecuentes de la
ingeniería del software y del soporte de este.
El Proceso de Diseño
Proceso del diseño
• Es un proceso iterativo mediante el cual los requisitos se traducen en
un "plano" para construir el software.

Características para evaluar un buen diseño


• Debe implementar todos los requisitos explícitos contenidos en el
modelo de análisis, y debe ajustarse a todos los requisitos implícitos
que desea el cliente.
• Debe ser una guía legible y comprensible para quienes generan
código y quienes realizan pruebas y, en consecuencia, dan soporte al
software.
• Debe proporcionar una imagen completa del software desde una
perspectiva de implementación.
El Proceso de Diseño
Lineamientos de calidad
• Debe presentar una estructura arquitectónica
• Debe ser modular
• Debe contener distintas representaciones de los datos, la arquitectura, las
interfaces y los componentes
• Debe conducir a estructuras de datos que sean apropiadas para las clases que
habrán de implementarse y que procedan de patrones de datos reconocibles
• Debe conducir a componentes que presenten características funcionales
independientes
• Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre
los componentes y el ambiente externo
• Debe obtenerse por medio de un método repetible que se base en la
información obtenida durante el análisis de requisitos del software
• Debe representarse por medio de una notación que comunique de manera
eficaz su significado
El Proceso de Diseño
Atributos de calidad

• Funcionalidad, conjunto de características y capacidades del


programa, la generalidad de las funciones que se entregan y la
seguridad general del sistema
• Usabilidad, factores humanos, estética general, consistencia y
documentación
• Confiabilidad, frecuencia y gravedad de las fallas, exactitud de los
resultados que salen, el tiempo medio para que ocurra una falla,
capacidad de recuperación ante ésta y lo predecible del programa
• Rendimiento, velocidad de procesamiento, tiempo de respuesta,
uso de recursos, conjunto y la eficiencia
• Mantenibilidad, capacidad del programa para ser ampliable,
adaptable y servicial, que pueda probarse, compatible y
configurable, facilidad para instalarse en el sistema y para que se
detecten los problemas
El Proceso de Diseño
La evolución
del diseño del Métodos para
software es traducir el
un proceso flujo de datos
continuo que o la estructura
ya ha cubierto de éstos a una Métodos
casi seis definición de orientados al
décadas diseño aspecto

Programación Enfoque Desarrollo


estructurada orientado a orientado al
objeto para modelo y a las
diseñar pruebas
derivaciones
El Proceso de Diseño

1. Un mecanismo para traducir el


modelo de requerimientos en
una representación del diseño ¿Qué características son
2. Una notación para representar comunes en todos los
las componentes funcionales y
métodos de diseño?
sus interfaces
3. Una heurística para mejorar y
hacer particiones
4. Lineamientos para evaluar la
calidad
Conceptos de Diseño
Abstracción Es una de las formas fundamentales en
las que el humano se enfrenta a la
complejidad
Abstracción de Secuencia de instrucciones que tiene
Procedimiento
una función específica y limitada

Abstracción de Es una colección nombrada de datos


Datos
que describe un objeto de datos
Conceptos de Diseño
Arquitectura del software

•Estructura general del software y las formas en que la estructura proporciona una integridad conceptual para un sistema
•Estructura u organización de los componentes del programa
•La manera en que estos componentes interactúan
•Estructura de datos que utilizan los componentes

Propiedades del diseño de la arquitectura

•Propiedades estructurales, define los componentes de un sistema y la manera en la que están agrupados e interactúan
unos con otros
•Propiedades extrafuncionales, cómo se satisface los requerimientos de desempeño, capacidad, confiabilidad, seguridad
y adaptabilidad, así como otras características del sistema
•Familias de sistemas relacionados, el diseño debe tener la capacidad de reutilizar bloques de construcción
arquitectónica

Modelos del diseño arquitectónico

•Modelos estructurales, representan la arquitectura como un conjunto organizado de componentes del programa
•Modelos del marco de trabajo, aumentan el nivel de abstracción del diseño, al tratar de identificar patrones de diseño
arquitectónico repetibles que se encuentran en tipos similares de aplicaciones
•Modelos dinámicos, abordan los aspectos estructurales de la arquitectura del programa e indican cómo cambia la
estructura o la configuración del sistema en función de eventos externos
•Modelos del proceso, se centran en el diseño del negocio o proceso técnico al que debe dar acomodo el sistema
•Modelos funcionales, se usan para representar la jerarquía funcional de un sistema
Conceptos de Diseño
• Patrón de diseño
– Describe una estructura de diseño que resuelve un
problema de diseño particular dentro de un contexto
específico y en medio de "fuerzas" que pueden tener un
impacto en la manera en que se aplica y utiliza el patrón
• Objetivo
– Proporcionar una descripción que le permita al diseñador
determinar si el patrón:
1) Es aplicable al trabajo en cuestión
2) Se puede reutilizar
3) Sirve como guía para desarrollar un patrón distinto en funciones
o estructura
Conceptos de Diseño
• División de problemas
– Cualquier problema complejo puede manejarse con más facilidad si se subdivide en elementos
susceptibles de resolverse u optimizarse de manera independiente
o Problema, característica o comportamiento que se especifica en el modelo de los requerimientos para el
software

• Modularidad
– El software se divide en componentes (módulos) con nombres independientes y que es posible
abordar en forma individual
– Atributo particular del software que permite que un programa sea manejable de manera intelectual

• Ocultación de información
– Sugiere que los módulos se caracterizan por las decisiones de diseño que cada uno oculta a los otros
– Los módulos deben especificarse y diseñarse de manera que la información que está dentro del
módulo sea inaccesible para otros módulos que no necesiten esa información
– El ocultamiento define y fortalece las restricciones de acceso para los detalles de procedimiento
dentro de un módulo y para cualquier estructura de datos local que utilice el módulo
Conceptos de Diseño
• Independencia funcional
– Debe diseñarse software de manera que cada módulo resuelva un
subconjunto específico de requerimientos y tenga una interfaz sencilla cuando
se vea desde otras partes de la estructura del programa
– El software es más fácil de desarrollar porque su función se subdivide y las
interfaces se simplifican
– Son más fáciles de mantener debido a que los efectos secundarios causados
por el diseño o por la modificación del código son limitados, se reduce la
propagación del error y es posible obtener módulos reutilizables
– Es una clave para el buen diseño y éste es la clave de la calidad del software
– Se evalúa aplicando dos criterios cualitativos:
• Cohesión: indicador de la fortaleza relativa funcional de un módulo
• Acoplamiento: independencia relativa entre módulos
– Un módulo cohesivo ejecuta una sola tarea, por lo que requiere interactuar
poco con otros componentes en otras partes del programa
– En el diseño de software, debe buscarse el mínimo acoplamiento posible
Conceptos de Diseño
Refinamiento
- Es una estrategia de diseño descendente . Es un proceso de elaboración
- El desarrollo de un programa se realiza al refinar de manera sucesiva los niveles de detalle
procedimentales
- Ayuda al diseñador a revelar los detalles de grado menor mientras se realiza el diseño

Aspectos
- Representación de una preocupación de interferencia
- Es importante identificar aspectos, de modo que el diseño les pueda dar acomodo
conforme sucede el refinamiento y la división en módulos

Rediseño
- Técnica de reorganización que simplifica el diseño de un componente sin cambiar su función
o comportamiento
- Es el proceso de cambiar un sistema de software de tal forma que no se altere el
comportamiento externo de su código y aún así se mejore su estructura interna
Conceptos de Diseño
• Clases de diseño
– Permite refinar las clases de análisis al proporcionar detalles del diseño que permitirán
la implementación de las clases
– Permite producir un conjunto nuevo de clases de diseño que implementen una
infraestructura de software para soportar la solución del negocio
• Tipos de clases
– Clases de interfaz con el usuario, definen todas las abstracciones necesarias para la
interacción humano-computadora
– Clases del dominio de negocios, identifican los atributos y servicios necesarios para
implementar algún elemento del dominio de negocios
– Clases de proceso, implementan abstracciones del negocio en un nivel más bajo, las
cuales se requieren para manejar por completo las clases del dominio de negocios
– Clases persistentes, representan almacenamientos de datos que persistirán más allá de
la ejecución del software
– Clases de sistema, implementan las funciones de gestión y control de software que
permiten que el sistema opere y se comunique dentro de su entorno de computación y
con el mundo exterior
Ingeniería del Diseño
• Características clase de diseño bien formada
– Completa y suficiente, una clase de diseño debe ser la encapsulación
completa de todos los atributos y métodos que se pueden esperar, en
forma razonable, que existan por clase
– Primitivismo, los métodos asociados con una clase de diseño deben
enfocarse en el cumplimiento de un servicio para la clase. Una vez que
el servicio ha sido implementado con un método, la clase no debe
proporcionar otra forma de complementar la misma cosa
– Cohesión alta, una clase de diseño cohesiva tiene un conjunto de
responsabilidades pequeño y enfocado, y aplica atributos y métodos
de manera sencilla para implementar dichas responsabilidades
– Acoplamiento bajo, Dentro del modelo de diseño es necesario que las
clases de diseño colaboren con alguna otra. La colaboración se debe
mantener en un mínimo aceptable. Si un modelo de diseño tiene un
acoplamiento alto, el sistema es difícil de implementar, probar y
mantener a través del tiempo
El Modelo del Diseño
• Dimensión del proceso
– Indica la evolución del modelo del diseño
conforme se ejecutan las tareas de éste como
parte del proceso del software
• Dimensión de la abstracción
– Representa el nivel de detalle a medida que cada
elemento del modelo de análisis se transforma en
un equivalente de diseño y luego se mejora en
forma iterativa
El Modelo del Diseño
• Elementos del diseño de datos
– En ocasiones denominado arquitectura de datos
– Crea un modelo de datos o información que se
representa en un nivel de abstracción elevado
– La estructura de los datos y algoritmos requeridos
para manipular los datos – Nivel de componentes
– Traducción de un modelo de datos a una base de
datos – Nivel de aplicación
– Conjunto de información almacenada en bases de
datos incompatibles y reorganizados en un “data
warehouse” – Nivel de negocios
El Modelo del Diseño
• Elementos del diseño arquitectónico
– Conjunto de sistemas interconectados, obtenidos de paquetes de análisis
dentro del modelo de requerimientos
– Fuentes:
• Información sobre el dominio de la aplicación del software que se va a elaborar
• Elementos específicos del modelo de requerimientos, sus relaciones y
colaboraciones para el problema en cuestión
• La disponibilidad de estilos arquitectónicos y sus patrones

• Elementos de diseño de la interfaz


– Elementos:
• Interfaz de usuario (UI)
• Interfaces externas que tienen que ver con otros sistemas, dispositivos, redes y
otros productores o consumidores de información
• Interfaces internas que involucran a los distintos componentes del diseño
El Modelo del Diseño
• Elementos del diseño en el nivel de los
componentes
– Un componente se representa en forma de
diagrama UML
– Se utiliza un diagrama de actividades UML para
representar la lógica del procesamiento
– El flujo detallado del procedimiento para un
componente se representa con seudocódigo
– La estructura algorítmica sigue las reglas
establecidas para la programación estructurada
El Modelo del Diseño
• Elementos del diseño del despliegue
– Indican la forma en la que se acomodarán la
funcionalidad del software y los subsistemas
dentro del ambiente físico de la computación que
lo apoyará
– Se indican los subsistemas (funcionalidad)
– Formato descriptor, el diagrama de despliegue
muestra el ambiente de computación, pero no
indica de manera explícita los detalles de la
configuración
Diseño Arquitectónico
• Qué es la arquitectura del software?
– Es la estructura o las estructuras del sistema, que incluyen los
componentes del software, las propiedades visibles externamente de
esos componentes y las relaciones entre ellos.
– Es una representación que permite que un ingeniero del software:
1) Analice la efectividad del diseño para cumplir con los requisitos
establecidos.
2) Considere opciones arquitectónicas en una etapa en que aún resulta
relativamente fácil hacer cambios al diseño.
3) Reduzca los riesgos asociados con la construcción del software.
– Componente de software es un módulo del programa o una clase
orientada a objetos, e incluye bases de datos y middleware que
permita configurar una red de clientes y servidores.
Diseño Arquitectónico
• Arquitectura del software
– El diseño de Ia arquitectura del software considera
dos niveles de Ia pirámide del diseño:
Diseño de datos, permite representar el componente
de datos de la arquitectura en sistemas convencionales
y definiciones de clase de los sistemas orientados a
objetos
 Diseño arquitectónico, se concentra en Ia
representación de Ia estructura de los componentes del
software, sus propiedades e interacciones.
Diseño Arquitectónico
• Por qué es importante la arquitectura?
– Permiten la comunicación entre todas las partes
interesadas en el desarrollo de un sistema de cómputo.

– Destaca las decisiones iniciales relacionadas con el diseño


que tendrán un impacto profundo en todo el trabajo de la
ingeniería del software que le sigue y en el éxito final del
sistema como entidad operacional.

– Constituye un modelo relativamente pequeño e


intelectualmente comprensible de como está estructurado
el sistema y como trabajan juntos sus componentes
Diseño Arquitectónico
• Descripciones arquitectónicas
– Es un conjunto de productos del trabajo que
reflejan puntos de vista distintos del sistema

– Perspectiva, representación del sistema completo


desde el punto de vista de un conjunto de
preocupaciones relacionadas de un participante

– Punto de vista, especificación de las convenciones


para construir y usar una perspectiva
Géneros Arquitectónicos
Inteligencia Simulan o incrementan la cognición humana, su locomoción u otros procesos orgánicos
artificial:
Comerciales y no Fundamentales para la operación de una empresa de negocios
lucrativos:
Comunicaciones: Proveen la infraestructura para transferir y manejar datos, para conectar usuarios de
éstos o para presentar datos en la frontera de una infraestructura

Contenido de Se emplean para crear o manipular artefactos de texto o multimedios


autor:
Dispositivos: Interactúan con el mundo físico a fin de brindar algún servicio puntual a un individuo

Entretenimiento y Administran eventos públicos o proveen una experiencia grupal de entretenimiento


deportes:
Financieros: Proporcionan la infraestructura para transferir y manejar dinero y otros títulos

Juegos: Dan una experiencia de entretenimiento a individuos o grupos


Géneros Arquitectónicos
Gobierno: Dan apoyo a la conducción y operaciones de una institución política local, estatal, federal, global o de otro tipo

Industrial: Simulan o controlan procesos físicos

Legal: Dan apoyo a la industria jurídica

Médicos: Diagnostican, curan o contribuyen a la investigación médica

Militares: Consulta, comunicaciones, comando, control e inteligencia, así como de armas ofensivas y defensivas

Sistemas operativos: Están inmediatamente instalados en el hardware para dar servicios de software básico

Plataformas: Se encuentran en los sistemas operativos para brindar servicios avanzados

Científicos: Se emplean para hacer investigación científica y aplicada

Herramientas: Se utilizan para desarrollar otros sistemas

Transporte: Controlan vehículos acuáticos, terrestres, aéreos o espaciales

Utilidades: Interactúan con otro software para brindar algún servicio específico
Estilos Arquitectónicos
• Estilos arquitectónicos
– Mecanismo descriptivo
– Plantilla para la construcción
– Describe una categoría de sistemas
• Objetivo
– Establecer una estructura para todos los componentes del sistema
• Los estilos arquitectónicos abarcan:
 Conjunto de componentes, que realizan una función requerida por el sistema
 Conjunto de conectores, que permiten la comunicación, coordinación y
cooperación entre los componentes
 Restricciones, que definen cómo se integran los componentes para formar el
sistema
 Modelos semánticos, que permiten a un diseñador, mediante el análisis de las
propiedades conocidas de las partes que lo integran, comprender las
propiedades generales de un sistema
Estilos Arquitectónicos
• Arquitectura centrada en datos
– Un almacén de datos se encuentra en el centro; otros componentes tienen
acceso a él y cuentan con la opción de actualizar, agregar, eliminar o modificar
los datos

• Arquitectura de flujo de datos


– Se aplica cuando los datos de entrada se habrán de transformar en datos de
salida mediante una serie de componentes para el cálculo o la manipulación

• Arquitectura de llamada y retorno


– Permite que un diseñador de software obtenga una estructura de programa
que resulta relativamente fácil modificar y cambiar de tamaño
Estilos Arquitectónicos
• Arquitectura orientada a objetos
– Encapsulan los datos y las operaciones que deben aplicarse para manipular los
datos

• Arquitectura en capas
– Hay varias capas definidas; cada una de ellas realiza operaciones que se
acercan progresivamente al conjunto de instrucciones de la máquina
• Capa externa, los componentes sirven a las operaciones de interfaz de usuario

• Capa interna, los componentes sirven como interfaz con el sistema operativo

• Capas intermedias, proporcionan servicios de utilería y de software de


aplicaciones
Patrones arquitectónicos
– Se abocan a un problema de aplicación específica
dentro de un contexto dado y sujeto a
limitaciones y restricciones
Estilos Arquitectónicos
• Conjunto de criterios de diseño para evaluar un diseño arquitectónico
– Control.
 Cómo se maneja el control dentro de la arquitectura?
 Existe una jerarquía de control distintiva y si es así, cuál es la función de los componentes
dentro de esta jerarquía de control?
 Cómo transfieren los campos el control dentro del sistema?
 Cómo se comparte el control entre los componentes?
 Cuál es la topología del control?
 Está sincronizado el control o los componentes operan asincrónicamente?

– Datos.
• Cómo se comunican los datos entre los componentes?
• El flujo de datos es continuo o los objetos de datos se pasan esporádicamente al sistema?
• Cuál es el modo de transferencia de los datos?
• Existen componentes de datos, y de ser así, cuál es su papel?
• Cómo interactúan los componentes funcionales con los de datos?
• Los componentes de datos son pasivos o activos?
• Cómo interactúan los datos y el control dentro del sistema?
Diseño Arquitectónico
• Representación del sistema en el contexto
– Diagrama de contexto del sistema
• Representa el flujo de la información dentro y fuera del sistema, la información del
usuario y el procesamiento relevante de soporte.
• Modela la manera en que el software interactuará con las entidades ubicadas mas
allá de sus limites.
– Sistemas superiores: Utilizan al sistema objetivo como parte de algún
esquema de procesamiento de alto nivel
– Sistemas subordinados: Usados por el sistema objetivo y proveen
datos o procesamiento que son necesarios para completar las
funciones del sistema objetivo
– Sistemas entre iguales: Interactúan sobre una base de igualdad
– Actores: entidades que interactúan con el sistema objetivo mediante
la producción o consumo de información que es necesaria para el
procesamiento de los requerimientos
Diseño Arquitectónico
Definición de arquetipos

• Es una clase o un patrón que representa una abstracción central


importantísima en el diseño de una arquitectura para el sistema de
destino

Refinamiento de la arquitectura en componentes

• Dominio de la aplicación
• Dominio de la infraestructura

Instancia de Ia arquitectura

• La arquitectura se aplica a un problema específico con el propósito de


demostrar que la estructura y los componentes son apropiados
Evaluación de las arquitecturas de
software
• Método de la negociación para analizar la arquitectura
– Escenarios de investigación. Se desarrolla un conjunto de casos de
uso
– Obtención de los requerimientos y restricciones, y descripción del
ambiente
– Descripción de los estilos o patrones de arquitectura elegidos para
abordar los escenarios y requerimientos
– Evaluación de los atributos de calidad, considerando cada atributo
por separado
– Identificación de la sensibilidad de los atributos de calidad de
varios atributos arquitectónicos para un estilo de arquitectura
específico
– Crítica de las arquitecturas candidatas
Evaluación de las arquitecturas de
software
• Complejidad arquitectónica
– Una técnica útil para evaluar la complejidad general de una
arquitectura determinada consiste en considerar las dependencias
entre componentes dentro de la arquitectura.

• Tipos de dependencias:
– Dependencias compartidas, representan relaciones de dependencia
entre consumidores que usan el mismo recurso o los productores que
producen para los mismos consumidores.
– Dependencias de flujo, representan las relaciones de dependencia
entre productores y consumidores de recursos.
– Dependencias de restricción, representan restricciones al flujo relativo
de control entre un conjunto de actividades.
Evaluación de las arquitecturas de
software

Lenguajes de descripción arquitectónica

• Proporciona una semántica y una sintaxis para


describir una arquitectura del software

• Proporcionar al diseñador la capacidad de separar


componentes arquitectónicos, de integrar
componentes individuales en bloques arquitectónicos
mayores y de representar interfaces entre
componentes
Diseño Arquitectónico
• Flujo de transformación
– Trayectoria de flujo de entrada. Los datos se
transforman de una representación del mundo
exterior a una forma internalizada

– Centro de transformación. Los datos se procesan

– Trayectoria de flujo de salida. Transforma los datos


a una forma del mundo exterior
Mapeo de la Arquitectura
• Mapeo de Transformación
– Es un conjunto de pasos de diseño que permite que un Diagrama de Flujo de Datos
(DFD) con características de flujo de transformación se correlacione con un estilo
arquitectónico específico
• Pasos de diseño
– Paso 1. Revisar el modelo fundamental del sistema
– Paso 2. Revisar y refinar los diagramas de flujo de datos para el software
– Paso 3. Determinar si el DFD tiene características de flujo de transformación o de
transacción
– Paso 4. Aislar el centro de transformación al especificar límites de flujo de entrada y
salida
– Paso 5. Realizar una factorización de primer nivel. La factorización genera una estructura
de programa en que los componentes descendentes se encargan de la toma de
decisiones ylos componentes de bajo nivel realizan más trabajo de entrada, cálculo y
salida
– Paso 6. Realice una "factorización de segundo nivel"
– Paso 7. Refinar la arquitectura de primera iteración empleando diseño heurístico para
mejorar la calidad del software
Mapeo de la Arquitectura

Refinamiento del diseño arquitectónico

• Debe estimularse el refinamiento de la arquitectura


del software durante las primeras etapas del diseño

• Debe perseguir el menor número de componentes


que sea consistente con la modularidad efectiva y la
estructura de datos menos compleja que cumpla de
modo adecuado con los requerimientos de
información
Diseño en el Nivel de Componentes

¿Qué es?

Define las estructuras de datos, algoritmos,


características de la interfaz y mecanismos de
comunicación asignados a cada componente del
software
Diseño en el Nivel de Componentes
• ¿Qué es un componente?
– Es un bloque de construcción de software de cómputo
– Parte modular, desplegable y sustituible de un
sistema, que incluye la implantación y expone un
conjunto de interfaces
– Forman la arquitectura del software
– Juegan un papel en el logro de los objetivos y de los
requerimientos del sistema que se va a construir
– Deben comunicarse y colaborar con otros
componentes y con entidades que existen fuera de las
fronteras del software
Diseño en el Nivel de Componentes

Visión orientada a objetos

• Un componente contiene un conjunto de clases que


colaboran

Visión relacionada con el proceso

• El componente se diseña desde la nada


• Se crea un nuevo componente con base en las
especificaciones obtenidas del modelo de
requerimientos
Diseño en el Nivel de Componentes
• Visión tradicional
– Un componente es un elemento funcional de un programa
que incorpora la lógica del procesamiento, las estructuras
de datos internas que se requieren para implantar la lógica
del procesamiento y una interfaz que permite la
invocación del componente y el paso de los datos
– Módulo
o Componente de control, coordina la invocación de todos los
demás componentes del dominio del problema
o Componente del dominio del problema, implanta una función
completa o parcial que requiere el cliente
o Componente de infraestructura, responsable de las funciones que
dan apoyo al procesamiento requerido en el dominio del problema
Diseño de Componentes
Basados en Clase
• Principios básicos del diseño
– Principio Abierto-Cerrado. Debe especificarse el
componente en forma tal que permita extenderlo sin
necesidad de hacerle modificaciones internas
– Principio de sustitución de Liskov. Cualquier clase
derivada de una clase de base debe respetar cualquier
contrato implícito entre la clase de base y los componentes
que la usan
– Principio de Inversión de la Dependencia. Las
abstracciones son el lugar en el que es posible ampliar un
diseño sin muchas dificultades
– Principio de segregación de la interfaz. Es mejor tener
muchas interfaces específicas del cliente que una sola de
propósito general
Diseño de Componentes
Basados en Clase
• Principios básicos del diseño (cont.)
– Principio de equivalencia de la liberación de la
reutilización. El gránulo de reutilización es el
gránulo de liberación
– Principio de cierre común. Las clases que cambian
juntas pertenecen a lo mismo
– Principio de la reutilización común. Las clases que
no se reutilizan juntas no deben agruparse juntas
Diseño de Componentes
Basados en Clase
¿Qué es lo que hay que tomar en cuenta al dar nombre
a los componentes?
• Componentes. Deben establecerse convenciones para
dar nombre a los componentes. Deben provenir del
dominio del problema y significar algo para todos los
participantes que vean el modelo arquitectónico
• Interfaces. Dan información importante sobre la
comunicación y la colaboración
• Dependencias y herencia. Modelar las dependencias
de izquierda a derecha y la herencia de abajo hacia
arriba
Diseño de Componentes
Basados en Clase
Cohesión
• Implica que un componente o clase sólo contiene atributos y
operaciones que se relacionan de cerca uno con el otro y con la
clase o componente en sí

Tipos de cohesión
• Funcional. Ocurre cuando un componente realiza un cálculo y
luego devuelve el resultado
• De capa. Ocurre cuando una capa más alta accede a los servicios
de otra más baja, pero ésta no tiene acceso a las superiores
• De comunicación. Las clases se centran únicamente en los datos
en cuestión, acceden a ellos y los guardan
Diseño de Componentes
Basados en Clase
Acoplamiento

• Es la medición cualitativa del grado en el que


las clases se conectan una con otra
• Conforme las clases (y componentes) se
hacen más interdependientes, el
acoplamiento crece
• Un objetivo importante del diseño en el nivel
de componente es mantener el acoplamiento
tan bajo como sea posible
Diseño de Componentes
Basados en Clase
• Categorías de acoplamiento
– Acoplamiento de contenido. Tiene lugar cuando un
componente modifica datos internos en otro componente
– Acoplamiento común. Sucede cuando cierto número de
componentes hacen uso de una variable global
– Acoplamiento del control. Tiene lugar si la operación A( )
invoca a la operación B( ) y pasa una bandera de control a
B. La bandera dirige el flujo de la lógica dentro de B
– Acoplamiento de molde. Se presenta cuando se declara a
ClaseB como un tipo para un argumento de una operación
de ClaseA
Diseño de Componentes
Basados en Clase
• Categorías de acoplamiento (cont.)
– Acoplamiento de datos. Ocurre si las operaciones pasan
cadenas largas de argumentos de datos
– Acoplamiento de rutina de llamada. Tiene lugar cuando
una operación invoca a otra
– Acoplamiento de tipo de uso. Ocurre si el componente A
usa un tipo de datos definidos en el componente B
– Acoplamiento de inclusión o importación. Pasa cuando el
componente A importa o incluye un paquete o el
contenido del componente B.
– Acoplamiento externo. Sucede si un componente se
comunica o colabora con componentes de infraestructura
Diseño en el Nivel de Componentes
• Pasos
– Identificar todas las clases de diseño que correspondan al
dominio del problema
– Identificar todas las clases de diseño que correspondan al
dominio de la infraestructura
– Elaborar todas las clases de diseño que no sean
componentes reutilizables
– Especificar detalles del mensaje cuando colaboren clases o
componentes
– Identificar interfaces apropiadas para cada componente
– Elaborar atributos y definir tipos y estructuras de datos
requeridos para implantarlos
Diseño en el Nivel de Componentes
– Pasos (cont.)
• Describir en detalle el flujo del procesamiento dentro
de cada operación
• Describir las fuentes persistentes de datos e identificar
las clases requeridas para administrarlos
• Desarrollar y elaborar representaciones del
comportamiento para una clase o componente
• Elaborar diagramas de despliegue para dar más detalles
de la implantación
• Rediseñar cada representación del diseño en el nivel de
componentes y siempre considerar alternativas
Diseño en el Nivel de Componentes
para Webapps

Componente de webapp

• Función cohesiva bien definida que manipula contenido o da


procesamiento de cómputo o de datos para un usuario final
• Paquete cohesivo de contenido y funciones que brindan al
usuario final alguna capacidad solicitada

Diseño del contenido en el nivel de componente

• Se centra en objetos de contenido y en la forma en la que se


empacan para su presentación a un usuario final de webapps
• La formalidad debe adaptarse a las características de la webapp
que se va a elaborar
Diseño en el Nivel de Componentes
para Webapps
• Funciones de las Webapps
– Producen un procesamiento localizado que genera
contenido y capacidad de navegación en forma dinámica
– Dan capacidad de computación o procesamiento de datos
que resultan adecuados para el dominio del negocio de la
webapp
– Brindan consultas y acceso avanzado a una base de datos
– Establecen interfaces de datos con sistemas corporativos
externos
– Arquitectura funcional, representación del dominio de
funciones de la webapp y describe los componentes
funcionales clave de la webapp y la forma en la que
interactúan una con otra
Diseño de Componentes Tradicionales

Secuencia

• Implementa pasos de procesamiento que son esenciales en la


especificación de cualquier algoritmo

Condición

• Proporciona el medio para seleccionar un procesamiento con


base en algún suceso lógico

Repetición

• Permite la ejecución de lazos


Diseño de Componentes Tradicionales
Notación gráfica de diseño
Diseño de Componentes Tradicionales
Notación del diseño tabular
• Las tablas de decisión, proporcionan una notación que traduce las acciones y
condiciones a una forma tabular
¿Cómo elaboro una tabla de decisión?
• Enlistar todas las acciones asociadas con un procedimiento específico
• Enlistar todas las condiciones durante la ejecución del procedimiento
• Asociar conjuntos específicos de condiciones con acciones específicas, con la
eliminación de las combinaciones o con condiciones imposibles; de manera
alternativa, desarrollar toda posible permutación de las condiciones.
• Definir reglas indicando qué acciones suceden para un conjunto dado de
condiciones

Lenguaje de diseño del programa


• incorpora la estructura lógica de un lenguaje de programación y la
expresividad de forma libre de un lenguaje natural
Desarrollo Basado en Componentes
• Ingeniería de software basada en componentes
– Es un proceso que pone el énfasis en el diseño y construcción de sistemas
basados en computadora que emplean componentes reutilizables de software

• Preguntas:
– ¿Es posible construir sistemas complejos con el ensamble de componentes
reutilizables de software procedentes de un catálogo?
– ¿Se logra esto en forma eficaz en cuanto a costo y tiempo?
– ¿Pueden establecerse incentivos apropiados que estimulen a los ingenieros de
software a reutilizar, más que a reinventar?
– ¿La dirección está dispuesta a incurrir en los gastos adicionales asociados a la
creación de componentes de software reutilizables?
– ¿Es posible crear la biblioteca de componentes necesarios para conseguir la
reutilización en forma tal que sea accesible a quienes los necesitan?
– ¿Quienes necesitan los componentes que ya existen pueden encontrarlos?
Desarrollo Basado en Componentes

Ingeniería del dominio


• Identifica, construye, cataloga y disemina un conjunto de
componentes de software que sean aplicables al software
existente y al del futuro en un dominio particular de aplicaciones

Los pasos de este proceso


• Definir el dominio que se va a investigar
• Clasificar los aspectos extraídos del dominio
• Reunir una muestra representativa de aplicaciones en el dominio
• Analizar cada aplicación en la muestra y definir clases de análisis
• Desarrollar un modelo de los requerimientos para las clases.
Desarrollo Basado en Componentes
Calificación de componentes
• Garantiza que un componente candidato ejecute la función requerida, encaje en forma
adecuada en el estilo arquitectónico especificado para el sistema y tenga las
características de calidad que se requieren para la aplicación

Factores que se consideran durante la calificación de componentes


• Aplicación de programación de la interfaz (API)
• Herramientas de desarrollo e integración requeridas por el componente
• Requerimientos durante la puesta en marcha, incluidos el uso de recursos, sincronía o
velocidad y protocolo de redes
• Requerimientos de servicio, incluidos interfaces del sistema operativo y apoyo de otros
componentes
• Características de seguridad, incluidos controles de acceso y protocolo de
autentificación
• Suposiciones incrustadas en el diseño, incluido el empleo de algoritmos específicos
• Manejo de excepciones
Desarrollo Basado en Componentes
• Adaptación de componentes
– Envoltura de caja blanca. Cuando un equipo de
software tiene acceso total al diseño y código interno
de un componente
– Envoltura de caja gris. Cuando la biblioteca de
componentes proporciona un lenguaje de extensión
del componente o API que permite que los conflictos
se eliminen o se anulen
– Envoltura de caja negra. Requiere la introducción de
procesamiento previo y posterior en la interfaz del
componente para eliminar o anular los conflictos
Desarrollo Basado en Componentes
Combinación de componentes

• Ensambla componentes calificados, adaptados y con la ingeniería necesaria para


incluirse en la arquitectura establecida para una aplicación

Análisis y diseño para la reutilización

• El modelo de requerimientos se analiza para determinar qué elementos apuntan


hacia componentes reutilizables ya existentes

Aspectos clave para la reutilización

• Datos estándar. El dominio de la aplicación debe investigarse y tienen que


identificarse las estructuras de datos globales estándar
• Protocolos de interfaz estándar
• Plantillas de programa. Se elige un estilo arquitectónico que sirve como plantilla
para el diseño de la arquitectura del nuevo software
Desarrollo Basado en Componentes

Clasificación y recuperación de componentes


• Concepto. Descripción de lo que hace el componente
• Contenido. Describe cómo se lleva a cabo el concepto
• Contexto. Coloca un componente de software
reutilizable en su dominio de aplicabilidad
• Biblioteca de reutilización. Es un elemento de un
repositorio mayor de software y brinda herramientas
para el almacenamiento de componentes de software,
así como una amplia variedad de productos finales
reutilizables
Cuándo Utilizar un <<include>> y <<extend>>

Casos a incluir y casos a extender

Un tema que genera mucha polémica entre la gente que modela casos de uso es la
elección entre la relación de <<include>> y <<extend>>. Lo peor es que muchas de esas
discusiones generan muy poco valor en el resultado final en el modelo y en cambio
quitan tiempo valioso del proyecto. Esto se debe a que dichas relaciones, muchas veces
no son del todo comprendidas por la persona que la modela, y mucho menos son
comprendidas por las personas que leen el modelo. Así que al final no se le saca el
provecho que en todo caso debería de tener dicha elección.

Es mejor mantener el modelo simple, incluso si esto significa utilizar menos elementos
gráficos de UML, si eso va a facilitar el modelado y la comunicación en el proyecto.
Pero, después de todo este tiempo y de los diferentes temas que hemos venido tratando,
es importante avanzar y adentrarnos en algunos pormenores del lenguaje unificado.

Antes que todo, ¿qué es el “include” y el “extend”?

Gráficamente lo que mostramos es una relación de dependencia entre el par de casos de


uso, con el nombre correspondiente al tipo de relación de la que se trate: ya sea
<<include>> o <<extend>>.

Estas, son relaciones que usamos para ligar gráficamente dos casos de uso, cuyos flujos
de eventos están unidos, normalmente en una sola sesión del usuario. En otras palabras,
un caso de uso que está ligado, por medio de una de estas dos relaciones, a otro caso de
uso; también podría leerse o ejecutarse como un sólo caso de uso en lugar de dos.
Obviamente, hay una razón por la cual decidimos separarlos en dos, lo cual explicaremos
más adelante.

Imagina el conjunto de pasos que ocurren al realizar una compra en una tienda
departamental. Seguramente no tendrás problema en visualizar el conjunto de pasos para
solicitar la autorización de la tarjeta de crédito con la que vas a pagar, ligado a los pasos
donde el vendedor registra los productos a comprar. Es decir, los flujos de eventos de
ambos procesos forman una sola cosa; juntos podrían formar un solo caso de uso, en
lugar de dos casos de uso unidos por alguna de estas relaciones que aquí estamos
tratando.
Figura 1. Relacionando casos de uso

Include. En términos muy simples, cuando relacionamos dos casos de uso con un
“include”, estamos diciendo que el primero (el caso de uso base) incluye al segundo (el
caso de uso incluido). Es decir, el segundo es parte esencial del primero. Sin el segundo,
el primero no podría funcionar bien; pues no podría cumplir su objetivo. Para una venta
en caja, la venta no puede considerarse completa si no se realiza el proceso para cobrarla
en ese momento. El caso de uso “Cobrar Renta” está incluido en el caso de uso “Rentar
Video”, o lo que es lo mismo “Rentar Video” incluye (<<include>>) “Cobrar Renta”.

Figura 2. Ejemplo de Include

Extend. La polémica al querer seleccionar una de las dos relaciones es que en el “extend”
también podemos ver, desde la perspectiva del usuario, a los dos flujos como si fueran
uno sólo. Y en ciertos escenarios el caso de uso base no podría cumplir su objetivo si no
se ejecutara la extensión. Pero, una de las diferencias básicas es que en el caso del
“extend” hay situaciones en que el caso de uso de extensión no es indispensable que
ocurra, y cuando lo hace ofrece un valor extra (extiende) al objetivo original del caso de
uso base. En cambio en el “include” es necesario que ocurra el caso incluido, tan sólo
para satisfacer el objetivo del caso de uso base. Ejemplo: Puedes “Realizar Venta” sin
“Acumular Puntos de Cliente VIP”, cuando no eres un cliente VIP. Pero, si eres un
cliente VIP sí acumularás puntos. Por lo tanto, “Acumular Puntos” es una extensión de
“Realizar Venta” y sólo se ejecuta para cierto tipo de ventas, no para todas.
Figura 3. Ejemplo de Extend

Casos de Abuso

Uno de los riesgos que existe cuando la gente sabe que tiene estas relaciones como un
elemento a utilizar en sus modelos de casos de uso, consiste en su abuso. Mucha gente, y
sobre todo la que arrastra prácticas de métodos estructurados, la suele utilizar en exceso.
No es raro ver modelos de casos de uso que llegan a tener decenas de inclusiones y
extensiones, incluso las inclusiones y extensiones se vuelven a extender a varios niveles,
generando una maraña de casos de uso que no ofrecen valor al ser mostrados
explícitamente.

Figura 4. Abuso de relaciones

Es importante comprender que el objetivo de estos tipos de relaciones NO consiste


(remarco la negación) en motivar la división de los casos de uso en la mayor cantidad de
pedazos. Debe de existir una razón importante para que decidamos dividir un caso de uso
en dos que serán unidos por medio de alguna de estas relaciones. Si entendemos esto y
somos congruentes, obtendremos un beneficio real para el proyecto; fin último del uso de
UML.
La razón por la que la gente suele partir sus casos de uso en infinidad de “include” y
“extend” es porque quieren conocer, entender y comunicar el máximo detalle de los casos
de uso en el diagrama. Hay quien llega a utilizar, erróneamente, estas relaciones para
mostrar el orden en que se ejecutan estos casos de uso. Debemos de recordar que al
modelar el diagrama de casos de uso no buscamos analizar el detalle, y mucho menos los
flujos. Todo ese detalle lo podremos plasmar en otro tipo de diagramas, como los
diagramas de interacción, de actividad, de estados, o simplemente un texto en una
especificación.

Relaciones de Análisis o Diseño

Otra situación donde abusamos de estas relaciones se da cuando queremos representar la


unión de casos de uso por una decisión de diseño del sistema, específicamente por una
decisión de navegabilidad entre funciones. Pensemos en cierta funcionalidad en un
sistema, la cual corresponde a la ejecución de cierto caso de uso (por ejemplo “Registrar
Préstamo de un Video”). Y estando en dicho caso de uso tienes a la vista en la pantalla, y
decides utilizar, un botón que te permitiría iniciar otro caso de uso que tiene poco o nada
que ver con el objetivo del caso de uso inicial (digamos, “Consultar Promociones”). Esto
no debería de mostrarse como una relación entre estos dos casos de uso en el modelo.

No deberíamos modelar al primer caso de uso incluyendo ni siendo extendido con el


segundo caso de uso ni viceversa, pues la razón por la que se ligaron (no gráficamente,
sino en su ejecución) fue por una facilidad otorgada por la manera en que se diseño el
sistema, la cual permite navegar fácilmente entre las diferentes funciones del sistema. La
navegabilidad que otorga el sistema entre uno y otro caso de uso normalmente tiene que
ver poco con que exista o no una relación entre dichos casos de uso.

Reuso: Evitando el Retrabajo

Una de las razones por las cuales deberías de considerar el uso de este tipo de relaciones,
es porque identificas que hay pasos que son iguales en dos o más casos de uso. No
querrás tener que escribir y darle mantenimiento a esos pasos en los documentos
asociados a cada uno de ellos. Peor aún, no querrás correr el riesgo de que esos pasos se
diseñen, programen y prueben de maneras diferentes y con esfuerzos aislados por ti o tu
equipo de desarrollo. Finalmente son la misma cosa, ¿para qué querríamos trabajar
doble? Lo que queremos es economizar, ser más eficientes en el desarrollo, y ahí es
cuando viene el beneficio de identificar estos tipos de relaciones; porque es una
oportunidad de identificar reuso.
Figura 5. Identificación de reuso

Si te sientes preparado para desarrollar modelos de casos de uso más sofisticados y de


mayor valor, entonces considera la posibilidad de utilizar estos tipos de relaciones. Sólo
asegúrate de aprovecharlas adecuadamente, buscando el beneficio real que deberían de
proporcionar en tu modelo y proyecto con base en las recomendaciones mencionadas. Y
recuerda unificar los criterios dentro de tu empresa para que el lenguaje sea realmente
unificado o estandarizado dentro de tu empresa.
Diagramas de Casos de Uso

UNPSJB - 2005 Ingeniería de Software - Clase 6 1


Casos de Uso www.dsic.upv.es/~uml

• Los Casos de Uso (Ivar Jacobson) • Comparación con respecto a los Diagramas de
describen bajo la forma de Flujo de Datos del Enfoque Estructurado
acciones y reacciones el • Un caso de uso es una función atómica
ofrecida por el sistema al entorno (actores)
comportamiento de un sistema
• DFD puede ser detallada en un DFD Hijo
desde el p.d.v. del usuario
• Caso Uso y Proceso igual modelado, pero
• Permiten definir los límites del caso de uso expresa funcionalidad mediante
sistema y las relaciones entre el interacción de actores
sistema y el entorno • Caso de uno no modela detalle funcional
interno
• Los Casos de Uso son • Relaciones de extensión y generalización de
descripciones de la funcionalidad CU no tienen igual en DFD
del sistema independientes de la
implementación

UNPSJB - 2005 Ingeniería de Software - Clase 6 2


… Casos de Uso www.dsic.upv.es/~uml

• Los Casos de Uso cubren la


carencia existente en métodos
previos (OMT, Booch) en cuanto
a la determinación de requisitos
• Los Casos de Uso particionan el
conjunto de necesidades Caso de Uso A
atendiendo a la categoría de Actor A
usuarios que participan en el
mismo
• Están basado en el lenguaje Caso de Uso B
Actor B

natural, es decir, es accesible


por los usuarios

UNPSJB - 2005 Ingeniería de Software - Clase 6 3


… Casos de Uso www.dsic.upv.es/~uml

• Actores:
• Principales: personas que usan el sistema
• Secundarios: personas que mantienen o administran el sistema
• Material externo: dispositivos materiales imprescindibles que forman parte del ámbito de la
aplicación y deben ser utilizados
• Otros sistemas: sistemas con los que el sistema interactúa
• La misma persona física puede interpretar varios papeles como actores distintos
• El nombre del actor describe el papel desempeñado

UNPSJB - 2005 Ingeniería de Software - Clase 6 4


… Casos de Uso www.dsic.upv.es/~uml

• Los Casos de Uso se determinan observando y precisando, actor por actor, las
secuencias de interacción, los escenarios, desde el punto de vista del usuario
• Un escenario es una instancia de un caso de uso
• Los casos de uso intervienen durante todo el ciclo de vida. El proceso de
desarrollo estará dirigido por los casos de uso

UNPSJB - 2005 Ingeniería de Software - Clase 6 5


Casos de Uso: Relaciones www.dsic.upv.es/~uml

• UML define cuatro tipos • Inclusión: una instancia del


de relación en los Caso de Uso origen incluye
Diagramas de Casos de también el comportamiento
descrito por el Caso de Uso
Uso: destino

• Comunicación <<include>>

Caso de Uso Origen Caso de Uso Destino

Caso de Uso
Actor
<<include>> reemplazó al
denominado <<uses>>

UNPSJB - 2005 Ingeniería de Software - Clase 6 6


… Casos de Uso: Relaciones www.dsic.upv.es/~uml

• Herencia: el Caso de Uso


• Extensión: el Caso de origen hereda la
Uso origen extiende el especificación del Caso
comportamiento del de Uso destino y
Caso de Uso destino posiblemente la
modifica y/o amplía
<<extend>>

Caso de Uso Origen Caso de Uso Destino


Caso de Uso Hijo Caso de Uso Padre

UNPSJB - 2005 Ingeniería de Software - Clase 6 7


… Casos de Uso: Relaciones www.dsic.upv.es/~uml

• Ejemplo:
Identificación
<<include>>

Transferencia
Cliente

<<extend>>

Transferencia en Internet

UNPSJB - 2005 Ingeniería de Software - Clase 6 8


… Casos de Uso: Relaciones www.dsic.upv.es/~uml

• Ejemplo:

UNPSJB - 2005 Ingeniería de Software - Clase 6 9


Casos de Uso: Construcción www.dsic.upv.es/~uml

• Un caso de uso debe ser simple, inteligible, claro y conciso


• Generalmente hay pocos actores asociados a cada Caso de Uso
• Preguntas clave:
• ¿cuáles son las tareas del actor?
• ¿qué información crea, guarda, modifica, destruye o lee el actor?
• ¿debe el actor notificar al sistema los cambios externos?
• ¿debe el sistema informar al actor de los cambios internos?

UNPSJB - 2005 Ingeniería de Software - Clase 6 10


… Casos de Uso: Construcción www.dsic.upv.es/~uml

• La descripción del Caso de Uso comprende:


• el inicio: cuándo y qué actor lo produce?
• el fin: cuándo se produce y qué valor devuelve?
• la interacción actor-caso de uso: qué mensajes intercambian ambos?
• objetivo del caso de uso: ¿qué lleva a cabo o intenta?
• cronología y origen de las interacciones
• repeticiones de comportamiento: ¿qué operaciones son iteradas?
• situaciones opcionales: ¿qué ejecuciones alternativas se presentan en el caso de uso?

UNPSJB - 2005 Ingeniería de Software - Clase 6 11


RF- <id del requisito> <nombre del requisito funcional>
Versión <numero de versión y fecha>
Autores <autor>
Fuentes <fuente de la versión actual>
Objetivos asociados <nombre del objetivo>
Descripción El sistema deberá comportarse tal como se describe en
el siguiente caso de uso { concreto cuando <evento de
activación> , abstracto durante la realización de los
casos de uso <lista de casos de uso>}
Precondición <precondición del caso de uso>
Secuencia Paso Acción
Normal 1 {El <actor> , El sistema} <acción realizada por el
actor o sistema>, se realiza el caso de uso
< caso de uso RF-x>
2 Si <condición>, {el <actor> , el sistema} <acción
realizada por el actor o sistema>>, se realiza el
caso de uso < caso de uso RF-x>
3
4
5
6
n
Postcondición <postcondición del caso de uso>
Excepciones Paso Acción
1 Si <condición de excepción>,{el <actor> , el
sistema} }<acción realizada por el actor o
sistema>>, se realiza el caso de uso
< caso de uso RF-x>, a continuación este caso
de uso {continua, aborta}
2
3
Rendimiento Paso Cota de tiempo
1 n segundos
2 n segundos
Frecuencia esperada <nº de veces> veces / <unidad de tiempo>
Importancia {sin importancia, importante, vital}
Urgencia {puede esperar, hay presión, inmediatamente}
Comentarios <comentarios adicionales>
UNPSJB - 2005 Ingeniería de Software - Clase 6 12
Modelo de Casos de Uso y
Modelo Conceptual (Análisis)
www.dsic.upv.es/~uml

• La especificación de cada caso de uso y los correspondientes D. de Interacción


establecen el vínculo con el modelo conceptual
• En métodos OO que carecen de una técnica de captura de requisitos se
comienza inmediatamente con la construcción del modelo conceptual
(análisis)

UNPSJB - 2005 Ingeniería de Software - Clase 6 13