Instituto Tecnolgico de Culiacn

Proyecto Integrador de
Ingeniera de Software
 Introduccin
Qu es Ingeniera de Software ?

El establecimiento y uso de principios de ingeniera

robustos, orientados a obtener software econmico que
sea fiable y funcione de manera eficiente sobre mquinas
reales. (Fritz Bauer 1969)

La ingeniera de software es la aplicacin de un enfoque

sistemtico, disciplinado y cuantificable al desarrollo,
operacin y mantenimiento del software.[IEEE93]
 Introduccin
Orientacin 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 visin orientada a objetos para la creacin de
software de computadora, una abstraccin que modela el
mundo de forma tal que nos ayuda a entenderlo y
gobernarlo mejor.
 Introduccin
Orientacin a Objetos

El trmino orientado a objetos significa que el software se

organiza como una coleccin de objetos que contienen tanto
estructuras de datos como comportamiento.
Introduccin
OBJETOS BICICLETA

Bicicleta

Tam.del cuadro
Se hace una
Tam. De la rueda
abstraccin que
marchas
resulta en
material

Cambiar marcha()
mover()
reparar()
 Introduccin
Orientacin a Objetos

El atractivo intuitivo de la orientacin 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 tecnologas que permiten que los problemas del mundo
real sean expresados de modo fcil y natural.
Introduccin
Programar es divertido,
Pero desarrollar software de calidad es difcil.
Entre las ideas esplndidas, los requisitos y un producto software
funcionando, hay mucho ms que slo programar:
Debemos realizar los planos (anlisis y diseo) que definen cmo
solucionar el problema para obtener un producto software.
Definir el modelo arquitectnico
Aplicar la ingeniera de usabilidad.
Disear la Base de Datos
Etctera.
Introduccin Anlisis

Qu es el anlisis?
Es el estudio de un dominio que da como resultado los
modelos que describen sus caractersticas estticas y
dinmicas. Se centra en las cuestiones del que en lugar
del como. ESPACIO DEL PROBLEMA
Pone nfasis en una investigacin del problema y los
requisitos, en vez de ponerlos en una solucin.
Anlisis es un trmino amplio, es ms adecuado calificarlo
como anlisis de requisitos (un estudio de los requisitos) o
anlisis de objetos (estudios de objetos del dominio)
Qu es el anlisis orientado a objetos?
Es un mtodo de anlisis que examina los requisitos desde la
perspectiva de las clases y objetos que se encuentran en el
vocabulario del dominio del problema (Booch 1994)
Introduccin Anlisis

Anlisis Orientado a Objetos.

Se presta especial atencin 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,
Introduccin Diseo

Diseo:

Pone nfasis en una solucin conceptual que satisface los requisitos,

en vez de ponerlo en la implementacin.
Diseo orientado a objetos
Se presta especial atencin a la definicin de los objetos software y
en cmo colaboran para satisfacer los requisitos. Ejemplos:

ESPACIO DE LA SOLUCIN
Objeto LIBRO Titulo Atributo

GetCap(int c) Operacin

Una habilidad crtica en el desarrollo OO es la asignacin inteligente de

responsabilidades a los objetos software
Introduccin Anlisis y Diseo
Introduccin Anlisis y Diseo

El anlisis y diseo se han resumido en las freses:

Hacer lo correcto
(anlisis)
Hacerlo correcto
(diseo)
 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
Software
Requerimientos Sistema Software
del usuario
 Proceso de desarrollo de software:
Motivacin
Hoy en da la tendencia del software es hacia sistemas
ms grandes y complejos. Esta tendencia tambin ha
sido influenciada por el extensivo uso del internet para
intercambiar todo tipo de informacin. Queremos
software que est mejor adaptado a nuestra
necesidades, aunque ste sea cada vez ms complejo.
En resumen queremos cada vez ms.
Tambin lo queremos ms rpido, el tiempo para
construirlo es otro factor importante. Nuestra demanda
de software complejo y poderoso no concuerda con el
cmo ser desarrollado dicho software. Hoy en da, la
gente desarrolla software usando mtodos que fueron
usados desde hace 35 aos.
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 mtodo comn, un proceso que:

Proporcione una gua 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
ingls 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 construccin de
sistemas orientados a objetos.
El marco del Proceso Unificado
El UP utiliza el lenguaje unificado para la
creacin 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 automtico.
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 interaccin de este tipo es un caso de
uso.
El PU conducido por casos de 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.
El PU conducido por casos de uso
Los casos de uso no solo son una herramienta
para especificar los requerimientos de un
sistema; tambin conducen su :
Diseo,
Implementacin 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 construccin 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 estticos y dinmicos del sistema.
 El PU centrado en la arquitectura
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 distribucin
sistemas heredados y requerimientos no funcionales
Requerimientos no funcionales: en la ingeniera de software es
un requerimiento que especifica criterios que pueden usarse
para juzgar la operacin de un sistema en lugar de sus
comportamientos especficos, 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 cunto tiempo debera el sistema
actualizar su verificacin interna de cantidad de datos es, en
cambio, un requerimiento no funcional.
 El PU centrado en la arquitectura
Cmo se relacionan los casos de uso y la
arquitectura?
Cada producto tiene funcin y forma. Uno o
el otro no es suficiente. Estas dos fuerzas
deben estar balanceadas par obtener un
producto exitoso. En este caso la funcin
corresponde a los casos de uso y la forma a
la arquitectura. Se necesita, por lo tanto, la
interaccin entre los casos de uso y la
arquitectura.
El PU centrado en la arquitectura
El arquitecto moldea el sistema en una forma.
Esa forma, la arquitectura, debe ser diseada de
manera tal, que permita al sistema evolucionar,
no solamente a travs de su desarrollo inicial,
sino a travs 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 duracin
fija (por ejemplo, cuatro semanas) llamados
iteraciones.
El resultado de cada uno es un sistema que
puede ser probado, integrado y ejecutado.
Cada iteracin incluye sus propias actividades
de anlisis de requisitos, diseo implementacin
y pruebas.
El PU es iterativo e incremental
El ciclo de vida iterativo se basa en la ampliacin y
refinamiento sucesivos del sistema mediante mltiples
iteraciones, con retroalimentacin cclica y adaptacin como
elementos principales que nos conducen hacia un sistema
adecuado.
El sistema crece incrementalmente a lo largo del tiempo,
iteracin tras iteracin, por eso se dice que es iterativo e
incremental.
Proceso Iterativo Incremental: se dice que un proceso es
iterativo incremental cuando en cada iteracin de sus pasos
se alcanza una mayor cercana con los objetivos finales.
Esto es, se aade algo nuevo de valor en cada iteracin.
 La retroalimen-
