Curso Proyin F Inicio y Analisis

Instituto Tecnológico de Culiacán
Proyecto Integrador de
Ingeniería de Software
Introducción
¿ Qué es Ingeniería de Software ?
• El establecimiento y uso de principios de ingeniería

robustos, orientados a obtener software económico que
sea fiable y funcione de manera eficiente sobre máquinas
reales. (Fritz Bauer 1969)
• La ingeniería de software es la aplicación de un enfoque

sistemático, disciplinado y cuantificable al desarrollo,
operación y mantenimiento del software.[IEEE93]
Introducción
Orientación a Objetos
Vivimos en un mundo de objetos. Estos objetos existen en

la naturaleza, en entidades hechas por el hombre, en los
negocios y en los productos que usamos. Pueden ser
clasificados, descritos, organizados, combinados,
manipulados y creados. Por eso no es sorprendente que se
proponga una visión orientada a objetos para la creación de
software de computadora, una abstracción que modela el
mundo de forma tal que nos ayuda a entenderlo y
gobernarlo mejor.
Introducción
El término orientado a objetos significa que el software se

organiza como una colección de objetos que contienen tanto
estructuras de datos como comportamiento.
Introducción
OBJETOS BICICLETA
Bicicleta
Tam.del cuadro
Se hace una
Tam. De la rueda
abstracción que
marchas
resulta en
material
Cambiar marcha()
mover()
reparar()
Introducción
El atractivo intuitivo de la orientación a objetos es que

proporciona conceptos y herramientas con las cuales se
modela y representa el mundo real tan fielmente como sea
posible. Estos conceptos y herramientas orientados a
objetos son tecnologías que permiten que los problemas del
mundo real sean expresados de modo fácil y natural.
Introducción
Programar es divertido,
Pero desarrollar software de calidad es difícil.
Entre las ideas espléndidas, los requisitos y un producto software
funcionando, hay mucho más que sólo programar:
Debemos realizar los planos (análisis y diseño) que definen cómo
solucionar el problema para obtener un producto software.
Definir el modelo arquitectónico
Aplicar la ingeniería de usabilidad.
Diseñar la Base de Datos
Etcétera.
Introducción Análisis
¿Qué es el análisis?
Es el estudio de un dominio que da como resultado los
modelos que describen sus características estáticas y
dinámicas. Se centra en las cuestiones del “que” en
lugar del “como”.
ESPACIO DEL PROBLEMA
Pone énfasis en una investigación del problema y los
requisitos, en vez de ponerlos en una solución.
“Análisis” es un término amplio, es más adecuado
calificarlo como análisis de requisitos (un estudio de los
requisitos) o análisis de objetos (estudios de objetos del
dominio)
¿Qué es el análisis orientado a objetos?
Es un método de análisis que examina los requisitos desde
la perspectiva de las clases y objetos que se encuentran
en el vocabulario del dominio del problema (Booch 1994)
Introducción Análisis
Análisis Orientado a Objetos.

Se presta especial atención a encontrar y describir
los objetos en el dominio del problema.
Ejemplos:
En el caso del sistema de renta de auto: Auto,
Cliente, Aseguradora, etc.
En el caso del sistema de la biblioteca: Libro,
Biblioteca, Socio
En el caso del sistema de vuelos: Pasajeros,
Aviones,…
Introducción Diseño
Diseño:
Pone énfasis en una solución conceptual que satisface los requisitos,

en vez de ponerlo en la implementación.
Diseño orientado a objetos
Se presta especial atención a la definición de los objetos software y
en cómo colaboran para satisfacer los requisitos. Ejemplos:
ESPACIO DE LA SOLUCIÓN
Objeto LIBRO Titulo Atributo
GetCap(int c) Operación
Una habilidad crítica en el desarrollo OO es la asignación inteligente de

responsabilidades a los objetos software
Introducción Análisis y Diseño
Plane
visualization of
domain concept tailNumber domain concept
public class Plane

{
representation in an private String tailNumber;
object-oriented
programming language public List getFlightHistory() {...}
}
Introducción Análisis y Diseño
El análisis y diseño se han resumido en las freses:

• Hacer lo correcto
(análisis)
• Hacerlo correcto
(diseño)
Proceso de desarrollo de
software
Un proceso de desarrollo de software es
un conjunto de actividades necesarias
para transformar los requerimientos del
usuario en un sistema de software.
Proceso de Desarrollo de
Requerimientos Software
Sistema Software
del usuario
Proceso de desarrollo de software:
Motivación
Hoy en día la tendencia del software es hacia sistemas
más grandes y complejos. Esta tendencia también ha
sido influenciada por el extensivo uso del internet para
intercambiar todo tipo de información. Queremos
software que esté mejor adaptado a nuestra
necesidades, aunque éste sea cada vez más complejo.
En resumen queremos cada vez más.
También lo queremos más rápido, el tiempo para
construirlo es otro factor importante. Nuestra demanda
de software complejo y poderoso no concuerda con el
cómo será desarrollado dicho software. Hoy en día, la
gente desarrolla software usando métodos que fueron
usados desde hace 35 años.
Proceso de desarrollo de software
La comunidad de desarrollo de software
necesita una manera de controlar el
trabajo. Se necesita un proceso que
integre las muchas facetas del desarrollo
de software.
Proceso de desarrollo de software
Necesitamos un método común, un proceso que:
Proporcione una guía para el orden de las

actividades del equipo
Dirija las tareas de los desarrolladores
individualmente y del equipo como un todo.
Especifique que artefactos deben ser
desarrollados
Ofrezca criterios para monitorear y medir las
actividades y productos de un proyecto.
El marco del Proceso Unificado
(UP, del inglés Unified Process)
La presencia de un proceso bien definido
y bien manejado es un discriminador clave
entre un proyecto productivo y exitoso y
uno que no lo es.
El proceso unificado, se ha convertido
en un proceso de desarrollo de software
de gran éxito para la construcción de
sistemas orientados a objetos.
El marco del Proceso Unificado
El UP utiliza el lenguaje unificado para la
creación de modelos (UML). De hecho, UML es
una parte integral del Proceso Unificado, fueron
desarrollados a la par.
Los aspectos que realmente distinguen al
Proceso Unificado se capturan en tras frases
claves:
 Conducido por casos de uso
 Centrado en la arquitectura
 Iterativo e incremental
El PU conducido por casos de
uso
Ejemplo: uso de un cajero automático.
El usuario inserta una tarjeta, responde a las
preguntas que emite el cajero en su pantalla y
recibe una suma de efectivo.
En respuesta a la tarjeta del usuario y sus
preguntas, el sistema realiza una secuencia de
acciones que provee al usuario un resultado
de valor, llamado retiro de fondos.
Una interacción de este tipo es un caso de
uso.
uso
Un caso de uso es una pieza de
funcionalidad en el sistema que da al usuario
un resultado de valor.
Los casos de uso capturan los
requerimientos funcionales.
Todos los casos de uso juntos, construyen el
modelo de casos de uso el cual describe la
funcionalidad completa del sistema.
uso
Los casos de uso no solo son una herramienta
para especificar los requerimientos de un
sistema; también conducen su :
 Diseño,
 Implementación y,
 Prueba.
Es decir,
los casos de uso conducen el proceso

