OOsistemasII ClasesTeoricas

El Paradigma Orientado a Objeto
UCSE FMA - Sistemas de Informacin II
Por qu la Orientacin a Objetos?

Proximidad de los conceptos de modelado respecto de las entidades del mundo real
Mejora captura y validacin de requisitos Acerca el espacio del problema y el
espacio de la solucin Modelado integrado de propiedades estticas y dinmicas del mbito del problema
Facilita construccin, mantenimiento y
reutilizacin
Por qu la Orientacin a Objetos?

Conceptos comunes de modelado durante el anlisis, diseo e implementacin
Facilita la transicin entre distintas fases Favorece el desarrollo iterativo del sistema Disipa la barrera entre el qu y el
cmo Sin embargo, existen problemas ...
Problemas en OO
...Los conceptos bsicos de la OO se conocen desde hace dos dcadas, pero su aceptacin todava no est tan extendida como los beneficios que esta tecnologa puede sugerir ...La mayora de los usuarios de la OO no utilizan los conceptos de la OO de forma purista, como inicialmente se pretenda. Esta prctica ha sido promovida por muchas herramientas y lenguajes que intentan utilizar los conceptos en diversos grados
--Wolfgang Strigel
Problemas en OO
Un objeto contiene datos y operaciones que operan sobre los datos, pero ... Podemos distinguir dos tipos de objetos degenerados: Un objeto sin datos (que sera lo mismo que una biblioteca de funciones) Un objeto sin operaciones, con slo operaciones del tipo crear, recuperar, actualizar y borrar (que se correspondera con las estructuras de datos tradicionales) Un sistema construido con objetos degenerados no es un sistema verdaderamente orientado a objetos
Las aplicaciones de gestin estn constituidas mayoritariamente por objetos degenerados
Fundamentos de Modelado OO
Objetos
Objeto = unidad atmica que encapsula estado y comportamiento La encapsulacin en un objeto permite una alta cohesin y un bajo acoplamiento Un objeto puede caracterizar una entidad fsica (coche) o abstracta (ecuacin matemtica)
Objetos
El Modelado de Objetos permite representar el ciclo de vida de los objetos a travs de sus interacciones En UML, un objeto se representa por un rectngulo con un nombre subrayado
Otro objeto Un objeto
Otro objeto ms
Objetos
Ejemplo de varios objetos relacionados:
Cuenta Corriente 101 Juan Banco de Valencia
Felipe Cuenta Corriente 114
Objetos
Objeto = Identidad + Estado + Comportamiento El estado est representado por los valores de los atributos Un atributo toma un valor en un dominio concreto
Un coche Azul 979 Kg 70 CV ...
Estado
El estado evoluciona con el tiempo Algunos atributos pueden ser constantes El comportamiento agrupa las competencias de un objeto y describe las acciones y reacciones de ese objeto Las operaciones de un objeto son consecuencia de un estmulo externo representado como mensaje enviado desde otro objeto
Comportamiento
Ejemplo de interaccin:
Un Objeto Operacin 1
1: Un mensaje
Operacin 2
Otro Objeto
Comportamiento
Los mensajes navegan por los enlaces, a priori en ambas direcciones Estado y comportamiento estn relacionados Ejemplo: no es posible aterrizar un avin si no est volando. Est volando como consecuencia de haber despegado del suelo
Persistencia
La persistencia de los objetos designa la capacidad de un objeto trascender en el espacio/tiempo Podremos despus reconstruirlo, es decir, tomarlo de memoria secundaria para utilizarlo en la ejecucin (materializacin del objeto) Los lenguajes OO no proponen soporte adecuado para la persistencia, la cual debera ser transparente, un objeto existe desde su creacin hasta que se destruya
Comunicacin
Un sistema informtico puede verse como un conjunto de objetos autnomos y concurrentes que trabajan de manera coordinada en la consecucin de un fin especfico El comportamiento global se basa pues en la comunicacin entre los objetos que la componen
Comunicacin
Categoras de objetos: Activos - Pasivos Cliente Servidores, Agentes Objeto Activo: posee un hilo de ejecucin (thread) propio y puede iniciar una actividad Objeto Pasivo: no puede iniciar una actividad pero puede enviar estmulos una vez que se le solicita un servicio Cliente es el objeto que solicita un servicio. Servidor es el objeto que provee el servicio solicitado
Comunicacin
Los agentes renen las caractersticas de clientes y servidores Son la base del mecanismo de delegacin Introducen indireccin: un cliente puede comunicarse con un servidor que no conoce directamente
Comunicacin
Ejemplo con objeto agente:
Servidor 1 2: Un agente 1: Un cliente 3: Servidor 2
El Concepto de Mensaje
Objeto 1 1: Mensaje A Objeto 2
2: Mensaje C 4: Mensaje E Objeto 3 3: Mensaje D Objeto 4
Diagrama de Clases
Clasificacin
El mundo real puede ser visto desde abstracciones diferentes (subjetividad) Mecanismos de abstraccin:
Clasificacin / Instanciacin Composicin / Descomposicin Agrupacin / Individualizacin Especializacin / Generalizacin
La clasificacin es uno de los mecanismos de abstraccin ms utilizados
Clases
La clase define el mbito de definicin de un conjunto de objetos Cada objeto pertenece a una clase Los objetos se crean por instanciacin de las clases
Clases: Notacin Grfica