tacin de la ite-
Requisitos racin N nos lle
Requisitos
va a refinar y
Diseo
Diseo adaptar los re-
Implementacin & quisitos y diseo
TIEMPO de la iteracin N+1.
Implementacin & Prueba & Integra-
Prueba & Integra- cin & ms diseo
cin & ms diseo
Integracin final &
Integracin final & Pruebas de sistema
Pruebas de sistema

4 semanas (por ejemplo)

Se fija la duracin de El sistema crece

Las iteraciones de manera incremental
El PU es iterativo e incremental
El resultado de cada iteracin es un
sistema ejecutable, pero incompleto; no
est preparado par ser puesto en
produccin. El sistema estara listo
despus de muchas iteraciones por
ejemplo, 10 o 15.
El PU es iterativo e incremental
La salida de una iteracin no es un
prototipo experimental o desechable, y el
desarrollo iterativo no es prototipado.
Ms bien, la salida es un subconjunto con
calidad de produccin del sistema final.
El PU es iterativo e incremental
Los desarrolladores basan la seleccin de
lo que ser desarrollado en cada iteracin
tomando en cuenta dos factores:
Primero: La iteracin trata con un
grupo de casos de uso que juntos amplan
la utilidad del producto, segn lo
desarrollado hasta ahora.
Segundo: La iteracin se ocupa de los
riesgos ms importantes.
Beneficios del desarrollo iterativo
Mitigacin tan pronto como sea posible de los riesgos
altos (tcnicos, requisitos, objetivos, usabilidad y
dems).
Progreso visible en las primeras etapas.
Una temprana retroalimentacin, compromiso de los
usuarios y adaptacin que nos lleva a un sistema
refinado que se ajusta ms a las necesidades reales
del personal involucrado.
Gestin de la complejidad, el equipo no se ve
abrumado por la parlisis del anlisis o pasos muy
largos y complejos.
El conocimiento adquirido en una iteracin se puede
utilizar metdicamente para mejorar el propio proceso
de desarrollo, iteracin tras iteracin.
 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 gua el
trabajo en las iteraciones, mientras que los casos
de uso definen las metas y conducen el trabajo
de cada iteracin. El quitar una de estas tres
ideas reducira 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: visin aproximada, anlisis del negocio,
estimaciones imprecisas de plazos y costos. Se
define la viabilidad del proyecto.
Elaboracin: visin refinada, implementacin
iterativa del ncleo central de la arquitectura,
resolucin de los riesgos altos, identificacin de
ms requisitos y alcance, estimaciones ms
realistas.
Construccin: implementacin iterativa del resto de
requisitos de menor riesgo y elementos ms fciles,
preparacin para el despliegue.
 Las Fases del PU
Transicin: 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 elaboracin NO es la fase de requisitos o

de diseo, sino una fase donde se implementa de
manera iterativa, la arquitectura, que constituye el
ncleo central y se mitigan las cuestiones de alto
riesgo.
 La vida del PU
Cada fase esta subdividida en iteraciones

Inicio Elaboracin Construccin Transicin

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
anlisis de requisitos.
En el PU, un artefacto es el trmino general para
cualquier producto del trabajo: cdigo, grficos
Web, esquema de base de datos, documento de
texto, diagramas, modelos, etctera.
Nos centraremos en 3 disciplinas: modelado del
negocio, requisitos y diseo.
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 descripcin
de los procesos de una empresa (ejemplo: un banco incluye
aceptar depsitos de los clientes, conceder prstamos a los
clientes y hacer inversiones)
La razn para construir un modelo de negocios es que
proporciones una comprensin de los negocios del
cliente como un todo,
con este conocimiento es posible aconsejar al cliente respecto de
qu porciones del sistema de informacin 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 enva una factura al encargado de banquetes
El encargado de banquetes paga la factura
 Disciplinas del PU modelado del negocio

Pueden usarse una serie de tcnicas para

obtener informacin necesaria para
construir el modelo de negocios,
principalmente la entrevista.
 Disciplinas del PU
Requisitos: anlisis de requisitos para la aplicacin, escritura de
casos de uso e identificacin de requisitos no funcionales.

El objetivo de esta disciplina es asegurar que los desarrolladores

construyan el sistema de informacin correcto,

Esto se logra al describir el sistema de informacin 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
informacin.

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 comprensin
detallada necesaria de lo que se va a desarrollar.
 Disciplinas del PU
Anlisis
El propsito de esta disciplina es examinar y refinar los
requisitos. Al hacerlo se logra la comprensin detallada de
los requisitos que deben tener para desarrollar
correctamente un sistema de informacin y darle
mantenimiento con facilidad.
por qu tener la disciplina de anlisis?
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 (espaol, ingls, armenio,),
pero todos los lenguajes naturales de alguna manera son
imprecisos y conducen a malas interpretaciones.
 Disciplinas del PU Anlisis

Ejemplo: se tiene el siguiente requisito

Un registro de partes y un registro de las planta de fabricacin de las

mismas se buscan en una base de datos. Si el registro contiene la
letra A justo despus 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 anlisis es un lenguaje ms preciso que asegurar
que las disciplinas de diseo e implementacin se llevarn a cabo
correctamente.
 Disciplinas del PU
Diseo

En esta disciplina se refina los artefactos del