de desarrollo.
El PU centrado en la arquitectura
El rol de la arquitectura del software es similar
en naturaleza al rol que juega la arquitectura en
la construcción de un edificio.
El edificio es observado desde varios puntos de
vista: estructura, servicios, electricidad, etc.
Similarmente, la arquitectura en un sistema de
software se describe con diferentes vistas del
sistema que será construido.
El concepto de arquitectura del software abarca
los aspectos estáticos y dinámicos del sistema.
La arquitectura está influenciada por otros factores tales como:
la plataforma sobre la cual se va a ejecutar el sistema
bloques reusables disponibles
consideraciones de distribución
sistemas heredados y requerimientos no funcionales
Requerimientos no funcionales: en la ingeniería de software es
un requerimiento que especifica criterios que pueden usarse
para juzgar la operación de un sistema en lugar de sus
comportamientos específicos, ya que éstos corresponden a los
requerimientos funcionales.
A un sistema se le puede pedir que muestre en tiempo real la
cantidad de datos de una base de datos: ése es un
requerimiento funcional. En cuánto tiempo debería el sistema
actualizar su verificación interna de cantidad de datos es, en
cambio, un requerimiento no funcional.
¿Cómo se relacionan los casos de uso y la
arquitectura?
Cada producto tiene función y forma. Uno o el
otro no es suficiente. Estas dos fuerzas
deben estar balanceadas par obtener un
producto exitoso. En este caso la función
corresponde a los casos de uso y la forma a
la arquitectura. Se necesita, por lo tanto, la
interacción entre los casos de uso y la
arquitectura.
El arquitecto moldea el sistema en una forma.
Esa forma, la arquitectura, debe ser diseñada
de manera tal, que permita al sistema
evolucionar, no solamente a través de su
desarrollo inicial, sino a través de futuras
generaciones.
Para encontrar tal forma, los arquitectos deben
tener un entendimiento general de las funciones
claves, esto es, los casos de uso claves del
sistema.
El PU es iterativo e incremental
Bajo este enfoque, el desarrollo se organiza en
una serie de mini-proyectos cortos, de duración
fija (por ejemplo, cuatro semanas) llamados
iteraciones.
El resultado de cada uno es un sistema que
puede ser probado, integrado y ejecutado.
Cada iteración incluye sus propias actividades
de análisis de requisitos, diseño implementación
y pruebas.
El ciclo de vida iterativo se basa en la ampliación y
refinamiento sucesivos del sistema mediante múltiples
iteraciones, con retroalimentación cíclica y adaptación
como elementos principales que nos conducen hacia un
sistema adecuado.
El sistema crece incrementalmente a lo largo del tiempo,
iteración tras iteración, por eso se dice que es iterativo
e incremental.
Proceso Iterativo Incremental: se dice que un proceso es
iterativo incremental cuando en cada iteración de sus
pasos se alcanza una mayor cercanía con los objetivos
finales. Esto es, se añade algo nuevo de valor en cada
iteración.
La retroalimen-
tación de la ite-
Requisitos ración N nos lle
Requisitos
va a refinar y
Diseño
Diseño adaptar los re-
Implementación & quisitos y diseño
TIEMPO de la iteración N+1.
Implementación & Prueba & Integra-
Prueba & Integra- ción & más diseño
ción & más diseño
Integración final &
Integración final & Pruebas de sistema
Pruebas de sistema
4 semanas (por ejemplo)
Se fija la duración de El sistema crece

Las iteraciones de manera incremental
El resultado de cada iteración es un
sistema ejecutable, pero incompleto; no
está preparado par ser puesto en
producción. El sistema estaría listo
después de muchas iteraciones por
ejemplo, 10 o 15.
La salida de una iteración no es un
prototipo experimental o desechable, y el
desarrollo iterativo no es prototipado.
Más bien, la salida es un subconjunto con
calidad de producción del sistema final.
Los desarrolladores basan la selección de
lo que será desarrollado en cada iteración
tomando en cuenta dos factores:
Primero: La iteración trata con un
grupo de casos de uso que juntos amplían
la utilidad del producto, según lo
desarrollado hasta ahora.
Segundo: La iteración se ocupa de los
riesgos más importantes.
Beneficios del desarrollo
iterativo
Mitigación tan pronto como sea posible de los
riesgos altos (técnicos, requisitos, objetivos,
usabilidad y demás).
Progreso visible en las primeras etapas.
Una temprana retroalimentación, compromiso de los
usuarios y adaptación que nos lleva a un sistema
refinado que se ajusta más a las necesidades reales
del personal involucrado.
Gestión de la complejidad, el equipo no se ve
abrumado por la “parálisis del análisis” o pasos muy
largos y complejos.
El conocimiento adquirido en una iteración se puede
utilizar metódicamente para mejorar el propio
proceso de desarrollo, iteración tras iteración.
EN RESUMEN
Los conceptos:
dirigido por casos de uso,

centrado en la arquitectura y
el desarrollo iterativo e incremental,
son igualmente importantes. La arquitectura

proporciona la estructura en la cual se guía el
trabajo en las iteraciones, mientras que los
casos de uso definen las metas y conducen el
trabajo de cada iteración. El quitar una de estas
tres ideas reduciría severamente el valor del
proceso unificado.
Las Fases del PU
Un proyecto con el PU organiza el trabajo y las
iteraciones en 4 fases fundamentales:
Inicio: visión aproximada, análisis del negocio,
estimaciones imprecisas de plazos y costos. Se
define la viabilidad del proyecto.
Elaboración: visión refinada, implementación
iterativa del núcleo central de la arquitectura,
resolución de los riesgos altos, identificación de
más requisitos y alcance, estimaciones más
realistas.
Construcción: implementación iterativa del resto de
requisitos de menor riesgo y elementos más
fáciles, preparación para el despliegue.
Las Fases del PU
Transición: pruebas beta, despliegue.
La fase de inicio NO es una fase de requisitos; sino

una especie de fase de viabilidad, donde se lleva a
cabo solo el estudio suficiente para decidir si
continuar o no.
La fase de elaboración NO es la fase de requisitos o

de diseño, sino una fase donde se implementa de
manera iterativa, la arquitectura, que constituye el
núcleo central y se mitigan las cuestiones de alto
riesgo.
La vida del PU
Cada fase esta subdividida en iteraciones
Inicio Elaboración Construcción Transición

Iter. Iter. Iter. Iter.
#1 # 2.. #n-1 #n…
versiones
Un ciclo con sus fases y sus iteraciones
The UP Disciplines
Phases
Process Disciplines Inception Elaboration Construction Transition
Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Supporting Disciplines
Configuration Mgmt
Management
Environment
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1
Iterations
Disciplinas del PU (flujos de trabajo)
Informalmente una disciplina es un conjunto de
actividades (y artefactos relacionados) en un
área determinada como las actividades en el
análisis de requisitos.
En el PU, un artefacto es el término general
para cualquier producto del trabajo: código,
gráficos Web, esquema de base de datos,
documento de texto, diagramas, modelos,
etcétera.
Nos centraremos en 3 disciplinas: modelado del
negocio, requisitos y diseño.
Disciplinas del PU (flujos de
trabajo)
Modelado del negocio
Una vez que los miembros del equipo de requisitos se

han familiarizado con el lenguaje, el siguiente paso es:
 construir el modelo del negocio inicial, que es una descripción
de los procesos de una empresa (ejemplo: un banco incluye
aceptar depósitos de los clientes, conceder préstamos a los
clientes y hacer inversiones)
La razón para construir un modelo de negocios es que
proporciones una comprensión de los negocios del
cliente como un todo,
 con este conocimiento es posible aconsejar al cliente respecto
de qué porciones del sistema de información computarizar.
Disciplinas del PU modelado del negocio
Ejemplo: los procesos de negocios de una empresa de

servicios de banquetes incluyen:
comprar los ingredientes,
preparar los alimentos,
servir la comida
El proceso comprar ingredientes refinado
El encargado del servicio de banquetes ordena los ingredientes
a un mayorista
El mayorista entrega los ingredientes al encargado del servicios
de banquetes
 El mayorista envía una factura al encargado de banquetes
El encargado de banquetes paga la factura
Disciplinas del PU modelado del negocio
Pueden usarse una serie de técnicas para

obtener información necesaria para
construir el modelo de negocios,
principalmente la entrevista.
Disciplinas del PU
Requisitos: análisis de requisitos para la aplicación, escritura de
casos de uso e identificación de requisitos no funcionales.
El objetivo de esta disciplina es asegurar que los desarrolladores

construyan el sistema de información correcto,
Esto se logra al describir el sistema de información objetivo de una

manera suficientemente clara y precisa como para que los dos
involucrados principales (cliente y desarrolladores) puedan ponerse
de acuerdo en lo que debe y no debe hacer el sistema de
información.
Con el fin de lograr esto, lo requisitos tienen que ser comprendidos

por el cliente. Una manera de lograrlo es usar el PU, porque sus
diversos modelos ayudan al cliente a obtener la comprensión
detallada necesaria de lo que se va a desarrollar.
Disciplinas del PU
Análisis
El propósito de esta disciplina es examinar y refinar los
requisitos. Al hacerlo se logra la comprensión detallada de
los requisitos que deben tener para desarrollar
correctamente un sistema de información y darle
mantenimiento con facilidad.
¿por qué tener la disciplina de análisis?
El punto clave es que los artefactos de la disciplina de
requisitos deben expresarse en el lenguaje del cliente, es
decir en un idioma natural (español, inglés, armenio,…),
pero todos los lenguajes naturales de alguna manera son
imprecisos y conducen a malas interpretaciones.
Disciplinas del PU Análisis
Ejemplo: se tiene el siguiente requisito
“Un registro de partes y un registro de las planta de fabricación de las

mismas se buscan en una base de datos. Si el registro contiene la
letra A justo después de la Q, entonces se calcula el costo de
transportar esa parte a la planta.”
A primera vista ese requisito parece perfectamente claro. Pero ¿a

