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?