anlisis hasta que el material est en una forma
en que los programadores puedan implementar.

Adems una serie de requisitos necesitan

familiarizarse en este momento, incluyendo la
eleccin del lenguaje de programacin, as como
la reutilizacin y los problemas de portabilidad.
 Disciplinas del PU
Implementacin

El objetivo de esta disciplina es instaurar el

sistema de informacin 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 iteracin se realiza la prueba de integracin. 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 modelos
Modelo de en el PU
casos de uso

Anlisis
Modelo de
anlisis

Diseo
Modelo de Modelo de
diseo distribucin

Implementacin
Modelo de
implementacin

Prueba
Modelo de
pruebas
Buenas prcticas del PU adicionales
Lo fundamental para apreciar y aplicar el PU es el desarrollo iterativo
(fijando iteraciones cortas) y adaptable.
Uso de tecnologas de objetos (A/DOO Y POO).
Abordar cuestiones de alto riesgo en las primeras iteraciones.
Involucrar continuamente a los usuarios para evaluacin,
retroalimentacin y requisitos.
Construir en las primeras iteraciones una arquitectura que constituya
un ncleo 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 gestin de configuraciones.
 Modelo arquitectnico de capas
La tienda FOO _ X
Articulo ID
Interfaz Menor atencin
Cantidad
Introducir art. Etc.

Capa de lgica Principal atencin

de la aplicacin del caso de estudio
Venta Pago
y objetos del
dominio

Capa de servicios Registro FachadadePersistencia

tcnicos Atencin
secundaria

Un sistema OO se disea en funcin de varias capas

arquitectnicas o subsistemas
 Descripcin de las capas
arquitectnicas
Interfaz de usuario: interfaz grfica, ventanas.
Lgica de la aplicacin y objetos del dominio: objetos
software que representan conceptos del dominio (por
ejemplo una clase software denominada Venta) que
satisfacen los requisitos de la aplicacin.
Servicios tcnicos: objetos de propsito general y
subsistemas que proporcionan servicios tcnicos de
apoyo, como conexin con una base de datos o
registrar los errores. Normalmente estos servicios son
independientes de la aplicacin y se pueden reutilizar
entre varios sistemas.
 Fase de inicio
El propsito de la fase de inicio es establecer una visin
comn 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 elaboracin.
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
organizacin?
2. Se puede implementar el sistema utilizando la
tecnologa actual y dentro de las restricciones de costo y
tiempo?
3. puede integrarse el sistema con otros sistemas
existentes en la organizacin?
 Fase de inicio
La fase de inicio en una frase

Vislumbrar el alcance del producto, visin y

anlisis del negocio

El principal problema resuelto en una frase:

Est de acuerdo el personal involucrado en la

visin del proyecto, y merece la pena invertir en
un estudio serio?
 Artefactos en la fase de inicio
Artefacto
Visin y anlisis del negocio
Modelo de casos de uso
Especificacin complementaria
Glosario
Lista de riesgos y plan de
gestin de riesgos
Prototipos y pruebas de
conceptos
Plan de iteracin
Fase plan y plan de desarrollo
del software
Marco de desarrollo
Comentario
Describe los objetivos y las restricciones de alto nivel, el
anlisis del negocio y proporciona un informe para la
toma de decisiones
Describe los requisitos funcionales y no funcionales
Describe otros requisitos
Terminologa clave del dominio
Describe los riesgos del negocio, tcnicos, recursos,
planificacin y las ideas para mitigarlos o darles
respuesta
Para clarificar la visin y validar las ideas tcnicas
Describe qu hacer en la primera iteracin de la
elaboracin
Estimacin de poca precisin de la duracin y esfuerzo
de la fase de elaboracin
Una descripcin 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 aplicacin informtica utilizada (en parte) para
registrar ventas y realizar pagos. Incluye componentes hardware,
como una computadora y un lector de cdigos de barras y software
para ejecutar el sistema.
Interacta con varias aplicaciones de servicios, como un servicio de
clculo 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 estn disponibles temporalmente, deben
ser capaces de capturar las ventas y gestionar, al menos, pagos en
efectivo.
Un sistema PDV, progresivamente, debe soportar mltiples 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 tctil, PDAs inalmbricos, etc.
Se desea crear un sistema PDV comercial que se vender a diferentes
clientes con necesidades diferentes en trminos de reglas del
negocio. Por lo que necesitamos un mecanismo para proporcionar
flexibilidad y personalizacin.
 Artefacto: Visin
La Visin sirve para comunicar de
manera concisa:
las grandes ideas acerca de por qu se
propuso el proyecto,
cules son los problemas,
quines son las personas involucradas,
qu necesitan, y
cul podra ser la apariencia de la solucin
propuesta.
 Ejemplo Nueva Era: Visin (parcial)
Historia de revisiones
Versin Fecha Descripcin Autor
Borrador de inicio 10-01-2031 Primer borrador. Para Craig Larman
refinarse durante la
elaboracin

Introduccin:
Prevemos una aplicacin punto de venta (PDV) tolerante a fallos de prxima
generacin, PDV Nueva Era, con flexibilidad para poder soportar variaciones en
las reglas del negocio del cliente, mltiples mecanismos de terminal e interfaz
de usuario y la integracin con mltiples sistemas de terceras partes.
Enunciado del Problema:
Los sistemas PDV tradicionales son inflexibles, intolerantes a fallos, y difciles
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 planificacin y medidas, entre otras cuestiones. Esto
afecta a los cajeros, encargados de almacn, administradores del sistema y a la
gestin empresarial.
 Ejemplo Nueva Era: Visin (parcial)
Enunciado de la posicin en el mercado del producto:
-- Resumen conciso de a quin est dirigido el producto.
Alternativas y competencia:
Descripcin del personal involucrado:
Objetivos de alto nivel y problemas claves del personal
involucrado: despus 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 rpido, Prdida de la capacidad de procesamiento bsico
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.
.