qué se refiere el “registro” (registro de partes o registro de plantas).
Con la disciplina de requisitos se formula en el lenguaje del cliente y

la disciplina de análisis es un lenguaje más preciso que asegurará
que las disciplinas de diseño e implementación se llevarán a cabo
correctamente.
Disciplinas del PU
Diseño
En esta disciplina se refina los artefactos del

análisis hasta que el material esté en una forma
en que los programadores puedan implementar.
Además una serie de requisitos necesitan

familiarizarse en este momento, incluyendo la
elección del lenguaje de programación, así
como la reutilización y los problemas de
portabilidad.
Disciplinas del PU
Implementación
El objetivo de esta disciplina es instaurar el

sistema de información deseado en el lenguaje
deseado.
En cuanto el componente se ha codificado, el

programador lo prueba, una vez que el
programador está seguro de que el componente
es correcto, se pasa al grupo de aseguramiento
de la calidad para una prueba posterior.
Disciplinas del PU
Pruebas
Esta disciplina es responsabilidad del grupo de aseguramiento de la

calidad. Cada componente que se ha terminado se prueba, a esto
se le llama prueba de unidad.
Al final de cada iteración se realiza la prueba de integración. Aquí

los componentes que se han completado y a los cuales se les han
aplicado las prueba de unidad, se compilan y se ligan y luego se
prueban con varios casos de prueba.
Cuando el producto parece estar completo, se prueba en conjunto:

a esto se llama prueba de producto.
requerimientos
disciplinas y
Modelo de
casos de uso
modelos en el PU
Análisis
Modelo de
análisis
Diseño
Modelo de Modelo de
diseño distribución
Implementación
Modelo de
implementación
Prueba
Modelo de
pruebas
Buenas prácticas del PU
adicionales
Lo fundamental para apreciar y aplicar el PU es el desarrollo
iterativo (fijando iteraciones cortas) y adaptable.
Uso de tecnologías de objetos (A/DOO Y POO).
Abordar cuestiones de alto riesgo en las primeras iteraciones.
Involucrar continuamente a los usuarios para evaluación,
retroalimentación y requisitos.
Construir en las primeras iteraciones una arquitectura que
constituya un núcleo central consistente.
Verificar la calidad continuamente; pruebas muy pronto, con
frecuencia y realistas.
Aplicar casos de uso.
Modelar software visualmente (UML).
Gestionar los requisitos con cuidado.
Manejar peticiones de cambio y gestión de configuraciones.
Modelo arquitectónico de capas
La tienda FOO _ X
Articulo ID
Interfaz Menor atención
Cantidad
Introducir art. Etc.
Capa de lógica Principal atención

de la aplicación del caso de
Venta Pago estudio
y objetos del
dominio
Capa de servicios Registro FachadadePersistencia

técnicos Atención
secundaria
Un sistema OO se diseña en función de varias capas

arquitectónicas o subsistemas
Descripción de las capas
arquitectónicas
Interfaz de usuario: interfaz gráfica, ventanas.
Lógica de la aplicación y objetos del dominio: objetos
software que representan conceptos del dominio (por
ejemplo una clase software denominada Venta) que
satisfacen los requisitos de la aplicación.
Servicios técnicos: objetos de propósito general y
subsistemas que proporcionan servicios técnicos de
apoyo, como conexión con una base de datos o
registrar los errores. Normalmente estos servicios
son independientes de la aplicación y se pueden
reutilizar entre varios sistemas.
Fase de inicio
El propósito de la fase de inicio es establecer una visión
común inicial de los objetivos del proyecto, determinar si
es viable y decidir si merece la pena llevar a cabo
algunas investigaciones serias en la fase de
elaboración.
El resultado del estudio de viabilidad debe ser un
informe que recomiende si merece o no la pena seguir
con el proceso de desarrollo del sistema. Usualmente se
debe responder a las siguientes preguntas:
1. ¿Contribuye el sistema a los objetivos generales de la
organización?
2. ¿Se puede implementar el sistema utilizando la
tecnología actual y dentro de las restricciones de costo y
tiempo?
3. ¿puede integrarse el sistema con otros sistemas
existentes en la organización?
Fase de inicio
La fase de inicio en una frase
“Vislumbrar el alcance del producto, visión y

análisis del negocio”
El principal problema resuelto en una frase:
“¿Está de acuerdo el personal involucrado en la

visión del proyecto, y merece la pena invertir en
un estudio serio?
Artefactos en la fase de inicio
Artefacto Comentario
Visión y análisis del negocio Describe los objetivos y las restricciones de alto nivel,
el análisis del negocio y proporciona un informe para la
toma de decisiones
Modelo de casos de uso Describe los requisitos funcionales y no funcionales
Especificación complementaria Describe otros requisitos
Glosario Terminología clave del dominio
Lista de riesgos y plan de Describe los riesgos del negocio, técnicos, recursos,
gestión de riesgos planificación y las ideas para mitigarlos o darles
respuesta
Prototipos y pruebas de Para clarificar la visión y validar las ideas técnicas
conceptos
Plan de iteración Describe qué hacer en la primera iteración de la
elaboración
Fase plan y plan de desarrollo Estimación de poca precisión de la duración y esfuerzo
del software de la fase de elaboración
Marco de desarrollo Una descripción de los pasos del UP y los artefactos
adaptados para este proyecto.
Caso de estudio: Sistema Punto de
Venta Nueva Era
Un sistema PDV es una aplicación informática utilizada (en parte) para
registrar ventas y realizar pagos. Incluye componentes hardware,
como una computadora y un lector de códigos de barras y software
para ejecutar el sistema.
Interactúa con varias aplicaciones de servicios, como un servicio de
cálculo de impuestos y un control de inventario, de terceras partes.
Estos sistemas deben ser relativamente tolerantes a fallos, es decir,
si los servicios remotos no están disponibles temporalmente, deben
ser capaces de capturar las ventas y gestionar, al menos, pagos en
efectivo.
Un sistema PDV, progresivamente, debe soportar múltiples y variadas
terminales e interfaces del lado del cliente, como una terminal con
navegador Web de una arquitectura “cliente delgado”, una PC
normal con una GUI hecha con clases swing de Java, entrada de
datos mediante una pantalla táctil, PDAs inalámbricos, etc.
Se desea crear un sistema PDV comercial que se venderá a diferentes
clientes con necesidades diferentes en términos de reglas del
negocio. Por lo que necesitamos un mecanismo para proporcionar
flexibilidad y personalización.
Artefacto: Visión
La Visión sirve para comunicar de
manera concisa:
 las grandes ideas acerca de por qué se
propuso el proyecto,
 cuáles son los problemas,
 quiénes son las personas involucradas,
 qué necesitan, y
 cuál podría ser la apariencia de la solución
propuesta.
Ejemplo Nueva Era: Visión (parcial)
Historia de revisiones
Versión Fecha Descripción Autor
Borrador de inicio 10-01-2031 Primer borrador. Para Craig Larman
refinarse durante la
elaboración
Introducción:
Prevemos una aplicación punto de venta (PDV) tolerante a fallos de próxima
generación, PDV Nueva Era, con flexibilidad para poder soportar variaciones
en las reglas del negocio del cliente, múltiples mecanismos de terminal e
interfaz de usuario y la integración con múltiples sistemas de terceras partes.
Enunciado del Problema:
Los sistemas PDV tradicionales son inflexibles, intolerantes a fallos, y difíciles
de integrar con sistemas de terceras partes. Esto da lugar a problemas en el
oportuno procesamiento de las ventas, en el establecimiento de procesos
mejorados y con los datos de contabilidad e inventario precisos y oportunos
para dar soporte a la planificación y medidas, entre otras cuestiones. Esto
afecta a los cajeros, encargados de almacén, administradores del sistema y a
la gestión empresarial.
Enunciado de la posición en el mercado del producto:
-- Resumen conciso de a quién está dirigido el producto.
Alternativas y competencia:
Descripción del personal involucrado:
Objetivos de alto nivel y problemas claves del personal
involucrado: después de llevar a cabo un taller de requisitos se
identificaron los siguientes objetivos y problemas claves:
Objetivo de alto Prioridad Problemas e inquietudes Soluciones actuales
nivel
Realizar un Alta Se reduce la velocidad cuando se Los productos PDV
procesamiento de aumenta la carga. existentes permiten el
ventas rápido, Pérdida de la capacidad de procesamiento básico
robusto e integrado procesamiento de las ventas si los de ventas pero no
componentes fallan abordan estos
Imposibilidad de adaptar las reglas problemas
de negocio a requisitos únicos.
…….
…. …. …… ….
Objetivos a nivel de usuario:
Los usuarios (y los sistemas externos) necesitan un sistema para
satisfacer sus objetivos:
•Cajero: procesar las ventas, gestionar las devoluciones, abrir y cerrar
caja.
•Administrador del sistema: gestionar los usuarios, gestionar la
seguridad, gestionar las tablas del sistema.
•Sistema de actividad de ventas: analizar los datos de las ventas.
•…..
Perspectiva del producto:
El PDV Nueva Era residirá normalmente en tiendas. Proporcionará
servicios al usuario y colaborará con otros sistemas
<actor>
<actor> <actor>
Sistema de
Serv. de Calculador
actividad de
Invocar autorización de
ventas Invocar
servicios de pagos impuestos
Cajero servicios
PDV
<actor> <actor>
<actor>
Sistema de Sistema de
Sistema de
rec. inventarios
contabilidad
humanos
Administrador Encargado de
del sistema tienda
Resumen de beneficiarios:
Característica soportada Beneficio del personal involucrado
Funcionalmente, el sistema proporcionará Servicios de punto de venta rápidos y
todos los servicios típicos que requiere la automáticos
organización de las ventas…..
Resumen de las características del sistema:

• Entrada de ventas.
• Autorización de pagos (crédito, débito, cheque)
• Procesamiento de venta automático sin conexión cuando fallan los
componentes.
• ….
Otros requisitos y restricciones:
Abarca las restricciones de diseño, fiabilidad, rendimiento, soporte,
empaquetado, etcétera: diríjase a la Especificación Complementaria
y a los casos de uso.
Ejemplo Nueva Era: Especificación
Complementaria (parcial)
elaboración
Introducción:
Este documento es el repositorio de todos los requisitos del PDV Nueva
Era que no se capturan en los casos de uso.
Funcionalidad:
(Funcionalidad común entre muchos casos de uso)
Registro y gestión de errores
Registrar todos los errores en almacenamiento persistente.
Reglas de negocio conectables
En varios puntos de los escenarios de varios casos de uso (pendientes de
ser definidos) soportar la capacidad de adaptar la funcionalidad del
sistema con un conjunto arbitrario de reglas que se ejecutan en ese punto
o evento.
Seguridad
Todo uso requiere la autenticación de los usuarios.
Facilidad de uso
Factores humanos
El cliente será capaz de ver la información en un gran monitor, por tanto:
•Se debe ver el texto fácilmente a una distancia de 1 metro.
•Evitar colores asociados con formas comunes de daltonismo.
El cajero está mirando a menudo al cliente o los artículos, no a la pantalla
de la computadora, por tanto, se deben comunicar las señales y avisos con
sonidos, en lugar de sólo mediante gráficos.
Fiabilidad:
Capacidad de recuperación
Si se produce algún fallo al usar un servicio externo, intentar solucionarlo
con una solución local para no obstante, completar una venta. Se necesita
mucho mas análisis aquí ….
Rendimiento
Los compradores quieren completar el proceso de ventas muy rápido. Un
cuello de botella potencial es la autorización de pagos externa. El objetivo
es conseguir la autorización en menos de 1 minuto el 90% de las veces.
Interfaces
Interfaces y hardware destacable
•Monitor con pantalla táctil.
•Escáner láser de código de barras.
•Impresora de recibos.
•Lector de tarjetas de crédito/débito.
Interfaces software
Para los sistemas de colaboración externos (inventario, contabilidad, …) se
requieren diversas interfaces.
Reglas del dominio (negocio)
ID Regla Grado de variación Fuente
REGLA1 Se requiere la firma de Se solicita la “firma” de los La política de todas
pagos a crédito compradores, en 2 años los las compañías de
clientes solicitarán la firma autorización de
en aparato digital y en 5
crédito
años la nueva firma digital
única soportada por la ley
americana
……. …..
Visión, especificación complementaria, casos de
uso, ¿Qué va primero?
No es útil ser estricto en el orden de algunos artefactos.
Durante la creación de los diferentes artefactos de requisitos
se produce una sinergia en la que el trabajo de uno influye y
ayuda a clarificar otros. Una secuencia recomendada es:
1. Escribir un borrador breve de la Visión.

2. Identificar los objetivos de usuario y los casos de uso.
3. Escribir algunos casos de uso y comenzar con la
Especificación Complementaria.
4. Refinar la Visión, resumiendo la información a partir de
éstos.
Glosario
El GLOSARIO es una lista de los términos relevantes y sus definiciones.
Es sorprendentemente habitual que un término propio del dominio, se
utilice de forma ligeramente distinta por diferentes personas
involucradas; esto tiene que resolverse para reducir los problemas de
comunicación y los requisitos ambiguos.
En el PU, el Glosario juega también el rol de diccionario de datos, un

documento que recoge los datos sobre los datos, es decir, metadatos.
Durante la fase de inicio, el glosario debe ser un documento sencillo de
términos y descripciones.
Durante la fase de elaboración, podría ampliarse a un diccionario de
datos.
Los atributos de los términos podrían contener:
•Alias.
•Descripción.
•Formato (tipo, longitud, unidad)
•Relaciones con otros elementos
•Rango de valores.
•Reglas de validación
Ejemplo Nueva Era: Glosario (parcial)
elaboración
Definiciones
Término Definición e información Alias
Artículo Un artículo o servicio en venta
Autorización de Validación llevada a cabo por un servicio
pago externo de autorización de pago, que hará o
garantizará el pago al vendedor
UPC Código de 12 dígitos que identifica a un Código de producto
artículo. Se representa mediante un código de universal
barras en los artículos
Solicitud de Un compuesto de elementos enviados
autorización de pago electrónicamente a un servicio de autorización
de pagos. Los elementos comprenden: ID de la
tienda, numero de cuenta del cliente, cantidad,
fecha.
Fase inicio Requisitos
Los requisitos son capacidades y condiciones con las que debe

cumplir el sistema y más ampliamente el proyecto.
El primer reto del trabajo de los requisitos es encontrar,
comunicar y registrar lo que se necesita realmente, de manera
que tenga un significado claro para el cliente y los miembros
del equipo de desarrollo.
El PU fomenta un conjunto de buenas prácticas, una de ellas
es la gestión de requisitos.
El PU utiliza un proceso que acepta el cambio y la
retroalimentación como motores centrales en el descubrimiento
de los requisitos, esto se debe a su característica de ser
iterativo e incremental.
Se utiliza la técnica de escritura de casos de uso para
encontrar y describir los requisitos.
Tipos de requisitos
En el PU los requisitos se clasifican de acuerdo con el
modelo FURPS+, un útil nemotécnico que significa los
siguientes tipos de requisitos:
Funcional (Functional): carácteristicas, capacidades y
seguridad.
Facilidad de uso (Usability): factores humanos, ayuda,
documentación.
Fiabilidad (Reliability): frecuencia de fallos, capcidad
de recuperación de un fallo y grado de previsión.
Rendimiento (Performance): tiempos de respuesta,
productividad, precisión, disponibilidad, uso de
recursos.
Soporte (Supportability): adaptabilidad, facilidad de
mantenimiento, internacionalización, configurabilidad.
Tipos de requisitos
El + en FURPS+ indica requisitos adicionales
como:
Implementación: limitación de recursos,
lenguajes y herramientas, hardware…
Interfaz: restricciones impuestas para la
interacción con sistemas externos.
Operaciones: gestión del sistema en su puesta
en marcha.
Empaquetamiento
Legales: licencias, etcétera.
Lo normal es dividir los requisitos en funcionales
(comportamiento) y no funcionales (todo lo
demás).
Modelo de casos de uso
El modelo de casos de uso debe contener
los siguientes elementos:
 Lista Actor-Semántica.
 Lista Actor- Objetivo.
 Lista de Casos de Uso.
 Descripción breve de casos de uso.
 Descripción completa (10 al 20%) de casos
de uso utilizando una plantilla.
 Diagrama de casos de uso.
Modelo de casos de uso: Identificación de
actores principales
Los actores principales en los casos de uso tienen objetivos de usuarios que
se satisfacen mediante el uso de los servicios del sistema.
¿Por qué se identifican? Para encontrar los objetivos de usuario, los cuales
dirigen los casos de uso.
Los actores principales pueden ser otros sistemas informáticos (procesos
software guardianes)
Los actores de apoyo proporcionan servicios al sistema que se está

diseñando.
¿Por qué se identifican? Para clarificar las interfaces externas y los protocolos.
Los actores pasivos están interesados en el comportamiento del caso de uso,