Cada clase se representa en un rectngulo con tres compartimientos: nombre de la clase atributos de la clase operaciones de la clase
Motocicleta color cilindrada velocidad mxima arrancar() acelerar() frenar()
Clases: Encapsulacin
La encapsulacin presenta dos ventajas bsicas:
Se protegen los datos de accesos indebidos El acoplamiento entre las clases se disminuye Favorece la modularidad y el mantenimiento
Los atributos de una clase no deberan ser manipulables directamente por el resto de objetos
Clases: Encapsulacin
Los niveles de encapsulacin estn heredados de los niveles de C++:
(-) Privado : es el ms fuerte. Esta parte es totalmente invisible (excepto para clases friends en terminologa C++)
(#) Los atributos/operaciones protegidos estn visibles para las clases friends y para las clases derivadas de la original (+) Los atributos/operaciones pblicos son visibles a otras clases (cuando se trata de atributos se est transgrediendo el principio de encapsulacin)
Relaciones entre Clases

Los enlaces entre de objetos pueden representarse entre las respectivas clases Formas de relacin entre clases:
Asociacin y Agregacin (vista como un caso particular de asociacin) Generalizacin/Especializacin

Las relaciones de Agregacin y Generalizacin forman jerarquas de clases
Asociacin
La asociacin expresa una conexin bidireccional entre objetos Una asociacin es una abstraccin de la relacin existente en los enlaces entre los objetos
Univ. de Murcia : Universidad Un enlace Antonio : Estudiante
Universidad Una asociacin
Estudiante
Asociacin
Ejemplo:
casado-con mujer
0..1 0..1
marido
Persona nombre s.s.
emplea-a
Compaa trabaja-para nombre direccin *
jefe Administra
0.. 1
empleado
Asociacin
Especificacin de multiplicidad (mnima...mxima)
1 0..1 M..N * 0..* 1..* Uno y slo uno Cero o uno Desde M hasta N (enteros naturales) Cero o muchos Cero o muchos Uno o muchos (al menos uno)
La multiplicidad mnima >= 1 establece una restriccin de existencia
Generalizacin
Permite gestionar la complejidad mediante un ordenamiento taxonmico de clases Se obtiene usando los mecanismos de abstraccin de Generalizacin y/o Especializacin La Generalizacin consiste en factorizar las propiedades comunes de un conjunto de clases en una clase ms general
... Generalizacin
Nombres usados: clase padre - clase hija. Otros nombres: superclase - subclase, clase base - clase derivada Las subclases heredan propiedades de sus clases padre, es decir, atributos y operaciones (y asociaciones) de la clase padre estn disponibles en sus clases hijas
... Generalizacin
Vehculo
Veihculo Terrestre
Vehculo Areo
Coche
Camin
Avin
Helicptero
Clasificacin Mltiple (herencia mltiple)

Se presenta cuando una subclase tiene ms de una superclase La herencia mltiple debe manejarse con precaucin. Algunos problemas son el conflicto de nombre y el conflicto de precedencia Se recomienda un uso restringido y disciplinado de la herencia. Java y Ada 95 simplemente no ofrecen herencia mltiple
Herencia Mltiple
Uso disciplinado de la herencia mltiple: clasificaciones disjuntas con clases padre en hojas de jerarquas alternativas
Bpedo nro patas Con Pelos cubertura Con Plumas cobertura cobertura Con Escamas Animal comida Carnvoro comida Cuadrpedo nro patas Herbvoro
Conejo
Polimorfismo
El trmino polimorfismo se refiere a que una caracterstica de una clase puede tomar varias formas El polimorfismo representa en nuestro caso la posibilidad de desencadenar operaciones distintas en respuesta a un mismo mensaje Cada subclase hereda las operaciones pero tiene la posibilidad de modificar localmente el comportamiento de estas operaciones
Polimorfismo
Ejemplo: todo animal duerme, pero cada clase lo hace de forma distinta
Anim al dorm ir()
?
dormir
?
Len Oso T igre
Polimorfismo
Animal dormir()
Dormir() { }
Len dormir()
Dormir() { sobre el vientre }
Oso dormir()
Tigre dormir()
Dormir() { sobrela espalda }
Dormir() { en un rbol }
Diagrama de Casos de Uso
Casos de Uso
Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el p.d.v. del usuario Permiten definir los lmites del sistema y las relaciones entre el sistema y el entorno Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementacin Comparacin con respecto a los Diagramas de Flujo de Datos del Enfoque Estructurado
Casos de Uso
Los Casos de Uso cubren la carencia existente en mtodos previos (OMT, Booch) en cuanto a la determinacin de requisitos Los Casos de Uso particionan el conjunto de necesidades atendiendo a la categora de usuarios que participan en el mismo Estn basado en el lenguaje natural, es decir, es accesible por los usuarios
Casos de Uso
Ejemplo:
Actor A
Caso de Uso A
Caso de Uso B
Actor B
Casos de Uso
Actores: Principales: personas que usan el sistema Secundarios: personas que mantienen o administran el sistema Otros sistemas: sistemas con los que el sistema interacta La misma persona fsica puede interpretar varios papeles como actores distintos El nombre del actor describe el papel desempeado
Casos de Uso
Los Casos de Uso se determinan observando y precisando, actor por actor, las secuencias de interaccin, los escenarios, desde el punto de vista del usuario Un escenario es una instancia de un caso de uso Los casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo estar dirigido por los casos de uso
Casos de Uso: Relaciones

UML define cuatro tipos de relacin en los Diagramas de Casos de Uso:
Comunicacin
Actor
Caso deUso

Inclusin : una instancia del Caso de Uso origen incluye tambin el comportamiento descrito por el Caso de Uso destino
<<include>>
Caso de Uso Origen
Caso deUso Desti no
<<include>> reemplaz al denominado <<uses>>

Extensin : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino
<<extend>>
Caso de Uso Origen
Caso deUso Desti no

Herencia : el Caso de Uso origen hereda la especificacin del Caso de Uso destino y posiblemente la modifica y/o ampla
Caso de UsoHij o
Caso de Uso Padre

Ejemplo:
<<include>> Iden i ic n t f aci
Cliente
Transferencia
<< e xtend >>
Transferencia en Internet
RF- <id del requisito> Versin Autores Fuentes Objetivos asociados Descripcin
Precondicin Secuencia Normal
Postcondicin Excepciones
Rendimiento
Frecuencia esperada Importancia Urgencia Comentarios
<nombre del requisito funcional> <numero de versin y fecha> <autor> <fuente de la versin actual> <nombre del objetivo> El sistema deber comportarse tal como se describe en el siguiente caso de uso { concreto cuando <evento de activacin> , abstracto durante la realizacin de los casos de uso <lista de casos de uso>} <precondicin del caso de uso> Paso Accin 1 {El <actor> , El sistema} <accin realizada por el actor o sistema>, se realiza el caso de uso < caso de uso RF-x> 2 Si <condicin>, {el <actor> , el sistema} <accin realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x> 3 4 5 6 n <postcondicin del caso de uso> Paso Accin 1 Si <condicin de excepcin>,{el <actor> , el sistema} }<accin realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x>, a continuacin este caso de uso {continua, aborta} 2 3 Paso Cota de tiempo 1 n segundos 2 n segundos <n de veces> veces / <unidad de tiempo> {sin importancia, importante, vital} {puede esperar, hay presin, inmediatamente} <comentarios adicionales>
Modelo de Casos de Uso y Modelo Conceptual (Anlisis)

La especificacin de cada caso de uso y los correspondientes D. de Interaccin establecen el vnculo con el modelo conceptual En mtodos OO que carecen de una tcnica de captura de requisitos se comienza inmediatamente con la construccin del modelo conceptual (anlisis)
Diagramas de Interaccin
Interaccin
Los objetos interactan para realizar colectivamente los servicios ofrecidos por las aplicaciones. Los diagramas de interaccin muestran cmo se comunican los objetos en una interaccin Existen dos tipos de diagramas de interaccin: el Diagrama de Colaboracin y el Diagrama de Secuencia
Diagramas de interaccin
El Diagrama de Secuencia es ms adecuado para observar la perspectiva cronolgica de las interacciones El Diagrama de Colaboracin ofrece una mejor visin espacial mostrando los enlaces de comunicacin entre objetos El D. de Colaboracin puede obtenerse automticamente a partir del correspondiente D. de Secuencia (o viceversa)
Diagrama de Secuencia
Muestra la secuencia de mensajes entre objetos durante un escenario concreto Cada objeto viene dado por una barra vertical El tiempo transcurre de arriba abajo Cuando existe demora entre el envo y la atencin se puede indicar usando una lnea oblicua
Diagrama de Secuencia
: Encargado :WInPrstamos :Socio :Video :Prstamo prestar(video, socio) verificar situacin socio verificar situacin video
registrar prstamo entregar recibo
Diagrama de Colaboracin
Son tiles en la fase exploratoria para identificar objetos La distribucin de los objetos en el diagrama permite observar adecuadamente la interaccin de un objeto con respecto de los dems La estructura esttica viene dada por los enlaces; la dinmica por el envo de mensajes por los enlaces
:Socio
:Video 2: verificar situacin socio
1: prestar(video, socio) :WInPrstamos 5: entregar recibo : Encargado
3: verificar situacin video
4: registrar prstamo
:Prstamo
Mensajes
Un mensaje desencadena una accin en el objeto destinatario Un mensaje se enva si han sido enviados los mensajes de una lista (sincronizacin):
A.1, B.3 / 1:Mensaje
Diagrama de Estados
Diagrama de Estados
Ejemplo de un Diagrama de Estados para la clase persona:
contratar
desempleado
en activo perder empleo jubilarse jubilarse jubilado
Diagrama de Actividad
El Diagrama de Actividad es una especializacin del Diagrama de Estado, organizado respecto de las acciones y usado para especificar:
Un mtodo Un caso de uso Un proceso de negocio (Workflow)

Las actividades se enlazan por transiciones automticas. Cuando una actividad termina se desencadena el paso a la siguiente actividad
Ejemplos
Buscar Bebida [ hay caf ] [ hay zumo ] Poner caf en filtro Aadir agua al depsito Coger taza Coger zumo [ no hay caf ] [ no zumo ]
Poner filtro en mquina
Encender mquina / cafetera.On Caf en preparacin indicador de fin Servir caf Beber
... Ejemplos
Pasaj ero Vendedor Airline
Solicitar pasaje
Verificar existencia vuelo Dar detalles vuelo Informar alternativas y precios
Seleccionar vuelo
Solicitar pago Pagar pasaje
Reservar plazas Confirmar plaza reservada
Emitir billete
Diagrama de Componentes
Diagrama de Componentes
Los diagramas de componentes describen los elementos fsicos del sistema y sus relaciones Muestran las opciones de realizacin incluyendo cdigo fuente, binario y ejecutable
...Diagrama de Componentes
Los componentes representan todos los tipos de elementos software que entran en la fabricacin de aplicaciones informticas. Pueden ser simples archivos, paquetes de Ada, bibliotecas cargadas dinmicamente, etc. Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente utiliza los servicios ofrecidos por otro componente
Interfaz de Terminal Control y Anlisis
Gestin de Cuentas
Rutinas de conexin
Acceso a BD
Proceso de Desarrollo de SW basado en UML
Qu es un Proceso de Desarrollo de SW?