. . .
 Ejemplo Nueva Era: Visin (parcial)
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
Invoca Invoca Serv. de Calcula
de Cajero autoriza dor de
PDV r
activida r cin de impuest
servici servici <actor> <actor> <actor>
d de pagos os
os os Sistema Sistema Sistema
ventas
de de rec. de
Administra Encargado contabili humano inventar
Ejemplo Nueva Era: Visin (parcial)
Resumen de beneficiarios:
Caracterstica soportada Beneficio del personal involucrado
Funcionalmente, el sistema proporcionar Servicios de punto de venta rpidos y
todos los servicios tpicos que requiere la automticos
organizacin de las ventas..

Resumen de las caractersticas del sistema:

Entrada de ventas.
Autorizacin de pagos (crdito, dbito, cheque)
Procesamiento de venta automtico sin conexin cuando fallan los
componentes.
.
Otros requisitos y restricciones:
Abarca las restricciones de diseo, fiabilidad, rendimiento, soporte,
empaquetado, etctera: dirjase a la Especificacin Complementaria
y a los casos de uso.
 Ejemplo Nueva Era: Especificacin
Complementaria (parcial)
Historia de revisiones
Versin Fecha Descripcin Autor
Borrador de inicio 10-01-2031 Primer borrador. Para Craig Larman
refinarse durante la
elaboracin

Introduccin:
Este documento es el repositorio de todos los requisitos del PDV Nueva
Era que no se capturan en los casos de uso.
Funcionalidad:
(Funcionalidad comn entre muchos casos de uso)
Registro y gestin 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.
 Ejemplo Nueva Era: Especificacin Complementaria (parcial)

Seguridad
Todo uso requiere la autenticacin de los usuarios.
Facilidad de uso
Factores humanos
El cliente ser capaz de ver la informacin en un gran monitor, por tanto:
Se debe ver el texto fcilmente a una distancia de 1 metro.
Evitar colores asociados con formas comunes de daltonismo.
El cajero est mirando a menudo al cliente o los artculos, no a la pantalla
de la computadora, por tanto, se deben comunicar las seales y avisos con
sonidos, en lugar de slo mediante grficos.
Fiabilidad:
Capacidad de recuperacin
Si se produce algn fallo al usar un servicio externo, intentar solucionarlo
con una solucin local para no obstante, completar una venta. Se necesita
mucho mas anlisis aqu .
Rendimiento
Los compradores quieren completar el proceso de ventas muy rpido. Un
cuello de botella potencial es la autorizacin de pagos externa. El objetivo
es conseguir la autorizacin en menos de 1 minuto el 90% de las veces.
 Ejemplo Nueva Era: Especificacin Complementaria (parcial)
Interfaces
Interfaces y hardware destacable
Monitor con pantalla tctil.
Escner lser de cdigo de barras.
Impresora de recibos.
Lector de tarjetas de crdito/dbito.
Interfaces software
Para los sistemas de colaboracin externos (inventario, contabilidad, ) se
requieren diversas interfaces.
Reglas del dominio (negocio)

ID Regla Grado de variacin Fuente

REGLA1 Se requiere la firma de
pagos a crdito
Se solicita la firma de los La poltica de todas
compradores, en 2 aos los las compaas de
clientes solicitarn la firma en autorizacin de
aparato digital y en 5 aos la
nueva firma digital nica crdito
soportada por la ley
americana

. ..
 Visin, especificacin complementaria, casos de
uso, Qu va primero?

No es til ser estricto en el orden de algunos artefactos.

Durante la creacin 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 Visin.

2.Identificar los objetivos de usuario y los casos de uso.
3.Escribir algunos casos de uso y comenzar con la
Especificacin Complementaria.
4.Refinar la Visin, resumiendo la informacin a partir de
stos.
 Glosario
El GLOSARIO es una lista de los trminos relevantes y sus definiciones.
Es sorprendentemente habitual que un trmino propio del dominio, se
utilice de forma ligeramente distinta por diferentes personas involucradas;
esto tiene que resolverse para reducir los problemas de comunicacin y
los requisitos ambiguos.

En el PU, el Glosario juega tambin 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
trminos y descripciones.
Durante la fase de elaboracin, podra ampliarse a un diccionario de
datos.
Los atributos de los trminos podran contener:
Alias.
Descripcin.
Formato (tipo, longitud, unidad)
Relaciones con otros elementos
Rango de valores.
Reglas de validacin
 Ejemplo Nueva Era: Glosario (parcial)
Historia de revisiones
Versin Fecha Descripcin Autor
Borrador de inicio 10-01-2031 Primer borrador. Para Craig Larman
refinarse durante la
elaboracin
Definiciones
Trmino Definicin e informacin Alias
Artculo Un artculo o servicio en venta
Autorizacin de pago Validacin llevada a cabo por un servicio
externo de autorizacin de pago, que har o
garantizar el pago al vendedor
UPC Cdigo de 12 dgitos que identifica a un artculo. Cdigo de producto
Se representa mediante un cdigo de barras en universal
los artculos
Solicitud de Un compuesto de elementos enviados
autorizacin de pago electrnicamente a un servicio de autorizacin
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 ms 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 prcticas, una de ellas es
la gestin de requisitos.
El PU utiliza un proceso que acepta el cambio y la
retroalimentacin como motores centrales en el descubrimiento
de los requisitos, esto se debe a su caracterstica de ser
iterativo e incremental.
Se utiliza la tcnica 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 nemotcnico que significa los
siguientes tipos de requisitos:
Funcional (Functional): carcteristicas, capacidades y
seguridad.
Facilidad de uso (Usability): factores humanos, ayuda,
documentacin.
Fiabilidad (Reliability): frecuencia de fallos, capcidad
de recuperacin de un fallo y grado de previsin.
Rendimiento (Performance): tiempos de respuesta,
productividad, precisin, disponibilidad, uso de
recursos.
Soporte (Supportability): adaptabilidad, facilidad de
mantenimiento, internacionalizacin, configurabilidad.
 Tipos de requisitos