pero no es principal ni de apoyo. Por ejemplo la Secretaría de
Administración Tributaria (SAT).
¿Por qué se identifican? Para asegurar que todos los intereses necesarios se
han identificado y satisfecho.
Lista actor-semántica
Contiene todos los actores y una descripción de ellos.

Lista Actor-Objetivo
Actor Objetivo
Cajero Registrar ventas
Gestionar devoluciones
Abrir caja
Cerrar caja
El resultado de esta actividad es una nueva versión

del modelo de casos de uso con un conjunto
actualizado de actores. La descripción de los
actores se puede usar como punto de inicio para
encontrar los casos de uso.
Los pasos para construir el
Modelo de Casos de Uso
A partir de la lista Actor-Objetivo, obtener una lista de
casos de uso, aquí lo importante es asegurar que todos
los objetivos se satisfagan con los casos de uso listados.
Posteriormente, deberá describir en formato breve todos
los casos de uso listados. El formato breve consiste de
escribir un resumen conciso de un párrafo, normalmente
del escenario principal con éxito.
El siguiente paso es escribir casos de uso completos
usando una plantilla.
¿Cuántos CU debemos escribir en esta fase?
Entre el 10 y 20%
Finalmente se dibuja un diagrama de casos de uso.
¿Qué sucedió en la fase de inicio?
Esta etapa debe durar poco tiempo (por ejemplo una
semana). Los artefactos creados deben ser breves e
incompletos.
No se han cubierto todas las actividades que podrían
ocurrir. En este estudio se resalta los artefactos
orientados a los requisitos. Algunas de las actividades y
artefactos posibles en la fase de inicio comprenden:
 Un breve taller de requisitos
 La mayoría de los actores, objetivos y casos de uso, con
los nombres.
 La mayoría de los casos de uso escritos en formato
breve, del 10 al 20% de los casos de uso se escriben en
detalle en formato completo para mejorar la
comprensión del alcance y complejidad.
 Identificación de la mayoría de los requisitos de calidad
influyentes y de riesgo.
 Lista de riesgo
 Por ejemplo, el director en realidad quiere una demostración en
la feria comercial en Holanda, dentro de 18 meses. Pero el
esfuerzo para el desarrollo de la demo no puede ser estimado ni
a grandes rasgos hasta que se haga un estudio más profundo.
 Prototipos de pruebas de conceptos técnicos y otros
estudios para explorar la viabilidad técnica de los
requisitos especiales.
 Funcionan los Java Swing de manera correcta en pantallas
táctiles?.
 Prototipos orientados a la interfaz de usuario para
clarificar la visión de los requisitos funcionales.
 Recomendaciones sobre qué componentes
comprar/construir/reutilizar, que se refinarán en la elaboración.
 Por ejemplo, una recomendación de compra de un paquete de
cálculo de impuestos.
 Arquitectura de alto nivel candidata y componentes propuestos
 No se trata de una descripción detallada de la arquitectura y no
se pretende que sea final y correcta. Más bien, se refiere a que
sea una breve especulación que se va a utilizar como punto de
partida del estudio en la elaboración. Por ejemplo, “una
aplicación java al lado del cliente, si un servidor de
aplicaciones, Oracle para las bases de datos…”. En la
elaboración podrá probarse que merece la pena o descubrir
que es una mala idea y rechazarla.
 Plan para la primera iteración
 Lista de herramientas candidatas.
Plan para la iteración 1 en el PDV
Nueva Era (requisitos a resolver)
Implementar un escenario básico del caso de
uso del Procesar Venta: entrada de artículos y
recibir el pago en efectivo.
Implementar un caso de uso Poner en Marcha
necesario para dar soporte las necesidades de
inicialización de la iteración.
Nada complejo es manejado, solo un simple
escenario que termina con éxito y el diseño e
implementación que lo soporte.
No se resolverá la colaboración con servicios
externos tales como el calculador de impuestos
o base de datos de artículos.
No se aplicarán reglas complejas para fijar los
precios.
Actividades principales de la fase de inicio
De la fase de inicio a la fase de elaboración
Fase de elaboración
La fase de elaboración en una frase:
Construir la arquitectura base, resolver los

elementos de alto riesgo, definir la
mayoría de los requerimientos y estimar la
planificación y los recursos globales.
En esta fase se inicia una serie de
iteraciones durante las que:
Se descubren y estabilizan la mayoría de

los requisitos.
Se reducen o eliminan los riesgos
importantes.
Se implementan y prueban los elementos
básicos de la arquitectura.
A menudo la fase de elaboración consiste de 2 a 4
iteraciones; cada iteración se recomienda tenga un
tiempo de duración de 2 a 6 semanas.
Debido a que a cada iteración se le asigna tiempo, esto

establece una fecha de terminación fija en la que debe
terminarse dicha iteración.
Si el equipo no cumple con la fecha, lo requerimientos

se colocan atrás en una lista de tareas futuras, de tal
forma que la iteración puede terminar en tiempo con una
versión estable y probada.
Actividades principales de la fase de
elaboración
Artefactos que pueden iniciar en la
fase de elaboración
Modelo del dominio Visualización de los conceptos del dominio; similar al
modelo de información estática de las entidades del
dominio.
Modelo de diseño Conjunto de diagramas que describen el diseño lógico:
diagramas de clase, de interacción de objetos, paquetes,
etc.
Documento de la Un resumen de las ideas de diseño más importantes y su
Arquitectura motivación.
Software
Modelo de Datos Esquemas de la base de datos y sus estrategias de mapeo

entre representaciones objetuales y no objetuales (Ej.
mapeo O/R)
Modelo de prueba Una descripción de lo que se va a probar y como se
probará.
Artefactos que pueden iniciar en la
fase de elaboración
Modelo de implementación Se corresponde con la implementación real (código

fuente, ejecutables, BD)
Guiones de casos de Descripción de la IU, caminos de navegación,

uso modelos de facilidad de uso, etc.
Prototipos de IU
Modelo del dominio

Modelo del dominio
Un modelo del dominio ilustra clases conceptuales
significativas en el dominio del problema, es el artefacto
mas importante creado durante el análisis orientado a
objetos.
Un modelo del dominio es usado como fuente de

inspiración para diseñar objetos de software.
Identificar un rico conjunto de objetos o clases

conceptuales es el alma del AOO, y este esfuerzo es
bien recompensado durante el trabajo de diseño e
implementación.
Modelo del Dominio
Un modelo del dominio es una
representación de clases conceptuales del
mundo real no de componentes de
software.
NO se trata de un conjunto de diagramas
describiendo clases de software u objetos
de software con responsabilidades.
Modelo del dominio y UML
Usando la notación de UML, un modelo del
dominio puede incluir un diagrama de clases,
donde se puede mostrar:
Objetos o clases conceptuales del dominio

Asociaciones entre clases conceptuales
Atributos de clases conceptuales
Aplicando la notación de Diagramas de clases

UML para el Modelo del Dominio nos lleva a un
Modelo de perspectiva conceptual.
Diagramas de Secuencia del
Sistema (DSS)
Para empezar el trabajo de la iteración #1, resultará útil
realizar un estudio adicional del dominio del problema.
Parte de este estudio comprende la identificación de los

eventos de entrada y salida del sistema que se está
desarrollando, que pueden presentarse en diagramas de
secuencia (DSS) UML
Un DSS es un dibujo que muestra, para un escenario

especifico de un caso de uso, los eventos que generan
los actores externos, el orden y la respuesta del sistema
a dichos eventos
Diagramas de Secuencia del
Sistema (DSS)
Sugerencia: Un DSS debe hacerse

para el escenario principal de éxito
del caso de uso (más riesgoso) y
para los escenario alternativos
complejos o frecuentes.
El DSS muestra el comportamiento del sistema
DSS para un escenario de Procesar
como una cajaVenta
negra (describe qué hace el
sistema si explicar cómo lo hace)
:Sistema
:Cajero
crearNuevaVenta()
introducirArt(artID, cantidad)
El *[..] indica
Descripción, total que la caja
es para iterar
* [más artículos]
finalizarVenta() Valor de retorno