Define Quin debe hacer Qu, Cundo y Cmo debe hacerlo
Requisitos nuevos o modificados Proceso de Desarrollo de Software Sistema nuevo o modificado
No existe un proceso de software universal. Las caractersticas de cada proyecto (equipo de desarrollo, recursos, etc.) exigen que el proceso sea configurable
Proceso Iterativo e Incremental

El ciclo de vida iterativo se basa en la evolucin de prototipos ejecutables que se muestran a los usuarios y clientes En el ciclo de vida iterativo a cada iteracin se reproduce el ciclo de vida en cascada a menor escala Los objetivos de una iteracin se establecen en funcin de la evaluacin de las iteraciones precedentes
... Proceso Iterativo e Incremental

Las actividades se encadenan en una minicascada con un alcance limitado por los objetivos de la iteracin
Anlisis Diseo Codific. n veces Pruebas e Integracin
... Proceso Iterativo e Incremental

Cada iteracin comprende: Planificar la iteracin (estudio de riesgos) Anlisis de los Casos de Uso y escenarios Diseo de opciones arquitectnicas Codificacin y pruebas. La integracin del nuevo cdigo con el existente de iteraciones anteriores se hace gradualmente durante la construccin Evaluacin de la entrega ejecutable (evaluacin del prototipo en funcin de las pruebas y de los criterios definidos) Preparacin de la entrega (documentacin e instalacin del prototipo)
Fases del Ciclo de Vida

El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versin del producto Cada ciclo est compuesto por fases y cada una de estas fases est compuesta por un nmero de iteraciones Las fases son: Inicio o Estudio de oportunidad Elaboracin Construccin Transicin
...Fases del Ciclo de Vida

Inicio o Estudio de oportunidad (inception) Define el mbito y objetivos del proyecto Se define la funcionalidad y capacidades del producto Elaboracin Tanto la funcionalidad como el dominio del problema se estudian en profundidad Se define una arquitectura bsica Se planifica el proyecto considerando recursos disponibles

Construccin
El producto se desarrolla a travs de iteraciones donde cada iteracin involucra tareas de anlisis, diseo e implementacin Las fases de estudio y anlisis slo dieron una arquitectura bsica que es aqu refinada de manera incremental conforme se construye (se permiten cambios en la estructura) Gran parte del trabajo es programacin y pruebas Se documenta tanto el sistema construido como el manejo del mismo Esta fase proporciona un producto construido junto con la documentacin

Transicin Se libera el producto y se entrega al usuario para un uso real Se incluyen tareas de marketing, empaquetado atractivo, instalacin, configuracin, entrenamiento, soporte, mantenimiento, etc. Los manuales de usuario se completan y refinan con la informacin anterior Estas tareas se realizan tambin en iteraciones
...Esfuerzo respecto de las Fases

Estudio de Oportunidad Requisitos Una iteracin en la fase de elaboracin Anlisis Elaboration Construction Transition
Diseo
Implementacin
Pruebas
P re lim ina ry Ite ra tion (s) ite r. #1 ite r. #2 ite r. #n ite r. # n+ 1 ite r. # n+2 ite r. #m ite r. #m +1
Esfuerzo: Duracin:
5% 10%
20% 30%
65% 50%
10% 10%
Un Proceso software basado en UML para sistemas de informacin
Contenidos
Introduccin Modelo del Negocio Modelo de Requisitos Modelo de Anlisis Modelo del Diseo Patrones GRASP y otras heursticas UP vs XP
Construir software es difcil
Mtodo
Mtodo
Establece cmo abordar de un modo sistemtico la construccin de software. Se describe el problema y la solucin mediante un conjunto de modelos. Los mtodos ayudan pero no aseguran el xito. Un mtodo es fruto de la experiencia Importante conocer las limitaciones de un mtodo.
Mtodo
TECNOLOGIA
(OO, UML, Rational Rose)
ORGANIZACION
PROCESO
(RUP)
Tecnologa
Conceptos
Orientacin a objetos Diseo estructurado
Notacin
Especificaciones formales Plantillas Diagramas
Proceso Software
Un proceso bien definido es necesario para desarrollar sistemas software de manera repetible y predecible Permite un negocio sostenible y que puede mejorar en cada nuevo proyecto, incrementando la eficiencia y productividad de la organizacin G. Booch
Proceso Software
Un proceso software debe especificar: la secuencia de actividades a realizar por el equipo de desarrollo: flujo de actividades productos que deben crearse: qu y cundo asignacin de tareas a cada miembro del equipo y al equipo como un todo proporcionar heursticas criterios para controlar el proceso
Proceso Software
Basados en casos de uso Debe ser iterativo e incremental.
Conviene centrarse en los aspectos crticos en las primeras iteraciones para minimizar riesgos. Rpida retroalimentacin
Establecer un proceso marco: Cada empresa de desarrollo debe crearse su propio proceso.
Proceso Software
Procesos giles o Ligeros vs. Procesos Pesados Extreme Programming (XP) vs Unified Process (UP). Proceso pesado
Muchos artefactos creados en un ambiente burocrtico Muchas actividades realizadas con rigidez y control Planificacin detallada a largo plazo Predictivos en vez de adaptativos
Un proceso simple
Simple, eficaz y pequeo: fcil de aprender y usar. Combinacin de proceso de Craig Larman con modelado del negocio. Util para pequeos y medianos proyectos y para un primer proyecto OO. Dirigido por los casos de usos. Desarrollo iterativo e incremental
Etapas del Proceso

Etapa Inicial Comprender procesos del negocio Obtener y especificar requisitos del sistema Identificar y especificar clases y colaboraciones para objetos del dominio. Resolver problemas de diseo (arquitectura, base de datos, redes, patrones,.., nuevas clases y colaboraciones). Implementacin Validacin
Etapas del Proceso

Modelado del Negocio Modelado de Requisitos Modelado del Anlisis Modelado del Diseo Implementacin Validacin
Procesos guiados por casos de uso

Por qu casos de uso? Sencillez e intuitivos
Existen dificultades?
descubrir y especificar casos de uso apropiados
cmo organizar y manejar los casos de uso
Es necesario establecer un conjunto de principios para guiar la identificacin, descripcin y organizacin de los casos de uso
Etapa Inicial
Suponemos que se ha realizado. Estudio de necesidades de la empresa, ver si es factible, alternativas, anlisis de riesgos, oportunidad. Definicin de objetivos del proyecto Planificacin, recursos, presupuesto. Debemos continuar?
Etapa Inicial
Duracin una semana Reuniones para captura de requisitos Se identifican actores, objetivos usuario, casos de uso Casos de uso escritos en formato breve, excepto unos pocos que se consideran claves. Se identifican riesgos Escribir borrador documento Visin y Especificacin Complementaria Prototipado Arquitectura candidata alto nivel Plan para primera iteracin
Modelado del Negocio

Objetivo: Comprender el conjunto de procesos de negocio que tienen lugar dentro de una empresa, como paso previo a establecer los requisitos del sistema a desarrollar. Cmo consigue la empresa sus objetivos?
Procesos de Negocio
Una organizacin tiene una serie de objetivos que satisface a travs de Procesos de Negocio Elementos de un proceso de negocio:
Flujo de Tareas, Agentes, Informacin y Reglas Negocio
Reglas de Negocio regulan el funcionamiento de la empresa

Describen restricciones y comportamientos NO son requisitos, influyen en ellos
Procesos y Reglas del Negocio