El + en FURPS+ indica requisitos adicionales
como:
Implementacin: limitacin de recursos,
lenguajes y herramientas, hardware
Interfaz: restricciones impuestas para la
interaccin con sistemas externos.
Operaciones: gestin del sistema en su puesta
en marcha.
Empaquetamiento
Legales: licencias, etctera.
Lo normal es dividir los requisitos en funcionales
(comportamiento) y no funcionales (todo lo
dems).
 Modelo de casos de uso
El modelo de casos de uso debe contener
los siguientes elementos:
Lista Actor-Semntica.
Lista Actor- Objetivo.
Lista de Casos de Uso.
Descripcin breve de casos de uso.
Descripcin completa (10 al 20%) de casos de
uso utilizando una plantilla.
Diagrama de casos de uso.
Modelo de casos de uso: Identificacin 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 informticos (procesos
software guardianes)

Los actores de apoyo proporcionan servicios al sistema que se est diseando.

Por qu se identifican? Para clarificar las interfaces externas y los protocolos.

Los actores pasivos estn interesados en el comportamiento del caso de uso,

pero no es principal ni de apoyo. Por ejemplo la Secretara de
Administracin Tributaria (SAT).
Por qu se identifican? Para asegurar que todos los intereses necesarios se
han identificado y satisfecho.

Lista actor-semntica

Contiene todos los actores y una descripcin de ellos.

 Lista Actor-Objetivo
Actor Objetivo
Cajero Registrar ventas
Gestionar devoluciones
Abrir caja
Cerrar caja

El resultado de esta actividad es una nueva versin

del modelo de casos de uso con un conjunto
actualizado de actores. La descripcin 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 prrafo, normalmente
del escenario principal con xito.
El siguiente paso es escribir casos de uso completos
usando una plantilla.
Cuntos 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 podran
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 mayora de los actores, objetivos y casos de uso, con
los nombres.
La mayora 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 comprensin
del alcance y complejidad.
 Qu sucedi en la fase de inicio?
Identificacin de la mayora de los requisitos de calidad
influyentes y de riesgo.
Lista de riesgo
Por ejemplo, el director en realidad quiere una demostracin 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 ms profundo.
Prototipos de pruebas de conceptos tcnicos y otros
estudios para explorar la viabilidad tcnica de los
requisitos especiales.
Funcionan los Java Swing de manera correcta en pantallas
tctiles?.
Prototipos orientados a la interfaz de usuario para
clarificar la visin de los requisitos funcionales.
 Qu sucedi en la fase de inicio?
Recomendaciones sobre qu componentes comprar/construir/
reutilizar, que se refinarn en la elaboracin.
Por ejemplo, una recomendacin de compra de un paquete de
clculo de impuestos.
Arquitectura de alto nivel candidata y componentes propuestos
No se trata de una descripcin detallada de la arquitectura y no
se pretende que sea final y correcta. Ms bien, se refiere a que
sea una breve especulacin que se va a utilizar como punto de
partida del estudio en la elaboracin. Por ejemplo, una
aplicacin java al lado del cliente, si un servidor de
aplicaciones, Oracle para las bases de datos. En la
elaboracin podr probarse que merece la pena o descubrir
que es una mala idea y rechazarla.
Plan para la primera iteracin
Lista de herramientas candidatas.
 Plan para la iteracin 1 en el PDV
Nueva Era (requisitos a resolver)
Implementar un escenario bsico del caso de
uso del Procesar Venta: entrada de artculos y
recibir el pago en efectivo.
Implementar un caso de uso Poner en Marcha
necesario para dar soporte las necesidades de
inicializacin de la iteracin.
Nada complejo es manejado, solo un simple
escenario que termina con xito y el diseo e
implementacin que lo soporte.
No se resolver la colaboracin con servicios
externos tales como el calculador de impuestos o
base de datos de artculos.
No se aplicarn reglas complejas para fijar los
precios.
Actividades principales de la fase de inicio
De la fase de inicio a la fase de elaboracin
 Fase de elaboracin
La fase de elaboracin en una frase:

Construir la arquitectura base, resolver los

elementos de alto riesgo, definir la mayora
de los requerimientos y estimar la
planificacin y los recursos globales.
 Fase de elaboracin
En esta fase se inicia una serie de
iteraciones durante las que:

Se descubren y estabilizan la mayora de

los requisitos.
Se reducen o eliminan los riesgos
importantes.
Se implementan y prueban los elementos
bsicos de la arquitectura.
 Fase de elaboracin
A menudo la fase de elaboracin consiste de 2 a 4
iteraciones; cada iteracin se recomienda tenga un
tiempo de duracin de 2 a 6 semanas.

Debido a que a cada iteracin se le asigna tiempo, esto

establece una fecha de terminacin fija en la que debe
terminarse dicha iteracin.

Si el equipo no cumple con la fecha, lo requerimientos se

colocan atrs en una lista de tareas futuras, de tal forma
que la iteracin puede terminar en tiempo con una
versin estable y probada.
Actividades principales de la fase de
elaboracin
Artefactos que pueden iniciar en la fase
de elaboracin
Artefacto Comentario
Modelo del dominio Visualizacin de los conceptos del dominio; similar al modelo
de informacin esttica de las entidades del dominio.

Modelo de diseo Conjunto de diagramas que describen el diseo lgico:

diagramas de clase, de interaccin de objetos, paquetes, etc.

Documento de la Un resumen de las ideas de diseo ms importantes y su

A r q u i t e c t u r a motivacin.
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 descripcin de lo que se va a probar y como se probar.
Artefactos que pueden iniciar en la fase
de elaboracin
Artefacto Comentario

Modelo de implementacin Se corresponde con la implementacin real (cdigo

fuente, ejecutables, BD)

Guiones de casos de uso Descripcin de la IU, caminos de navegacin,

Prototipos de IU modelos de facilidad de uso, etc.
Fase de elaboracin

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 anlisis orientado a
objetos.

Un modelo del dominio es usado como fuente de