asociado con el
mensaje anterior,
Total con impuestos ignora la
presentación y el
medio
realizarPago(cantidad)
Abstracción que
Cambio devuelto, recibo representa
entrada de
datos, mediante
Escenario simple de Procesar ventas en
efectivo. :Cajero :Sistema
1. El cliente llega a la terminal PDV crearNuevaVenta()
2. El cajero inicia una nueva venta
3. El cajero introduce el código del
artículo
Descripción, total
4. El sistema registra la línea de venta y
presenta la descripción y precio del finalizarVenta()
artículo y la suma parcial.
El cajero repite los pasos 3 y 4 hasta Total con impuestos
que se indique
5. El sistema muestra el total con los
impuestos calculados.
Cambio devuelto, recibo
6. El cajero le dice al cliente el total y
pide que le pague.
7. El cliente paga y el sistema gestiona
el pago.
…
Regresando al Diagrama de
Clases del Dominio
Concepto u objeto LineadeVenta Registro-venta-de
Articulo
del dominio cantidad
0..1 1
1..* *
Asociación Contenida-en Almacenado-en
1
1
Venta Tienda
fecha dirección
Atributos hora nombre
1
1 1
Pagada-mediante Alberga
1 1..*
La tarea fundamental en
el análisis orientado a
objetos es realizar la Pago Registro
descomposición de un Capturada-en
dominio en clases cantidad
conceptuales 1
individuales u objetos.
Diagrama de Clases del
Dominio
Los siguientes elementos no son adecuados
en un Diagrama de Clases del Dominio:
Artefactos de software, tales como una
ventana o una base de datos, a menos
que el dominio que esté siendo modelado
sea de conceptos de software tales como
un modelo de interfaz gráfica de usuario.
Responsabilidades o métodos.
Identificación de clases
conceptuales
En un desarrollo iterativo, incrementalmente se
construye un modelo del dominio sobre varias
iteraciones en la fase de elaboración.
En cada iteración, el modelo del dominio está

limitado al escenario actual y anterior bajo
consideración.
conceptuales
Por lo tanto la tarea central es identificar la
clases conceptuales relacionadas al
escenario que se esté resolviendo.
Es común que nos falten clases
conceptuales durante el paso inicial de
identificación y descubrirlas más tarde
durante la consideración de atributos o
asociaciones, o durante el trabajo de
diseño. Cuando se encuentren, pueden
ser agregadas al modelo del dominio.
conceptuales
GUÍA: es mejor especificar en exceso un
diagrama de clases del dominio con
muchas clases conceptuales de grano
fino que especificar por defecto.
Estrategias para identificar clases
conceptuales:
1. Análisis lingüístico.
2. Usar una lista de categorías de clases
conceptuales.
Identificación de clases usando
análisis lingüístico
Esta estrategia consiste en identificar los nombres
y las frases nominales en las descripciones
textuales de un dominio y considerarlos como
clases conceptuales o atributos candidatos.
Un punto débil en este enfoque es la imprecisión
del lenguaje natural; frases nominales diferentes
podrían representar la misma clase conceptual
o atributo.
Se recomienda que se combine con la técnica de
Lista de Categorías de Clases Conceptuales.
Identificación de clases usando
análisis lingüístico
El modelo del dominio es una visualización de los
conceptos del domino y vocabulario relevantes.
Por lo tanto, los casos de uso constituyen una

fuente rica a explorar mediante la identificación
de frases nominales.
Por ejemplo: utilizaremos el escenario principal de

éxito del caso de uso Procesar Venta.
Identifique las clases usando la
técnica de análisis lingüístico
Escenario principal de éxito
1. El cliente llega a una terminal PDV con mercancías
y/o servicios.
2. El cajero comienza una nueva venta.
3. El cajero introduce el identificador del artículo.
4. El sistema registra la línea de venta y presenta la
descripción del artículo, precio y suma parcial.
El cajero repite los pasos 3-4 hasta que se indique.
5. El sistema presenta el total con los impuestos
calculados.
conceptuales
Escenario principal de éxito
1. El cliente llega a una terminal PDV con mercancías
y/o servicios.
2. El cajero comienza una nueva venta.
3. El cajero introduce el identificador del artículo.
4. El sistema registra la línea de venta y presenta la
descripción del artículo, precio y suma parcial.
El cajero repite los pasos 3-4 hasta que se indique.
5. El sistema presenta el total con los impuestos
calculados.
identificación de clases usando
una lista de categorías
Se inicia la creación de un modelo del
dominio haciendo una lista de clases
conceptuales candidatas.
La siguiente tabla contiene categorías que
normalmente merece la pena tener en
cuenta, aunque no en ningún orden
particular de importancia.
El dominio son tiendas y reservaciones de
vuelos.
Categorías de clases conceptuales
Categoría Ejemplos
Objetos tangibles o físicos Registro (TPV), avión
Especificaciones, diseños o EspecificaionDelProducto,
descripciones de las cosas DescripcionDelVuelo
Lugares Tienda
Transacciones Venta, Pago, Reserva
Líneas de la transacción LineaDeVenta
Roles de la gente Cajero, Piloto
Contenedores de otras cosas Tienda, Lata, Aviion
Cosas en un contenedor Articulo, Pasajero
Otros sistemas informáticos o SistemaAutorizacionPagoCredito,
electromecánicos externos al sistema ControlTraficoAereo
Conceptos abstractos Ansia, Acrofobia
Organizaciones DeptoDeVentas, CompañiaAerea
hechos Venta, Pago, Reunion, Vuelo, Aterrizaje
Clases conceptuales candidatas
A partir del análisis de la Lista de
Categorías de Clases Conceptuales y las
frases nominales, se genera una lista de
clases conceptuales candidatas del
dominio.
La lista debe estar restringida a los
requisitos y simplificaciones que se están
estudiando actualmente. En este caso el
escenario simplificado de Procesar Venta
Clases conceptuales candidatas
Registro EspecificaciónDelPro
Artículo ducto
Tienda LineaDeVenta
Venta Cajero
Pago Cliente
CatálogoDeProductos Encargado
Cómo hacer un diagrama de clases
del dominio
Acotado por los requisitos de la iteración
actual:
 Listar las clases conceptuales
candidatas utilizando las técnicas vistas
anteriormente, representarlas en un
modelo del dominio.
 Añadir las asociaciones necesarias para
registrar las relaciones.
 Añadir los atributos necesarios para
satisfacer los requisitos de información.
Espíritu del cartógrafo
Hacer un modelo del dominio con el espíritu
del modo de trabajo del cartógrafo:
Utilice los nombres existentes en el
territorio (dominio).
Excluya las características irrelevantes.
No añada cosas que no están ahí.
Modelo del dominio del PDV
inicial
Registro Artículo Tienda
Venta LineaDeVenta Cajero
Cliente Encargado
Pago
CatalogoDeProductos EspecificacionDeProducto
Artefactos UP y evolución temporal
Disciplina Artefacto Inic. Elab Const Trans
I1 E1..En C1..Cn T1..T2
Modelado del Modelo del Dominio c
negocio
Requisitos Modelo de casos de c r
uso
Visión c r
Especificación c r
complementaria
Glosario c r
Diseño Modelo de diseño c r
Doc. de arq. de soft. c
Modelo de datos c r
Implementación Modelo de Implem. c r r
Artefactos UP y evolución temporal
Gestión de Plan de desarrollo c r r r

proy de software
Pruebas Modelo de c r r
pruebas
Entorno Marco de c r
desarrollo
Influencia entre los artefactos
Asociaciones
Las asociaciones denotan alguna dependencia
semántica entre clases, son el tipo de relación más
general, pero el de mayor debilidad semántica1.
La identificación de asociaciones entre clases es un

actividad de análisis y diseño inicial, momento en el cual
se comienza a descubrir las dependencias generales
entre las clases.
A medida que se continúe el diseño y la implementación

estas asociaciones débiles se refinarán hacia una
relación de clase más concreta (agregación, herencia).
1 El tiempo de vida de un objeto no depende del otro.
Criterios para asociaciones útiles
Las asociaciones que merece la pena registrar son
aquellas que implican conocimiento de una relación que
es necesario conservar durante algún tiempo
(milisegundos o años, depende del contexto).
Por ejemplo ¿es necesario recordar qué instancias de

LineaDeVenta están asociadas con una instancia de
venta?
Sin ninguna duda, de otra forma no sería posible

reconstruir una venta, imprimir un recibo o calcular el
total de la venta.
Criterios para asociaciones útiles
En un modelo del domino con n clases
diferentes, pueden existir n(n-1)
asociaciones entre las clases.
Muchas líneas en un diagrama añadirán