Procesos del Negocio
RN1
tarea2 tarea1 tarea3
datos
RN3
tarea5
tarea4
Reglas del Negocio
RN2
Determinan polticas y estructura de la informacin
Ejemplo
Objetivos Estratgicos Satisfacer pedido de cliente Subobjetivos Procesos del Negocio Incrementar las ventas un 25%
Empresa que fabrica productos bajo demanda
Reducir tiempo de fabricacin un 15%
...
Registrar pedido de cliente
Fabricar productos pedidos
Gestionar almacn de materiales
Realizar pedidos a proveedores
Casos de Uso del Negocio Registrar pedido Fabricar productos Gestionar almacn
Generar pedidos a proveedor
Etapas del modelado del negocio

Identificar y definir los procesos de negocio segn los objetivos de la organizacin. Definir un caso de uso del negocio para cada proceso del negocio (diagrama de casos de uso del negocio puede mostrar el contexto y los lmites de la organizacin). Identificar los roles implicados en los diferentes procesos del negocio (diagrama de roles).
Etapas del modelado del negocio

Modelar el flujo de tareas asociado a cada proceso de negocio mediante escenarios (diagramas de secuencia) y diagramas de procesos (diagramas de actividades) que muestran la interaccin entre roles para conseguir el objetivo. Especificar las informaciones y actividades incluidas en cada diagrama de actividades.
Diagrama Casos de Uso del Negocio

<<initiator>> Registrar pedido Cliente
Fabricar producto
Gestionar almacen
Generar pedidos a proveedores
Proveedor
Descripcin de Casos de Uso del Negocio

Textual Visual
Diagrama de Roles:
aspecto estructural de colaboracin entre roles
Escenario:
aspecto de comportamiento de la colaboracin
Diagrama de Proceso:
workflow que realiza el caso de uso del negocio
Caso de Uso del Negocio:

Registrar Pedido
1. El cliente realiza un pedido que incluir la fecha del pedido, los datos del cliente y los productos solicitados. 2. El comercial revisa el pedido (completndolo si es necesario) y le da curso, envindolo al jefe tcnico para que realice el anlisis del mismo. 3. El jefe tcnico analiza la viabilidad de la fabricacin de cada producto del pedido por separado.
- si el producto pedido est en el catlogo, se acepta la fabricacin del mismo, - en caso contrario, el producto es especial, y el jefe tcnico estudia su fabricacin
- si sta es viable, la fabricacin del producto especial es aceptada, - si no es viable, el producto no ser fabricado.
Caso de Uso del Negocio:

Registrar Pedido
4. Una vez estudiado el pedido completo, el jefe tcnico
informa al departamento comercial de la aceptacin/rechazo de cada producto integrante del pedido. si todos los productos de un pedido han sido aceptados, genera una orden de trabajo para cada producto, a partir de una plantilla de fabricacin (la estndar, si el producto estaba catalogado, o bien una nueva generada para el producto, si ste estaba fuera del catlogo). Cada orden de trabajo es enviada al jefe de produccin, y queda pendiente de su lanzamiento.
5. El comercial comunica al cliente el resultado del anlisis de su pedido.
Plantilla de Descripcin Registrar pedido

Proceso de Negocio Objetivo Descripcin
Registrar Pedido Registrar Pedido de Cliente 1. El cliente enva una orden de pedido, que debe incluir la fecha de solicitud, datos del cliente y productos solicitados. Es posible que sea un empleado del departamento comercial quien introduzca el pedido, a peticin de un cliente que realiz su pedido por telfono o lo envi por fax o correo ordinario al dpto. comercial de la empresa. 2. El empleado revisa el pedido (completndolo, si es necesario), y comienza su procesamiento envindolo al jefe tcnico, encargado de su anlisis. 3. El jefe tcnico analiza la viabilidad de cada producto pedido por separado: Si el producto pedido est en el catlogo, su fabricacin es aceptada. En caso contrario es considerado un producto especial y estudia su produccin: - Si es viable, la fabricacin del producto especial es aceptada; - Si no es viable, el producto especial no ser fabricado. 4. Una vez estudiado el pedido completo, el jefe tcnico... Informa al depto comercial de la aceptacin o rechazo de cada producto pedido; Si todos los productos de un pedido han sido aceptados, se crea una orden de trabajo para cada producto, a partir de una plantilla de fabricacin (la estndar si el producto estaba catalogado, o una nueva, especficamente diseada para el producto, si ste no estaba en el catlogo). Cada orden de trabajo es enviada al jefe de produccin, y queda pendiente de su lanzamiento. 5. El comercial comunica al cliente el resultado final del anlisis de su pedido.
Rol Externo
Roles Internos
Prioridad Riesgos Posibilidades Tiempo Ejec. Coste Ejec.
Bsico ... ... ... ...
Modelado del negocio

Identificamos los agentes o roles participantes (En el ejemplo: Cliente, Comercial, Jefe Tcnico y Jefe Produccin ).
Diagrama de Roles: diagramas de clase (clases son roles)
Creamos escenarios para mostrar la colaboracin entre los agentes, distinguimos entre flujos bsicos y alternativos:
Escenarios: diagramas de secuencia (objetos son roles)
Diagrama de roles Registrar Pedido

<<role>> Cliente <<role>> Comercial
* *
<<role>> Jefe Tecnico.
<<role>> Jefe Produccin
Escenario Registrar Pedido

: Cliente : Comercial : JefeTecnico : JefeProduccion
darCursoPedido()
estudiarPedido() * analizarFabricacionProducto()
planificarFabricacion()
informarAnalisisPedido()
aceptarPedido()
Flujos de actividades
Mostrar flujo del proceso mediante diagramas de proceso
diagramas de actividades con calles que corresponden a roles
Una actividad puede necesitar ser descrita mediante otro diagrama de actividad: Objetivos y Subobjetivos. Pueden existir procesos de negocio que no requieran interaccin entre agentes.
Diagrama de Proceso Registrar pedido

: Cliente : Comercial :Catalogo Rellenar pedido p: Pedido [propuesto] :Plantilla de Fabricacion Cursar pedido p: Pedido [en_evaluacion] Analizar viabilidad : JefeTecnico
Demasiado compleja: Descomposicin Jerrquica
: JefeProduccion
p:Pedido [evaluado] Notificar rechazo de pedido [ NO ] Viable?
: Producto Especial
Fin KO p: Pedido [rechazado] Notificar aceptacin de pedido
[ SI ] :Plantilla de Fabricacion
Ordenar fabricacion
:Orden de Trabajo [pendiente]
p: Pedido [aceptado]
Planificar produccion
Fin OK
Reglas de Negocio
Reglas de restriccin
Especifican polticas o condiciones que restringen la estructura y comportamiento de las informaciones
Estmulo-Respuesta Restriccin de operacin Restriccin de estructura
Reglas de derivacin
Especifican polticas o condiciones para inferir nuevos hechos a partir de otros.
Glosario
... Objeto de Informacin: Pedido
Atributos Codigo de pedido Fecha de solicitud Fecha lmite de entrega Conjunto de {Producto} Cliente Importe total Estado Actual
...
Actividad: Ordenar fabricacion
Reglas de Estmulo-Respuesta Origen: Analizar viabilidad Reglas de Operacin
Agente: Jefe Tecnico Precondiciones: La fabricacion de todos los productos

pedidos es viable. Existe una plantilla de fabricacin para cada uno de dichos productos. Postcondiciones: Ha sido creada una orden de trabajo para cada producto, con estado pendiente, y ha sido enviada al jefe de produccin para su planificacin.
Reglas Estructurales, de Derivacin y Restricciones - El cdigo de pedido identificarExistencia el de unvocamente el pedido, y ser asignado automticamente por
sistema - La fecha de solicitud ser anterior a la fecha lmite de entrega. - Un pedido contendr al menos un producto; no existe lmite mximo de productos. - Un pedido siempre ser solicitado por uno y solamente un cliente. - El importe total ser calculado a partir del precio de cada producto pedido. Clase del Dominio : - por especificar -
Caso de Uso : - por especificar-
Actividad: Notificar aceptacion de pedido

Origen: Analizar viabilidad Agente: Comercial Precondiciones: La fabricacin de todos los productos
pedidos es viable.
Postcondiciones: Se ha comunicad al cliente la aceptacin de su pedido. El estado del pedido es aceptado. Caso de Uso : - por especificar-
Trazabilidad
...
Especificacin de las actividades