inspiracin para disear 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 diseo e
implementacin.
 Modelo del Dominio
Un modelo del dominio es una
representacin 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 notacin 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 notacin 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 iteracin #1, resultar til
realizar un estudio adicional del dominio del problema.

Parte de este estudio comprende la identificacin 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 (ms riesgoso) y
para los escenario alternativos
complejos o frecuentes.
 El DSS muestra el comportamiento del sistema como
DSS para un escenario
unadecaja
Procesar
negra Venta
(describe qu hace el sistema si
explicar cmo lo hace)

:Sistema
:Cajero
crearNuevaVenta()

introducirArt(artID, cantidad)
El *[..] indica
Descripcin, total que la caja es
para iterar
* [ms artculos]

finalizarVenta() Va l o r d e r e t o r n o
asociado con el
mensaje anterior,
Total con impuestos ignora la
presentacin y el
medio
realizarPago(cantidad)
Abstraccin que
Cambio devuelto, recibo representa
entrada de datos,
mediante un
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
introducirArt(artID, cantidad)
3. El cajero introduce el cdigo del
artculo
Descripcin, total
4. El sistema registra la lnea de venta y
presenta la descripcin y precio del finalizarVenta()
artculo 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 realizarPago(cantidad)
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 Registro-venta-de
LineadeVenta
del dominio Articulo
cantidad
0..1 1

1..* *
Asociacin Contenida-en Almacenado-en
1
1
Venta Tienda

fecha direccin
Atributos hora nombre
1
1 1
Pagada-mediante Alberga
1 1..*
La tarea fundamental en
el anlisis orientado a
objetos es realizar la Pago
Capturada-en Registro
descomposicin de un
d o m i n i o e n c l a s e s cantidad
conceptuales individuales 1
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 grfica de usuario.
Responsabilidades o mtodos.
Identificacin de clases conceptuales
En un desarrollo iterativo, incrementalmente se
construye un modelo del dominio sobre varias
iteraciones en la fase de elaboracin.

En cada iteracin, el modelo del dominio est

limitado al escenario actual y anterior bajo
consideracin.
Identificacin de clases conceptuales

Por lo tanto la tarea central es identificar la

clases conceptuales relacionadas al
escenario que se est resolviendo.
Es comn que nos falten clases
conceptuales durante el paso inicial de
identificacin y descubrirlas ms tarde
durante la consideracin de atributos o
asociaciones, o durante el trabajo de
diseo. Cuando se encuentren, pueden ser
agregadas al modelo del dominio.
Identificacin de clases conceptuales

GUA: 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. Anlisis lingstico.
2. Usar una lista de categoras de clases
conceptuales.
Identificacin de clases usando anlisis
lingstico
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 dbil en este enfoque es la imprecisin
del lenguaje natural; frases nominales diferentes
podran representar la misma clase conceptual o
atributo.
Se recomienda que se combine con la tcnica de
Lista de Categoras de Clases Conceptuales.
Identificacin de clases usando anlisis
lingstico
El modelo del dominio es una visualizacin de los
conceptos del domino y vocabulario relevantes.

Por lo tanto, los casos de uso constituyen una

fuente rica a explorar mediante la identificacin
de frases nominales.

Por ejemplo: utilizaremos el escenario principal de

xito del caso de uso Procesar Venta.
 Identifique las clases usando la tcnica
de anlisis lingstico
Escenario principal de xito
1. El cliente llega a una terminal PDV con mercancas
y/o servicios.
2. El cajero comienza una nueva venta.
3. El cajero introduce el identificador del artculo.
4. El sistema registra la lnea de venta y presenta la
descripcin del artculo, 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.
 Identificacin de clases conceptuales

Escenario principal de xito

1. El cliente llega a una terminal PDV con mercancas
y/o servicios.
2. El cajero comienza una nueva venta.
3. El cajero introduce el identificador del artculo.
4. El sistema registra la lnea de venta y presenta la
descripcin del artculo, 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.
 identificacin de clases usando una
lista de categoras
Se inicia la creacin de un modelo del
dominio haciendo una lista de clases
conceptuales candidatas.
La siguiente tabla contiene categoras que
normalmente merece la pena tener en
cuenta, aunque no en ningn orden
particular de importancia.
El dominio son tiendas y reservaciones de
vuelos.
 Categoras de clases conceptuales
Categora
Objetos tangibles o fsicos
Especificaciones, diseos o
descripciones de las cosas
Lugares
Transacciones
Lneas de la transaccin
Roles de la gente
Contenedores de otras cosas
Cosas en un contenedor
Otros sistemas informticos o
electromecnicos externos al sistema
Conceptos abstractos
Organizaciones
hechos
Ejemplos
Registro (TPV), avin
EspecificaionDelProducto,
DescripcionDelVuelo
Tienda
Venta, Pago, Reserva
LineaDeVenta
Cajero, Piloto
Tienda, Lata, Aviion
Articulo, Pasajero
SistemaAutorizacionPagoCredito,
ControlTraficoAereo
Ansia, Acrofobia
DeptoDeVentas, CompaiaAerea
Venta, Pago, Reunion, Vuelo, Aterrizaje
Clases conceptuales candidatas
A partir del anlisis de la Lista de Categoras
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 estn
estudiando actualmente. En este caso el
escenario simplificado de Procesar Venta
Clases conceptuales candidatas
Registro EspecificacinDelPro
Artculo ducto
Tienda LineaDeVenta
Venta Cajero
Pago Cliente
CatlogoDeProductos Encargado
Cmo hacer un diagrama de clases del
dominio
Acotado por los requisitos de la iteracin
actual:
Listar las clases conceptuales candidatas
utilizando las tcnicas vistas
anteriormente, representarlas en un
modelo del dominio.
Aadir las asociaciones necesarias para
registrar las relaciones.
Aadir los atributos necesarios para
satisfacer los requisitos de informacin.
 Espritu del cartgrafo