“ruido visual” y lo hará menos
comprensible, por lo tanto debemos ser
cuidadosos al añadir líneas de asociacion.
Lista de Asociaciones Comunes
Categoría Ejemplos
A es una parte física de B Cajon-Registro (TPDV), Ala-
Avion
A es una parte lógica de B LineaDeVenta-Venta,
EtapaVuelo-RutaVuelo
A está contenido físicamente Registro-Tienda, Art-Estante
en B Pasajero-Avion
A está contenido lógicamente DescDelArt-Catalogo, Vuelo-
en B PlanificacionVuelo
A es una descripción de B DescDelArt-Articulo,
DescDelVuelo-Vuelo
A es una línea de una LineaDeVenta-venta
transacción o informe de B
Categoría Ejemplos
A se conoce/registra/recoge/ Venta-Registro, Reserva-
informa/captura en B ListaPasajeros
A es miembro de B Cajero-Tienda, Piloto-
CompañíaAerea
A es una sub-unidad Depto-Tienda,
organizativa de B Mantenimiento-CiaAerea
A utiliza o gestiona B Cajero-Registro, Piloto-Avion
A se comunica con B Cliente-Cajero,
AgenteDeReservas-Pasajero
A está relacionado con una Cliente-Pago, Pasajero-
transacción B Billete
Categoría Ejemplos
A es una transacción Pago-Venta, Reserva-

relacionada con otra Cancelacion
transacción B
A es propiedad de B Registro-Tienda, Avion-
CompañiaAerea
A es un evento relacionado Venta-Cliente, Venta-Tienda
con B Salida-Vuelo
Asociaciones de prioridad Alta
Categorías de asociaciones que son útiles
incluirlas en un modelo del dominio:
A es una parte física o lógica de B

A está contenida física o lógicamente en B
A se registra en B.
Asociaciones
El extremo final de una asociación es
llamado rol. Los roles pueden tener los
siguientes adornos.
Nombre
Expresión de multiplicidad
Navegabilidad
Asociaciones Multiplicidad
El valor de la multiplicidad indica cuántas
instancias se pueden asociar legalmente con
otra, en un momento concreto, en lugar de a lo
largo de un periodo de tiempo.
Almacena
Tienda Articulos
1 *
Si se implementa esta relación en el
software, queremos asegurar que una
instancia de Articulo siempre se
Multiplicidad
relacione con delconcreta
una instancia rol de
Tienda, de otra forma, indica un error o
corrupción en los elementos software o
datos.
Asociaciones Multiplicidad
El valor de la multiplicidad depende de
nuestros intereses como modeladores y
desarrolladores de software, porque pone
de manifiesto una restricción de diseño
que será reflejada en el software.
Ofrecido
Automovil LoteAutos
¿Qué multiplicidad debemos ponerle a la relación?

Depende lo queremos reflejar: lotes que los han ofrecido o lote que lo ofrece
Multiplicidad
* T cero o mas;
“many”
1..*
T Una o mas
1..40
T Una a cuarenta
5
T Exactamente 5
3, 5, 8 Exactamente 3, 5 o 8
T
Asociaciones Nombre
Asigne el nombre una asociación en base al siguiente
formato:
NombreTipo-FraseVerbal-NombreTipo
Donde la frase verbal crea una secuencia que es

legible y tiene significado en el contexto del modelo.
Los nombres de las asociaciones deben comenzar con una

letra mayúscula.
La frase verbal debe ser construida usando guiones.

Asociaciones Nombre
Tienda La lectura de las
asociaciones por defecto
1
Contiene se realizan de izquierda a
1..* derecha o de arriba hacia
abajo.
Registro
1
Captura
1..*
Pagada-mediante
Venta Pago
1 1
Asociaciones e Implementación
Durante el Modelado del Dominio, una
asociación NO es una declaración sobre el flujo
de datos, variables de instancia o conexiones
entre objetos en una solución software.
Una asociación es una manifestación de que

una relación es significativa en un sentido
puramente conceptual (en el mundo real), por lo
que su presencia en una vista conceptual de un
Modelo del Dominio no requiere pensar sobre
su implementación.
Asociaciones e Implementación
Muchas de estas relaciones se implementarán
generalmente en software como caminos de navegación y
visibilidad (tanto en el Modelo de Diseño como en el
Modelo de Datos).
En este momento es conveniente pensar en ellas

como expresiones puramente conceptuales, no
declaraciones sobre la solución de base de datos o
software.
Al posponer las consideraciones de diseño se nos libera

de informaciones y decisiones extrañas mientras
hacemos un estudio de análisis puro y maximiza nuestras
opciones de diseño más adelante.
Modelo del Dominio parcial del punto de venta
Registra-venta-de- -
Identifique que asociación sirve :
Especificacion
LibroMayor CatalogoDe delproducto • para recuperar una
Productos Contiene especificación de producto a
1 1..* partir de un ID del artículo.
1 1
1
Registra
0..1 Usado-por 1 • para recuperar el detalle de la
Describe
Lineaventa * venta
Tienda *
Almacena Articulo • para conocer la venta actual,
1 1
* 1 ..* generar el total, imprimir recibo.
1..*
Contenido-en 1
Registra-completas Alberga
1 1
Venta * Registro
Capturada-en Asociaciones necesito - conocer
1 1
Son aquellas asociaciones para las que
el conocimiento de la relación necesita
Pagada-mediante 1 1 Iniciado-por 1
3 Registra-ventas-en
- conservarse durante algún tiempo.
1 1 1
Pago Cliente Cajero

Asociaciones sólo - comprensión
Son aquellas asociaciones que se usan
para enriquecer el conocimiento básico
del dominio
Atributos
Un atributo es una característica inherente o
distintiva, un rasgo o cualidad que contribuye a
hacer que un objeto sea ese objeto y no otro.
En un modelo de dominio se deben incluir los

siguientes atributos:
Aquellos para los que los requisitos sugieren o

implican una necesidad de registrar la
información.
Atributos
Ejemplo: un recibo que contiene la información de una
venta normalmente incluye una fecha y una hora, por lo
que la clase conceptual Venta necesita los atributos fecha
y hora.
Los atributos en un modelo de dominio
deben de ser, preferentemente atributos
Venta simples1.
fecha •Los tipos de datos muy comunes incluyen:
horaInicio
Boolean, Fecha, Numero, String (texto), Hora
•Otros tipos comunes incluyen:
Dirección, Color, No. de teléfono, No. De la

seguridad social, Código de Precio Universal
(UPC), códigos postales, tipos enumerados.
1 Se conocen como datos primitivos.
Atributos
El tipo de un atributo, normalmente no debería ser un
concepto de dominio complejo, como Venta o Aeropuerto.
Ejemplo: No es atributo “simple”
P Cajero
e
o
El atributo registroActual en la clase Cajero no es
nombre
r
registroActual
deseable porque su tipo tiene la intención de ser un
Registro, que no es un tipo de atributo simple (número o
string).
M
e Cajero Registro
1 Utiliza 1
j
nombre numero
o
r
Atributos
Otro ejemplo:
No es atributo “simple”
P Vuelo
e
o destino Un aeropuerto de destino no es realmente
r
una cadena de texto.
M
e Vuelo Aeropuerto
1 Vuela-a 1
j
o
r
La restricción de que el tipo de los atributos en el modelo del dominio sea

un tipo de dato simple no implica que los atributos C++ o Java sólo deban
ser tipos de datos primitivos o simples.
Durante el trabajo de diseño e implementación, se verá que las

asociaciones entre objetos representadas en el modelo del dominio,a
menudo, se implementarán como atributos que referencian a otros objetos
software complejos.
Atributos
Guía para identificar si un atributo aparentemente simple
debe representarse como una clase no primitiva.
Está compuesto de secciones separadas.
 Número de teléfono, nombre de persona
Habitualmente, hay operaciones asociadas con él, como
análisis sintáctico o validación.
 Número de la seguridad social.
Tiene otros atributos
 El precio de promoción podría tener una fecha de inicio y
terminación.
Usa una cantidad con una unidad
 La cantidad del pago tiene una unidad monetaria.
Atributos
Es una abstracción de uno o más tipos con alguna de estas
cualidades:
 El identificador del artículo en el dominio de ventas es una
generalización de tipos como el Código de Producto
Universal(UPC) o el Número de Artículo Europeo (EAN).
Aplicando esta guía a los atributos del modelo del dominio del punto de
venta se obtiene:
El atributo dirección debe ser una clase no primitiva Dirección por tener
secciones diferentes.
El atributo precio debe ser clase no primitiva si se utiliza diferentes
unidad monetaria.
El atributo idarticulo debe ser clase no primitiva si usa los esquemas
(UPC, EAN) que permite identificar fabricante, producto, pais y
dígito de control.
Contratos
Los casos de uso son el principal mecanismo del
Proceso Unificado para describir el
comportamiento del sistema y, normalmente es
suficiente. Sin embargo en algunas ocasiones
se necesita una descripción más detallada del
comportamiento del sistema.
Los contratos describen el comportamiento