Contrato: nombre de la actividad realizada por los actores Origen: Actividad/es precedente/s Agente: Actor que realiza la actividad Precondicin: Estado previo a la realizacin de la actividad Postcondicin: Estado posterior a la realizacin de la actividad Caso de uso: Nombre del caso de uso que se corresponde con la actividad. Este campo no se rellenar hasta que no se identifiquen los casos de uso.
Especificacin de las informaciones

Nombre de la informacin Atributos: Listado de los atributos de la informacin Restricciones: Restricciones sobre los atributos de la informacin, referidas tanto al significado como al valor de los mismos. Clase: Nombre de la clase que modelar esta informacin. En principio no se indica nada, y slo se rellena este campo cuando la clase es identificada en el modelado conceptual.
Modelado de Requisitos
Objetivo: Se establecen los requisitos funcionales y no funcionales del sistema. A partir del modelo del negocio (si se hace) se construye el modelo de casos de uso y el modelo conceptual.
Tipos de Requisitos
Funcionales No Funcionales
Usabilidad Fiabilidad Rendimiento Adaptabilidad, Mantenimiento, Configurable Herramientas Inplementacin
Modelado de Requisitos
Extraer los casos de uso del sistema a partir de las actividades que aparecen en los diagramas de actividades. Establecer el modelo conceptual a partir de las informaciones incluidas en los diagramas de actividades. Agrupar casos de uso derivados de un diagrama de procesos en un diagrama de casos de uso
Modelo de Requisitos
De los diagramas de proceso...
rol
actor actividad
Caso de Uso
objeto
Clase del Dominio
Modelo de Requisitos
Se define un actor para cada rol del diagrama de proceso que interactua con el sistema: actor primario. Se crea un caso de uso por cada actividad que es soportada por el sistema: Un caso de uso produce un resultado de valor a un actor. Niveles de granularidad?
Tipos de casos de uso

Segn el nivel de detalle
Breve : Descripcin en unas pocas lneas Informal : Varios prrafos que cubren varios escenarios Expandido : Descripcin detallada con una plantilla
Segn la importancia
Primario, secundario u opcional
Segn el nivel de abstraccin

Esencial : Qu hace el sistema? Concreto : Se contemplan detalles de implementacin (GUI y tecnologa)
Introducir Pedido de Cliente Analizar Produccion Productos
Cliente Cursar Pedido Ordenar Fabricacion Productos
JefeTecnico
Aceptar Pedido de Cliente Comercial
Planificar Produccion
JefeProduccion
Denegar Pedido de Cliente
Diagrama de Casos de Uso Registrar Pedido
Descripcin de un caso de uso

Elegir una plantilla Asociar el caso de uso al contrato subyacente. Se descubren nuevos casos de uso al describir estos casos de uso extrados de las actividades. Uso limitado de relaciones include y extend
Plantilla Casos de Uso

Caso de uso: nombre del caso de uso Objetivo: descripcin informal de los objetivos del caso de uso Actores: actores que intervienen en el caso de uso: principales y secundarios Precondiciones: condiciones que deben cumplirse para que pueda realizarse el caso de uso Pasos: secuencia de pasos necesarios para que el caso de uso se desarrolle con xito. Debemos mostrar las interacciones de los actores y las acciones del sistema. Variaciones: variaciones en la secuencia de pasos. Extensiones: puntos de extensin del caso de uso. Cuestiones: cuestiones planteadas durante la especificacin del caso de uso
Plantilla de Casos de Uso

Caso de uso Descripcin Ordenar Fabricacion Crear rdenes de trabajo para cada producto solicitado en el pedido y enviarlas al jefe de produccin para dar comienzo a la planificacin de su fabricacin. Jefe Tcnico - El estado del pedido es evaluado, - Es viable la fabricacin de cada producto solicitado en el pedido, - Existe una plantilla de fabricacin para cada producto solicitado. - Ha sido creada una orden de trabajo para cada producto solicitado. - El estado de cada orden de trabajo es pendiente. - Cada orden de trabajo ha sido enviada al jefe de produccin 1. REPETIR 1.1. Obtener un producto del pedido. 1.2. Buscar la plantilla de fabricacin asociada al producto. 1.3. Crear la orden de trabajo. 1.4. Almacenar la orden de trabajo, con el estado pendiente. 1.5. Enviar la orden de trabajo al jefe de produccin. -
Actores Asunciones
Postcondiciones
Pasos
Variaciones Req No Funcionales Cuestiones
Trazabilidad
Plantilla usecases.org
Actor Principal Usuarios e Intereses Precondiciones Postcondiciones Escenario Principal (Flujo Bsico) Extensiones (Flujos Alternativos) Requisitos especiales Tecnologa y Lista Variaciones de datos Frecuencia Cuestiones abiertas
Identificacin de casos de uso (Larman)

Centrarse en casos de uso de negocio elementales: tarea realizada por una persona en cierto lugar en cierto instante, como respuesta a un evento del negocio que genera valor para el negocio y deja los datos en un estado consistente Procedimiento
Encontrar objetivos del usuario Definir un caso de uso para cada uno

Objetivos Estrtegicos
Ej.: Evitar prdidas
Objetivos de Usuario casos de uso

Ej.: Realizar Venta
Subfunciones casos de uso?

Ej.: Iniciar sesin (Login)

Establecer los lmites del sistema Identificar los actores principales
Es el cliente un actor en el sistema TPV?
Identificar sus objetivos de usuario

Posible uso de los eventos externos
Definir un caso de uso por objetivo de usuario

Excepcin: casos de uso para manejar informacin (crear, eliminar, modificar, consultar)
Formato expandido y esencial
Elaboracin de casos de uso (Larman)

Cundo?
Al principio de la iteracin en formato extendido y esencial, se refinan a lo largo de las iteraciones
Dnde?
En reuniones de captura de requisitos
Quin?
Usuarios finales, clientes, desarrolladores
Cmo? (Herramientas)
Herramientas de requisitos web-enabled integradas con un procesador de texto (texto cdu) y herramientas CASE UML (diagramas de cdu)
Documentos de Anlisis Requisitos

Casos de Uso Especificacin Complementaria
Captura otros requisitos
Glosario
Captura trminos y definiciones
Visin
Define visin del producto de los stakeholders, en trminos de sus necesidades y caractersticas
Especificacin Complementaria
Funcionalidad
Abarca varios casos de uso Ej. Almacenar informacin errores, Cualquier uso requiere autenticacin de usuario
Requisitos No Funcionales (Atributos de calidad)

Usabilidad, Mantenimiento, Adaptacin, Fiabilidad, Rendimiento Restricciones Implementacin (hardware, software, desarrollo) Componentes comprados y free open source Interfaces Reglas de Negocio (Ej. Reglas de descuento, Clculo impuestos) Cuestiones Legales Cuestiones sobre el entorno fsico y operacionales Informacin en dominios relacionados
Visin
Oportunidad Definicin del problema Alternativas Descripcin stakeholders Objetivos usuario Perspectiva del producto Beneficios del producto Lista de caractersticas del producto Coste y precio Otros requisitos y restricciones
Lista de Caractersticas del Sistema

Alguna funcionalidad no puede ser asignada a un caso de uso:
El sistema debe hacer transacciones con sistemas externos de inventario, contabilidad y clculo de impuestos
Para algunas aplicaciones conviene ms una lista de caractersticas que casos de uso
Ej. Servidor de aplicacin
Qu hacemos primero?
1. Escribir un borrador poco elaborado de la Visin en la Etapa Inicial 2. Identificar objetivos del usuario y casos de uso para ellos 3. Escribir casos de uso y comenzar Especificacin Complementaria 4. Refinar Visin
Elaboracin de Requisitos y Visin

Cundo?
Etapa Inicial, un poco Modelado de requisitos en cada iteracin
Dnde?
Inicio en reuniones de requisitos, se completa despus
Quin?
Analista de sistemas, Arquitecto Software, Usuarios
Cmo?
Herramientas de requisitos web-enabled integradas con un procesador de texto
Casos de uso e iteraciones