Hacer un modelo del dominio con el espritu
del modo de trabajo del cartgrafo:
Utilice los nombres existentes en el
territorio (dominio).
Excluya las caractersticas irrelevantes.
No aada cosas que no estn ah.
 Modelo del dominio del PDV inicial

Registro Artculo Tienda

Venta LineaDeVenta Cajero

Cliente Encargado
Pago

CatalogoDeProductos EspecificacionDeProducto
 Artefactos UP y evolucin 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
Visin c r
Especificacin c r
complementaria
Glosario c r
Diseo Modelo de diseo c r
Doc. de arq. de soft. c
Modelo de datos c r
Implementacin Modelo de Implem. c r r
Artefactos UP y evolucin temporal

Gestin de Plan de desarrollo c r r r

proy de software

Pruebas Modelo de pruebas c r r

Entorno Marco de c r
desarrollo
Influencia entre los artefactos
 Asociaciones
Las asociaciones denotan alguna dependencia semntica
entre clases, son el tipo de relacin ms general, pero el
de mayor debilidad semntica1.

La identificacin de asociaciones entre clases es un

actividad de anlisis y diseo inicial, momento en el cual
se comienza a descubrir las dependencias generales
entre las clases.

A medida que se contine el diseo y la implementacin

estas asociaciones dbiles se refinarn hacia una
relacin de clase ms concreta (agregacin, 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 relacin que
es necesario conservar durante algn tiempo
(milisegundos o aos, depende del contexto).

Por ejemplo es necesario recordar qu instancias de

LineaDeVenta estn asociadas con una instancia de
venta?

Sin ninguna duda, de otra forma no sera 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 lneas en un diagrama aadirn

ruido visual y lo har menos
comprensible, por lo tanto debemos ser
cuidadosos al aadir lneas de asociacion.
Lista de Asociaciones Comunes
Categora Ejemplos
A es una parte fsica de B Cajon-Registro (TPDV), Ala-
Avion
A es una parte lgica de B LineaDeVenta-Venta,
EtapaVuelo-RutaVuelo
A est contenido fsicamente en Registro-Tienda, Art-Estante
B Pasajero-Avion
A est contenido lgicamente DescDelArt-Catalogo, Vuelo-
en B PlanificacionVuelo
A es una descripcin de B DescDelArt-Articulo,
DescDelVuelo-Vuelo
A es una lnea de una LineaDeVenta-venta
transaccin o informe de B
Lista de Asociaciones Comunes
Categora Ejemplos
A se conoce/registra/recoge/ Venta-Registro, Reserva-
informa/captura en B ListaPasajeros
A es miembro de B Cajero-Tienda, Piloto-
CompaaAerea
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-
transaccin B Billete
Lista de Asociaciones Comunes
Categora Ejemplos

A es una transaccin Pago-Venta, Reserva-

relacionada con otra Cancelacion
transaccin B
A es propiedad de B Registro-Tienda, Avion-
CompaiaAerea
A es un evento relacionado Venta-Cliente, Venta-Tienda
con B Salida-Vuelo
 Asociaciones de prioridad Alta
Categoras de asociaciones que son tiles
incluirlas en un modelo del dominio:

A es una parte fsica o lgica de B

A est contenida fsica o lgicamente en B
A se registra en B.
 Asociaciones
El extremo final de una asociacin es
llamado rol. Los roles pueden tener los
siguientes adornos.

Nombre
Expresin de multiplicidad
Navegabilidad
 Asociaciones Multiplicidad
El valor de la multiplicidad indica cuntas
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 relacin en el
software, queremos asegurar que una
instancia de Articulo siempre se
Multiplicidad
relacione con del concreta
una instancia rol de
Tienda, de otra forma, indica un error o
corrupcin 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 restriccin de diseo
que ser reflejada en el software.

Ofrecido
Automovil LoteAutos

Qu multiplicidad debemos ponerle a la relacin?

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 asociacin 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 mayscula.

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 Implementacin
Durante el Modelado del Dominio, una
asociacin NO es una declaracin sobre el flujo
de datos, variables de instancia o conexiones
entre objetos en una solucin software.

Una asociacin es una manifestacin de que una

relacin 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
implementacin.
Asociaciones e Implementacin
Muchas de estas relaciones se implementarn
generalmente en software como caminos de navegacin y
visibilidad (tanto en el Modelo de Diseo como en el
Modelo de Datos).

En este momento es conveniente pensar en ellas como

expresiones puramente conceptuales, no
declaraciones sobre la solucin de base de datos o
software.

Al posponer las consideraciones de diseo se nos libera de

informaciones y decisiones extraas mientras hacemos un
estudio de anlisis puro y maximiza nuestras opciones de
diseo ms adelante.
 Modelo del Dominio parcial del punto de venta

Registra-venta-de
- - Identifique que asociacin sirve :

LibroMa Especifica para recuperar una especificacin

Catalog Contiene
yor ciondelpr de producto a partir de un ID del
oDePro artculo.
1 1..*oducto
1 1 ductos
0.. Registra 1 Usado-por 1 para recuperar el detalle de la
* Describeventa
1 Lineav *
enta Tienda Almacena Articulo para conocer la venta actual,
* generar el total, imprimir recibo.
1 1 1..*
1..*
Conteni 1 Alberga
Registra-completas
do-en 1 1
Venta * Registr Asociaciones necesito - conocer
Capturada-eno
1 1 Son aquellas asociaciones para las que el
c o n o c i m i e n t o d e l a re l a c i n n e c e s i t a
Pagada-mediante
1 1 Iniciado-por 1 conservarse durante algn tiempo.
Registra-ventas-en
-
1 1 1 Asociaciones slo - comprensin
Pago Cliente Cajero
Son aquellas asociaciones que se usan para
enriquecer el conocimiento bsico del dominio
 Atributos
Un atributo es una caracterstica 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
informacin.
 Atributos
Ejemplo: un recibo que contiene la informacin 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:

Direccin, Color, No. de telfono, No. De la

seguridad social, Cdigo de Precio Universal
(UPC), cdigos postales, tipos enumerados.
1 Se conocen como datos primitivos.
 Atributos
El tipo de un atributo, normalmente no debera ser un
concepto de dominio complejo, como Venta o Aeropuerto.

Ejemplo: No es atributo simple

P Cajero
El atributo registroActual en la clase Cajero no es
e nombre
deseable porque su tipo tiene la intencin de ser un
registroActual
o Registro, que no es un tipo de atributo simple (nmero o
r string).

M Cajero Registro
ej nombre 1 numero
o Utiliza
r 1
 Atributos
Otro ejemplo:
No es atributo simple

P Vuelo

e destino Un aeropuerto de destino no es realmente

o una cadena de texto.
r

M Vuelo Aeropuerto
ej 1 Vuela-
o a 1
rLa restriccin 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 slo deban
ser tipos de datos primitivos o simples.

Durante el trabajo de diseo e implementacin, se ver que las

asociaciones entre objetos representadas en el modelo del dominio,a
menudo, se implementarn como atributos que referencian a otros objetos
software complejos.
 Atributos
Gua para identificar si un atributo aparentemente simple
debe representarse como una clase no primitiva.
Est compuesto de secciones separadas.
Nmero de telfono, nombre de persona
Habitualmente, hay operaciones asociadas con l, como
anlisis sintctico o validacin.
Nmero de la seguridad social.
Tiene otros atributos
El precio de promocin podra tener una fecha de inicio y
terminacin.
Usa una cantidad con una unidad
La cantidad del pago tiene una unidad monetaria.
 Atributos
Es una abstraccin de uno o ms tipos con alguna de estas
cualidades:
El identificador del artculo en el dominio de ventas es una
generalizacin de tipos como el Cdigo de Producto
Universal(UPC) o el Nmero de Artculo Europeo (EAN).

Aplicando esta gua a los atributos del modelo del dominio del punto de
venta se obtiene:
El atributo direccin debe ser una clase no primitiva Direccin 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 dgito
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 descripcin ms detallada del
comportamiento del sistema.

Los contratos describen el comportamiento

detallado del sistema en funcin de los cambios
de estado de los objetos del Modelo de
Dominio, despus de la ejecucin de una
operacin 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 pblica 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()

introducirArt(artID, cantidad)
Estos eventos de entrada del
Descripcin, total sistema invocan operaciones
del sistema.
* [ms artculos]
El evento del sistema
CrearNuevaVenta() invoca
finalizarVenta() una operacin del sistema
d e n o m i n a d a
c r e a r N u e v a Ve n t a y a s
Total con impuestos sucesivamente.

realizarPago(cantidad) Esto es lo mismo que

cuando en POO decimos que
el mensaje Inserta, invoca al
mtodo Inserta.
Cambio devuelto, recibo
 Operaciones e interface del Sistema

En UML, el sistema como un todo se puede representar

mediante una clase.

Sistema
CrearNuevaVenta()
introducirArt(artID, cantidad)
finalizarVenta()
realizarPago(cantidad)

Los contratos son escritos para cada operacin del sistema

para describir su comportamiento.
 Secciones del contrato
Contrato C#: Nombre de la operacin
Operacin: nombre de la operacin y parmetro.
Referencias cruzadas: (opcional) casos de uso en
los que pueden tener lugar esta operacin.
Precondiciones: suposiciones relevantes sobre el
estado del sistema o de los objetos del Modelo del
Dominio, antes de la ejecucin de la operacin. No
se comprobar en la lgica de esta operacin, 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 despus de que se complete la
operacin.
 Ejemplo de contrato
Contrato C01: crearNuevaVenta
Operacin: crearNuevaVenta()
Referencia cruzada: caso de uso: Procesar Venta
Precondiciones: ninguna
Postcondiciones: - Se cre una instancia de
Venta v (creacin de instancias)
- v se asoci con el Registro
(formacin de asociaciones)
- Se inicializaron los atributos de v
 Ejemplo de contrato
Contrato C02: introducirArticulo
Operacin: introducirArticulo(articuloID:ArticuloID, cantidad:integer)
Referencia cruzada: caso de uso: Procesar Venta
Precondiciones: Hay una venta en curso
Postcondiciones: - Se cre una instancia de LineaDeVenta ldv
(creacin de instancias)
- ldv se asocia con la Venta actual (formacin
de asociaciones)
- ldv.cantidad pas a ser cantidad
(modificacin de atributos)
- ldv se asoci con una
EspecificacionDelProducto, en base a la coincidencia del
articuloId (formacin de asociaciones)
 Ejemplo de contrato
Contrato C03: finalizarVenta
Operacin: finalizarVenta()
Referencia cruzada: caso de uso: Procesar Venta
Precondiciones: Hay una venta en curso
Postcondiciones: - Venta.esCompletada pas a
ser verdad (modificacin de atributos)
 Contratos
La postcondicin describe cambios en el estado de los objetos del
Modelo del Dominio.

Dichos cambios comprenden:

creacin y eliminacin de instancias
formacin y rotura de asociaciones
modificacin de los atributos

Como ejemplo de postcondiciones que rompe una asociacin,

considere una operacin que permite la eliminacin de lineas de
venta. La postcondicin podra decir:
se rompi la asociacin seleccionada de la LineaDeVenta con la
Venta.
 Contratos
Las postcondiciones no son acciones que
se ejecutarn durante la operacin; ms
bien, son declaraciones sobre los objetos
del Modelo del Dominio que son verdad
cuando la operacin ha terminado
despus de que el humos se haya
despejado-
 Contratos el espritu de las postcondiciones: el escenario y teln

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 operacin, tome una fotografa del escenario.

2. Baje el teln y aplique las operaciones del sistema (ruido de martillos o
campanas, gritos,)
3. Suba el teln y tome una segunda fotografa.
4. Compare las fotografas 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 podra 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 especificacin 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

razn prctica apremiante que requiera
que la gente aprenda y utilice OCL,
mantenga las cosas simples y utilice el
lenguaje natural.