detallado del sistema en función de los cambios
de estado de los objetos del Modelo de
Dominio, después de la ejecución de una
operación del sistema.
Operaciones e interfaz del Sistema
Se pueden definir contratos para las
operaciones del sistema.
El sistema, como una caja negra, ofrece
operaciones en su interfaz pública para manejar
los eventos del sistema entrantes.
Las operaciones del sistema se pueden
identificar descubriendo estos eventos del
sistema, como se muestra en la siguiente figura.
Operaciones e interfaz del Sistema
:Sistema
:Cajero
crearNuevaVenta()
Estos eventos de entrada
del sistema invocan
Descripción, total operaciones del sistema.
* [más artículos] El evento del sistema

CrearNuevaVenta() invoca
finalizarVenta() una operación del sistema
denominada
crearNuevaVenta y así
Total con impuestos sucesivamente.
Esto es lo mismo que

cuando en POO decimos
que el mensaje Inserta,
invoca al método Inserta.
Cambio devuelto, recibo
Operaciones e interface del
Sistema
• En UML, el sistema como un todo se puede representar
mediante una clase.
Sistema
CrearNuevaVenta()
finalizarVenta()
• Los contratos son escritos para cada operación del sistema

para describir su comportamiento.
Secciones del contrato
Contrato C#: Nombre de la operación
Operación: nombre de la operación y parámetro.
Referencias cruzadas: (opcional) casos de uso en
los que pueden tener lugar esta operación.
Precondiciones: suposiciones relevantes sobre el
estado del sistema o de los objetos del Modelo del
Dominio, antes de la ejecución de la operación. No
se comprobará en la lógica de esta operación, se
asume que son verdad, y son suposiciones no
triviales que el lector debe saber que se hicieron.
Postcondiciones: el estado de los objetos del
Modelo del Dominio después de que se complete la
operación.
Ejemplo de contrato
Contrato C01: crearNuevaVenta
Operación: crearNuevaVenta()
Referencia cruzada: caso de uso: Procesar Venta
Precondiciones: ninguna
Postcondiciones: - Se creó una instancia de
Venta v (creación de instancias)
- v se asoció con el Registro
(formación de asociaciones)
- Se inicializaron los atributos de v
Ejemplo de contrato
Contrato C02: introducirArticulo
Operación: introducirArticulo(articuloID:ArticuloID, cantidad:integer)
Precondiciones: Hay una venta en curso
Postcondiciones: - Se creó una instancia de LineaDeVenta ldv
(creación de instancias)
- ldv se asocia con la Venta actual (formación
de asociaciones)
- ldv.cantidad pasó a ser cantidad
(modificación de atributos)
- ldv se asoció con una
EspecificacionDelProducto, en base a la coincidencia del
articuloId (formación de asociaciones)
Ejemplo de contrato
Contrato C03: finalizarVenta
Operación: finalizarVenta()
Precondiciones: Hay una venta en curso
Postcondiciones: - Venta.esCompletada pasó a
ser verdad (modificación de atributos)
Contratos
La postcondición describe cambios en el estado de los objetos del
Modelo del Dominio.
Dichos cambios comprenden:

creación y eliminación de instancias
formación y rotura de asociaciones
modificación de los atributos
Como ejemplo de postcondiciones que rompe una asociación,

considere una operación que permite la eliminación de lineas de
venta. La postcondición podría decir:
“se rompió la asociación seleccionada de la LineaDeVenta con la
Venta”.
Contratos
Las postcondiciones no son acciones que
se ejecutarán durante la operación; más
bien, son declaraciones sobre los objetos
del Modelo del Dominio que son verdad
cuando la operación ha terminado –
después de que el humos se haya
despejado-
Contratos el espíritu de las postcondiciones: el escenario y telón
Exprese las postcondiciones en pasado, para resaltar que son

declaraciones sobre un cambio de estado en el pasado.
(peor) Cree una LineaDeVenta

(mejor) se creó una instancia de LineaDeVenta.
Piense en las postcondiciones utilizando la siguiente imagen:

El sistema y sus objetos se presentan en el escenario de un teatro.
1. Antes de la operación, tome una fotografía del escenario.

2. Baje el telón y aplique las operaciones del sistema (ruido de
martillos o campanas, gritos,…)
3. Suba el telón y tome una segunda fotografía.
4. Compare las fotografías anterior y posterior, y exprese como
postcondiciones el cambio en el estado del escenario.
Contratos expresados con OCL
Existe un lenguaje formal asociado con UML, denominado Lenguaje
de Restricciones de Objetos (OCL, Object Constraint Languague),
que se puede utilizar para expresar las restricciones en los
modelos.
OCL se podría utilizarse en lugar del lenguaje natural informal que se

ha utilizado en los ejemplos de contratos que hemos hecho.
OCL define un formato oficial para la especificación de las pre y

postcondiciones de las operaciones como se muestra en el
siguiente fragmento.
Sistema::creaNuevaVenta()
pre: <sentencias en OCL>
post_ …
Contratos expresados con OCL
SUGERENCIA: A menos que exista una

razón práctica apremiante que requiera
que la gente aprenda y utilice OCL,
mantenga las cosas simples y utilice el
lenguaje natural.

Curso Proyin F Inicio y Analisis

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Curso Proyin F Inicio y Analisis

Încărcat de

Drepturi de autor:

Formate disponibile

Instituto Tecnológico de Culiacán

• El establecimiento y uso de principios de ingeniería

• La ingeniería de software es la aplicación de un enfoque

Vivimos en un mundo de objetos. Estos objetos existen en

El término orientado a objetos significa que el software se

El atractivo intuitivo de la orientación a objetos es que

Análisis Orientado a Objetos.

Pone énfasis en una solución conceptual que satisface los requisitos,

Una habilidad crítica en el desarrollo OO es la asignación inteligente de

public class Plane

El análisis y diseño se han resumido en las freses:

Proporcione una guía para el orden de las

los casos de uso conducen el proceso

4 semanas (por ejemplo)

Se fija la duración de El sistema crece

dirigido por casos de uso,

son igualmente importantes. La arquitectura

La fase de inicio NO es una fase de requisitos; sino

La fase de elaboración NO es la fase de requisitos o

Inicio Elaboración Construcción Transición

Una vez que los miembros del equipo de requisitos se

Ejemplo: los procesos de negocios de una empresa de

Pueden usarse una serie de técnicas para

El objetivo de esta disciplina es asegurar que los desarrolladores

Esto se logra al describir el sistema de información objetivo de una

Con el fin de lograr esto, lo requisitos tienen que ser comprendidos

Ejemplo: se tiene el siguiente requisito

“Un registro de partes y un registro de las planta de fabricación de las

A primera vista ese requisito parece perfectamente claro. Pero ¿a

Con la disciplina de requisitos se formula en el lenguaje del cliente y

En esta disciplina se refina los artefactos del

Además una serie de requisitos necesitan

El objetivo de esta disciplina es instaurar el

En cuanto el componente se ha codificado, el

Esta disciplina es responsabilidad del grupo de aseguramiento de la

Al final de cada iteración se realiza la prueba de integración. Aquí

Cuando el producto parece estar completo, se prueba en conjunto:

Capa de lógica Principal atención

Capa de servicios Registro FachadadePersistencia

Un sistema OO se diseña en función de varias capas

“Vislumbrar el alcance del producto, visión y

El principal problema resuelto en una frase:

“¿Está de acuerdo el personal involucrado en la

Resumen de las características del sistema:

1. Escribir un borrador breve de la Visión.

En el PU, el Glosario juega también el rol de diccionario de datos, un

Los requisitos son capacidades y condiciones con las que debe

Los actores de apoyo proporcionan servicios al sistema que se está

Los actores pasivos están interesados en el comportamiento del caso de uso,

Contiene todos los actores y una descripción de ellos.

El resultado de esta actividad es una nueva versión

Construir la arquitectura base, resolver los

Se descubren y estabilizan la mayoría de

Debido a que a cada iteración se le asigna tiempo, esto

Si el equipo no cumple con la fecha, lo requerimientos

Modelo de Datos Esquemas de la base de datos y sus estrategias de mapeo

Modelo de implementación Se corresponde con la implementación real (código

Guiones de casos de Descripción de la IU, caminos de navegación,

Modelo del dominio

Un modelo del dominio es usado como fuente de

Identificar un rico conjunto de objetos o clases

Objetos o clases conceptuales del dominio

Aplicando la notación de Diagramas de clases