Asignar prioridad a casos de uso Escribir casos de uso en su forma expandida Asignar casos de uso a iteraciones. Varias versiones de un caso de uso complejo, para aadir complejidad de modo incremental. Necesidad de comunicacin con el usuario Al final un caso de uso esencial se transforma en su forma concreta.
Iteraciones
Dirigidas por el riesgo
Asociar a cada caso de uso un nivel de riesgo e importancia para el negocio
Comenzar pronto con la programacin Realizar pruebas Rpida retroalimentacin Se obtiene la arquitectura en las primeras iteraciones
Ejemplo: Terminal Punto de Venta

Realizar Venta
Cajero
Cliente
Registrar Productos
Casos de Uso
Gerente Inicia
Gestion Usuarios
Administrador Sistema
Caso de uso Realizar Venta

Resumen: Un cliente llega al TPV con un conjunto de artculos. El Cajero
registra los artculos y se genera un ticket. El cliente paga en efectivo y recoge los artculos.
Pasos:
1. A: El cliente llega al TPV con los artculos. 2. A: El cajero registra el identificador de cada artculo. 3. S: El sistema obtiene el precio de cada artculo y aade la informacin a la transaccin de venta. 4. A: Al acabar el cajero indica la finalizacin de la introduccin de artculos. 5. S: El sistema calcula el total de la compra y lo muestra. 6. A: El Cajero le dice al cliente el total. 7. A: El cliente realiza el pago.
Caso de uso Comprar productos

8. A: El cajero registra la cantidad de dinero recibida. 9. S: El sistema muestra la cantidad a retornar al cliente y genera un recibo. 10. A: El cajero deposita el dinero recibido y saca la cantidad a devolver que entrega al cliente junto al ticket de compra. 11. S: El sistema almacena la compra completada. 12. A: El cliente recoge los artculos comprados. Variaciones: Paso 2: Introducir identificador no vlido- Indicar error Paso 7: El cliente no tiene dinero suficiente. Cancelar transaccin
Extensiones:
10. Diferentes formas de pago: efectivo, tarjeta
Modelo Conceptual (o Dominio)

Representa el vocabulario del dominio: ideas, conceptos, objetos Conjunto de diagramas de clases No son modelos de elementos software Clases conceptuales Clases no incluyen operaciones, slo atributos Atributos: nmeros o texto Asociaciones entre clases
Identificar Clases Conceptuales

Si se hace modelado del negocio:
Los objetos informacin, entrada y salida de las actividades de los diagrama de proceso, representan entidades y conceptos del dominio.
Una clase conceptual para cada informacin relevante. De la especificacin del diccionario se extraen:
atributos, asociaciones, restricciones
Se refina a lo largo de las iteraciones Ms vale que sobren clases que falten
Modelo Conceptual: Ejemplo

Objeto informacin Pedido Atributos: codigo, fechaRecepcion, importe, estado, fechaTopeEntrega Asociaciones: Pedido-Cliente y Pedido-Producto Restricciones: {fechaTopeEntrega > fechaRecepcion} Tambin es posible identificar objetos que pasan por varios estados (diagrama de estados preliminar)

Si no se hace modelado del negocio:
Usar una lista de categoras de clases Identificar nombres de las frases
Categoras de clases
Objetos fsicos Especificaciones o descripciones de cosas Lugares Transacciones Lneas de una transaccin

Categoras de clases (continua)
Contenedores de cosas Cosas en un contenedor Dispositivos externos al sistema Conceptos abstractos Eventos Procesos Reglas y Polticas Catlogos Contratos, documentos legales Instrumentos y servicios financieros Manuales, documentos, trabajos, libros
Modelo Conceptual
Descrita por 1 0..1
Registra venta de
1 Catalogo Productos 1 Usado-por 0..n Contiene 1..n Describe 0..n Almacena 0..n 1 Item Producto
Lineas Venta cantidad 1..n Contenidas en 1 Venta 1 1 pagado por 1 Pago 1 iniciada por 1 Cliente capturada en 1 0..n
Tienda direccion nombre 1 1
1..n TPV 1 1 Registra Ventas 1 Cajero Iniciado por 1 Gerente
Producto Especial
Producto Catalogado
Catalogo
fabricado mediante Producto 1..* es solicitado en Plantilla de Produccion
base de 0..* genera 0..* Orden de Trabajo
0..* Pedido 1..* realizado por
Cliente
Modelo conceptual inicial
Identificar Asociaciones
Se incluyen aquellas:
para la que el conocimiento de la relacin deba mantenerse algn tiempo derivadas de la Lista de Asociaciones
Lista de Asociaciones
A es parte fsica de B A es parte lgica de B A est fsicamente contenida en B A est lgicamente contenida en B A es una descripcin de B
Lista de Asociaciones (continua)
A es una lnea de una transaccin o informe B A es conocido/registrado/informado/capturado en B A es miembro de B A es una subunidad organizacional de B A usa o maneja a B A comunica con B A est relacionado a una transaccin B A es el siguiente a B A es apropiado por B A es un evento relacionado con B
Encontrar clases conceptuales es ms importante que encontrar asociaciones. Se debe dedicar ms tiempo a encontrar clases conceptuales que asociaciones Centrarse en las asociaciones necesita-conocer Muchas asociaciones dificultan la comprensin de los diagramas Evitar asociaciones redundantes En la implementacin se notar que falta o sobra alguna asociacin
Asociaciones en TPV
A es parte fsica de B
TPV-Caja
A es parte lgica de B
LineaVenta-Venta
A est fsicamente contenida en B

Item-Tienda, TPV-Tienda
A est lgicamente contenida en B

EspecificacionProducto-CatalogoProductos
A es una descripcin de B
EspecificacionProducto-Item
Asociaciones en TPV
A es una lnea de una transaccin o informe B
LineaVenta-Venta
A es conocido/registrado/informado/capturado en B
Venta-TPV
A es miembro de B
Cajero-Tienda
A usa o maneja a B
Cajero-TPV, Gerente-TPV
A comunica con B
Cliente-Cajero
A est relacionado a una transaccin B

Cliente-Pago, Cajero-Pago
A es el siguiente a B
LineaVenta-LineaVenta
A es apropiado por B
TPV-Tienda
Atributos
Son valores de tipos de datos: Identidad no tiene sentido Tipos Primitivos: Boolean, Date, Numero, Time, String Tipos no primitivos: Direcciones, Colores, Nmero Tlfno, Nmero Seguridad Social, DNI, Cdigo de Producto Universal, Cdigo Postal,.. Tipos no primitivos se deben modelar como clases si:
Estn formados por varias partes Son aplicables operaciones Tiene otros atributos Es una cantidad con una unidad
No utilizar atributos como claves ajenas
Prototipo Inicial
Utilizar los casos de uso. Incluye las interfaces de usuario Sirve para validar los requisitos: analista y usuarios llegan a un acuerdo sobre la funcionalidad y vocabulario. Prototipo desechable Fcil de construir con herramientas visuales.
Modelo del anlisis

Objetivo:
A partir de los casos de uso obtener el diseo preliminar del sistema que deber ser refinado en el modelo del diseo. Nivel de abstraccin ms alto que en el diseo. Visin ideal del sistema. Se define una arquitectura del sistema.
Modelo del anlisis

Para cada caso de uso se define un diagrama de secuencia del sistema que muestra los eventos que un actor genera durante la interaccin con el sistema (caja negra) Cada evento da origen a una operacin del sistema El efecto de las operaciones se describen mediante contratos especificados mediante una plantilla.
Modelo del anlisis

Para cada operacin del sistema se define un diagrama de interaccin que muestra cmo deben colaborar los objetos para satisfacer las responsabilidades y postcondicin expresada en el contrato de dicha operacin. Disear las colaboraciones, asignando responsabilidades a las clases. Utilizaremos patrones GRASP y patrones de diseo.
Cajero
Realizar Venta
Cliente
:Sistema
: Cajero crearNuevaVenta * introducirItem(upc,cantidad) finalizarVenta() crearPago(cantidad)
Operacion Operacion Operacion
CONTRATOS
Diagrama de Secuencia del Sistema (Caso de Uso Realizar Venta)

: Cajero :Sistema crearNuevaVenta() introducirItem (CUP, cantidad) finalizarVenta () crearPago()
1. Cliente llega al TPV con item 2. Cajero inicia venta 3. Cajero introduce id item 4. Sistema registra lnea de venta y presenta parcial Cajero repite pasos 3 y 4 hasta que acaba 5. Sistema presenta total 6. Cajero requiere pago 7. ...
Operaciones del sistema
eventos del sistema
Contratos
Descripcin detallada del comportamiento del sistema en trminos de cambios de estado a los objetos en el Modelo Conceptual, tras la ejecucin de una operacin del sistema. Definicin basada en pre y postcondiciones Las postcondiciones indican
Creacin y Eliminacin de objetos Creacin o Eliminacin de asociaciones Modificacin de atributos
Contratos
Las postcondiciones sern completas y se descubrirn detalles en el diseo. Las postcondiciones nos obligarn a modificar el modelo conceptual Son redundantes los contratos con los casos de uso?
Contratos
tiles cuando hay mucha complejidad y la precisin es un valor aadido Normalmente no son necesarios, si un equipo escribe un contrato para cada caso de uso es una seal de unos casos de uso muy pobres o falta de colaboracin con los expertos o que les gusta escribir documentacin innecesaria En la prctica la mayora de detalles se pueden inferir de los casos de uso de modo obvio, aunque obvio es un concepto muy resbaladizo.
Contratos
1. Identificar operaciones del sistema 2. Para operaciones complejas y quiz sutiles en sus resultados, o que no estn claras en el caso de uso, construir un contrato 3. Describir postcondiciones
Creacin/Eliminacin de instancias Creacin/Eliminacin de asociaciones Modificacin de atributos
No olvidar crear asociaciones! Se puede usar OCL
Plantilla de un Contrato de Operacin

Nombre: signatura de la operacin Responsabilidades: qu debe hacer la operacin Tipo: clase controlador que realiza la operacin Caso de uso: nombre del caso de uso al que pertenece la operacin Notas: requisitos no funcionales Excepciones: casos excepcionales que debe detectar Salidas: salidas fuera del sistema, sin tener en cuenta las salidas por pantalla Precondiciones: condiciones que han de cumplirse para realizar la operacin Postcondiciones: estado del sistema despus de realizar la operacin
Contrato IntroducirItem
Nombre: introducirItem (itemID: itemID, cantidad: integer) Responsabilidades: Registrar la venta de un producto y agregarlo a la venta. Desplegar la descripcin del producto y su precio. Tipo: Sistema Notas: Acceso rpido a la base de datos Excepciones: Si CUP no vlido, indicar error. Precondiciones: El sistema conoce itemID Postcondiciones: - Si era una nueva venta, un objeto Venta se cre y se asoci al objeto TPV. - Se cre una instancia lv de LineasVenta y se asoci a la venta. - Se asign cantidad a lv.cantidad - lv se asoci a una EspecificacinProducto segn itemID
Diagramas de Interaccin
Crear estos diagramas es una actividad de AOO/DOO muy creativo. Diseo de colaboraciones es la parte ms difcil. Punto de partida para la programacin. Crear diagramas en parejas. Crear diagrama de clases en paralelo
2: [nuev venta] crear() 1: IntroducirProducto(cup, cant) GUI : TPV 6: AddLineaVenta(esp, cant) : Venta
4: esp:= especificacion(cup) 3: crear() 8: add(lv)
7: crear(esp,cant)
: Catalogo Productos
5: esp:= find(cup) : Lineas Venta
lv : Lineas Venta
: Producto
Diagrama de clases
1) Se refina el modelo conceptual inicial que se convierte en un modelo de clases del anlisis. 2) Se extrae comportamiento de las clases a partir de los diagramas de interaccin. 3) Refinar los diagramas de interaccin de modo que nuevos objetos participarn en la interaccin. 4) Refinar el diagrama de clases.
Modelo del anlisis

Definir los subsistemas Para aquellas clases con muchos estados y transiciones entre estados, construir un diagrama de estados.
Patrones GRASP
Describen los principios bsicos de asignacin de responsabilidades a clases. Distribuir responsabilidades en la parte ms difcil del diseo OO. Consume la mayor parte del tiempo. Patrones GRASP: Experto, Creador, Bajo Acoplamiento, Alta Cohesin, Controlador, Polimorfismo, No hables con extraos
Responsabilidades
Contrato u obligacin de una clase. Dos categoras:
Conocer
datos encapsulados privados existencia de objetos conectados datos derivados o calculados
Hacer
Algo a uno mismo Iniciar una accin en otros objetos Controlar y coordinar actividades en otros objetos
Responsabilidades
Responsabilidades hacer se pueden inferir de las asociaciones y atributos del modelo conceptual. Puede asignarse a varias clases y mtodos dependiendo de su granularidad. Diagramas de interaccin muestran elecciones en la asignacin de responsabilidades.
Experto
Cmo se asignan responsabilidades? Asignar una responsabilidad a la clase que tiene la informacin necesaria para cumplimentarla Heursticas relacionadas
Distribuir responsabilidades de forma homognea No crear clases dios
Beneficios
Se conserva encapsulacin: Bajo acoplamiento Alta Cohesin
Ejemplo 1
Quin es el responsable de conocer el total de una venta?
Venta fecha nota contiene 1..1 1..* Descrita por LineaVenta cantidad
0..* Producto descripcion precio codigo
Ejemplo 1
Quin es el responsable de conocer el total de una venta?
: Venta : LineaVenta : Producto
total
subtotal
precio
Ejemplo 2
: LectorCorreo :Buzon : Carpeta :Mensaje MensajesEntre(f1,f2)
mensajesEntre(f1,f2)
esFecha(f1,f2)
Creador
Quin es responsable de crear una instancia de una cierta clase? Asignar a la clase B la responsabilidad de crear instancias de una clase A si:
B es una agregacin de objetos de A B contiene objetos de A B registra instancias de A B utiliza hace un uso especfico de los objetos de A B proporciona los datos de inicializacin necesarios para crear un objeto de A
Creador
Quin debera crear una instancia de la clase LineaVenta?
Una instancia de la clase Venta es una agregacin de instancias de la clase LineaVenta
Beneficios:
Bajo acoplamiento
Bajo Acoplamiento
Cmo reducir las dependencias entre clases? Asignar responsabilidad de modo que se consiga un bajo acoplamiento Es un patrn evaluativo No considerarlo de forma independiente, sino junto a los patrones Experto y Alta Cohesin. Beneficios: Facilita i) reutilizacin, ii) comprensin de las clases y iii) mantenimiento
Tipos de dependencias
Existe acoplamiento entre una clase A y otra B si:
i) A posee un atributo de tipo B ii) A tiene un mtodo con un parmetro, una variable local o devuelve un valor de tipo B iii) A es subclase directa o indirecta de B iv) A implementa la interfaz B (Java)
Ejemplo
:Aplicacion efectuarPago : TPV crear agregarPago : Pago :Venta
Ejemplo
:Aplicacion efectuarPago : TPV : Pago :Venta
efectuarPago crear
Alta Cohesin
Canto estn de relacionadas las responsabilidades de una clase? Asignar una responsabilidad de modo que la cohesin siga siendo alta Baja Cohesin: Clases con responsabilidades que deberan haber delegado. Son clases dios. Difciles de comprender, reutilizar, mantener. Ejemplo anterior: En el primer caso TPV tendra muchas operaciones, mejor delegar.
Alta Cohesin
Muy baja cohesin:
Clase AccesoBD-RPC Mezcla de funcionalidad
Baja cohesin:
Clase AccesoBD Muchos mtodos
Alta cohesin:
Clase AccesoBD + Familia de clases relacionada
Cohesin moderada:
Clase Empresa: conoce empleados e informacin financiera
Alta Cohesin
Beneficios
Mejora reutilizacin Clases ms claras, se comprenden mejor Mejora mantenimiento
Controlador
Quin se encarga de atender los eventos del sistema Asignar responsabilidad de manejar eventos externos a un controlador: i) el sistema global ii) la organizacin iii) agente que interviene en la tarea iv) un manejador de todos los eventos de un caso de uso La misma clase controlador para todos los eventos de un mismo caso de uso.
Controlador
Las clases de la interfaz no deben encargarse de realizar las tareas asociadas a un evento. Deben delegarlas a un controlador. Separar interfaz de la lgica de aplicacin. Las operaciones del sistema en la capa del dominio. Cundo debemos escoger un controlador de caso de uso?
Cuando con las otras alternativas obtenemos controladores saturados Es posible llevar el estado del proceso actual
Ejemplo controlador
:AppletTPV :TPV :Venta
introProd
introProducto(cant,cod)
crearLineaProd(cant,cod)
evento Acoplamiento adecuado de la capa presentacin con la capa del dominio
Ejemplo
:AppletTPV :Venta
introProd
crearLineProd(cant,cod)
evento Acoplamiento inadecuado de la capa presentacin con la capa del dominio
Controlador
Evento Introducir producto i) TPV, ii) Tienda, iii) Cajero, iv) Manejador Compra Beneficios:
Favorece la reutilizacin Posibilidad de capturar informacin sobre el estado del proceso
Polimorfismo
No realizar anlisis de casos de uso basado en el tipo de los objetos.
if tipoPago = Cheque then autorizarPagoCheque else if tipoPago = Efectivo then autorizarPagoEfectivo else if tipoPago = Tarjeta then autorizarPagoTarjeta else if
Sustituir anlisis de casos de uso por jerarqua de herencia.
No hables con extraos

No enviar mensajes sobre objetos indirectos, sino sobre instancia actual (self), parmetros de mtodos, atributos de la instancia actual y elementos de colecciones de la instancia actual.
class A { B at1; void met1(..) { obj = at1.getAt2; obj.met2;} } class B { C at2; C getAt2 {return at2;} }
No hables con extraos

class A { B at1; void met1(..) { at1.met3;} } class C { void met2 {..} } class B { C at2; C getAt2 {return at2;} void met3 {at2.met2;} }
Modelo del diseo

Objetivo:
Refinar el diseo del sistema del modelo del anlisis introduciendo los requisitos no funcionales y restricciones del entorno de implementacin. De manera iterativa se refina el diagrama de clase del anlisis hasta obtener un diseo del sistema adecuado para pasar a la implementacin:
nuevas clases, atributos, operaciones mtodos interfaces visibilidad, dependencia, navegabilidad
Cuestiones del diseo

Definicin de la arquitectura del sistema Subsistemas: Paquetes Patrones de diseo Estructuras de datos Diseo del interfaz de usuario Manejo de la persistencia Distribucin
Niveles en un sistema de informacin

Presentacin: GUI Lgica de Aplicacin:
Clases del dominio del problema Clases servicio (acceso a BD, seguridad, ..)
Almacenamiento
VISTA-DATOS VS. VISTA-MODELO-DATOS

ARQUITECTURA VISTA-DATOS
Interfaz de usuario y la lgica de acceso a los datos son las partes esenciales de la aplicacin
Aplicaciones aplicacin. pasivas con poca lgica de
No se crean clases para el modelo. Se pierden los beneficios de la OO
VISTA-DATOS VS. VISTA-MODELO-DATOS

ARQUITECTURA VISTA-MODELO-DATOS
La lgica del modelo es dominante sobre la lgica del acceso a los datos. Se realiza un anlisis y diseo OO completo Se crean clases para el modelo Separacin del modelo de la vista Se favorece la reutilizacin y extensibilidad
Validacin del sistema

Utilizar los casos de uso. Para cada caso de uso comprobar que el sistema muestra el comportamiento esperado, considerando el escenario principal y los excepcionales o alternativos. Considerar requisitos no funcionales.
Cmo encontrar las clases?

Un mtodo puede ofrecer buenas ideas, sugerir centrar la atencin en algunos aspectos y sealar fuentes de error. No hay libro que sustituya la experiencia. Reuso de clases permite incorporar el diseo de otros.
Heursticas para encontrar clases

Tres categoras de clases:
i) Anlisis
Representan abstracciones del dominio de la aplicacin: Cuenta, Libro, Automovil, Parrafo,..
ii) Implementacin
Describen abstracciones de datos necesarias para los algoritmos en la implementacin Array, Lista, Pila,...
Heursticas para encontrar clases

ii) Diseo
Fruto de decisiones relacionadas con la arquitectura del software. Pertenecen al espacio de la solucin, pero describen conceptos de alto nivel. Las ms difciles de encontrar.
Estado, Comando, Iterador, Window...
El mtodo para encontrar clases

I) Fuentes de posibles clases
Fuentes de ideas y qu buscar
II) Razones para rechazar una clase

Seales de peligro y el porqu sospechar
Fuentes de ideas (I)

Libreras existentes
Clases que tratan necesidades del problema Clases que describen conceptos relevantes al sistema
Documento de requisitos
Trminos que aparecen frecuentemente Trminos para los que aparecen definiciones explcitas Trminos que se suponen bien conocidos, aunque no se definan No considerar categoras gramaticales
Fuentes de ideas (II)

Discusin con clientes y futuros usuarios
Abstracciones importantes del dominio Jerga del dominio Tener presente que las clases del anlisis pueden representar objetos de diversa naturaleza
Documentacin para otros sistemas en el mismo dominio

Abstracciones importantes del dominio Jerga del dominio Abstracciones de diseo tiles
Fuentes de ideas (III)

Sistemas no OO
Datos que fluyen como argumentos Ficheros importantes Registros en Pascal, C Entidades del modelo ER
Discusiones con diseadores expertos

Clases de diseo que se han probado tiles
Libros sobre algoritmos y estructuras de datos Libros sobre diseo OO (patrones)
Razones para el rechazo (I)

Clases con nombre verbal
Puede ser una rutina, no una clase
Clases totalmente efectivas con una sola rutina exportada

Puede ser una rutina, no una clase
Clases que se describen como una tarea

Pueden no ser una abstraccin de datos
Clases sin mtodos para modificar estado

Pueden no ser una abstraccin de datos, o que las rutinas deben ser aadidas.
Razones para el rechazo (II)

Clases que introducen muy pocas propiedades (pero heredan de otra clase)
Puede ser un uso excesivo de la herencia (taxomania)
Clases que cubren varias abstracciones

Deberan dividirse en varias clases

OOsistemasII ClasesTeoricas

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OOsistemasII ClasesTeoricas

Uploaded by

Copyright:

Available Formats

El Paradigma Orientado a Objeto

UCSE FMA - Sistemas de Informacin II

Por qu la Orientacin a Objetos?

UCSE FMA - Sistemas de Informacin II

Por qu la Orientacin a Objetos?

cmo Sin embargo, existen problemas ...

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

Las aplicaciones de gestin estn constituidas mayoritariamente por objetos degenerados

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

Felipe Cuenta Corriente 114

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

2: Mensaje C 4: Mensaje E Objeto 3 3: Mensaje D Objeto 4

UCSE FMA - Sistemas de Informacin II

Clasificacin / Instanciacin Composicin / Descomposicin Agrupacin / Individualizacin Especializacin / Generalizacin

La clasificacin es uno de los mecanismos de abstraccin ms utilizados

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

Clases: Notacin Grfica

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

Relaciones entre Clases

Asociacin y Agregacin (vista como un caso particular de asociacin) Generalizacin/Especializacin

UCSE FMA - Sistemas de Informacin II

Universidad Una asociacin

UCSE FMA - Sistemas de Informacin II

Persona nombre s.s.

Compaa trabaja-para nombre direccin *

UCSE FMA - Sistemas de Informacin II

La multiplicidad mnima >= 1 establece una restriccin de existencia

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

Clasificacin Mltiple (herencia mltiple)

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

Dormir() { sobrela espalda }

Diagrama de Casos de Uso

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

UCSE FMA - Sistemas de Informacin II

Casos de Uso: Relaciones

UCSE FMA - Sistemas de Informacin II

Casos de Uso: Relaciones

Caso de Uso Origen