Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Contenido
Por qu Modelizar? El Paradigma Orientado a Objetos Introduccion UML Captura de Requisitos Modelado de Interacciones Modelado de la Estructura del Sistema Diagramas de Estados Modelado de Componentes Modelado de Distribucin Hacia un proceso de Desarrollo usando UML RUP Proceso Desarrollo Unificado Conclusiones
Mtodos
Mtodo
Establece cmo abordar de un sistemtico la construccin de software.
modo
Mtodo
Importante conocer las limitaciones y beneficios
de los mtodos. Los mtodos pueden ayudar pero no aseguran el xito. Un mtodo ofrece guas mediante ejemplos de aplicacin. Un mtodo es fruto de la experiencia en proyectos. No sustituye a la necesidad creativa
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 de 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
Un proceso debe ser iterativo e incremental.
Conviene centrarse en los aspectos crticos en las primeras iteraciones para minimizar riesgos.
Un mtodo debera describir procesos por
envo
MODELO DE LA INFORMACION
Sistema de informacion BIBLIOTECA
Registrar prestmo
Libro Biblioteca
Reportar Multas
Agregar recursos
A/D estructurados
DESARROLLO SW
TECNOLOGIA
(OO, UML, Rational Rose)
ORGANIZACION
PROCESO
(RUP)
Por qu modelar?
Proporcionar la estructura para la resolucin
de los problemas Experimentar diversas soluciones Reducir el tiempo de venta Disminuir los costes de desarrollo Gestionar el riesgo de cometer errores
Por qu modelamos?
Una empresa software con xito es aquella que produce de manera consistente software de calidad que satisface las necesidades de los usuarios
El modelado es la parte central de todas las actividades que conducen a la produccin de software de calidad
Por qu modelamos?
Un modelo es una simplificacin de la realidad
Construimos modelos para comprender mejor el sistema que estamos modelando Cuatro utilidades de los modelos: Visualizar cmo es o queremos que sea el sistema
Especificar la estructura y comportamiento del sistem Proporcionan plantillas que guan la construccin del sistema Documentan las decisiones Validar el software
al existir un lenguaje comn. Se dispone de documentacin que trasciende al proyecto. Hay estructuras que trascienden lo representable en un lenguaje de programacin.
MV promueve la reutilizacin
Multiples Sistemas
Componentes Reutilizados
reutilizacin
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
Introduccin a UML
UML y el modelado
UML es un lenguaje para visualizar, especificar, construir y documentar los artefactos de un sistema que involucra una gran cantidad de software, desde una perspectiva OO.
Qu es UML?
Objetivos de UML
Ser un lenguaje estndar 1997 OMG (Object
Management Group) version 1.1
Definir un lenguaje visual de modelado fcil de aprender y a la vez rico semnticamente. Unificar los mtodos Booch, Objetory y OMT Incluir ideas de otros sistemas de modelado Incorporar la experiencias prcticas Responder a las necesidades actuales de los desarrollos de software. Vlido para diferentes procesos de desarrollo
Historia de UML
Comenz como el Mtodo Unificado, con la participacin de Grady Booch y Jim Rumbaugh. Se present en 1995. El mismo ao se uni Ivar Jacobson. Los Tres Amigos son socios en la compaa Rational Software. Herramienta CASE Rational Rose.
Historia de UML
2001 ? UML 2.0
2000 ?
1999 1998 Nov 97
UML aprobado por el OMG
UML 1.2
MCI Systemhouse (Grady Booch, Jim Rumbaugh y Ivar Microsoft Jacobson) ObjecTime Digital Equipment Oracle Hewlett-Packard Platinium Technology i-Logix (David Harel) Sterling Software IBM Taskon ICON Computing (Desmond DSouza) Texas Instruments Intellicorp and James Martin Unisys
Jacobson Meyer
Pre- and Post-conditions
UML
State Charts
Harel
Embly
Singleton classes
Wirfs-Brock Fusin
Responsabilities Operation descriptions, message numbering
Inconvenientes en UML?
Definicin del proceso de desarrollo usando UML. UML no es una metodologa
Falta integracin con respecto de otras tcnicas tales como patrones de diseo, interfaces de usuario, documentacin, etc. Ejemplos aislados
Perspectivas de UML
UML ser el lenguaje de modelizacin de objetos
Evidencias: Herramientas que proveen la notacin UML Edicin de libros Congresos, cursos, camisetas, etc.
Uso de UML
El objetivo de UML es describir cualquier tipo de sistema en trminos de diagramas orientados a
objetos Algunas categoras de Sistemas Sistemas de Informacin Sistemas de Tiempo Real Sistemas Embebidos Sistemas Distribuidos Software de Sistemas Sistemas de Negocios
Comercio
Diagrama de Clases
import
Politicas + ReglasPedidos + GUI:Ventana
import
Paquetes
Diagrama de Secuencia
:Interface Entrada Pedido preparar *preparar hayStock:=comprobar [hayStock] eliminar pedir?:=necesarioPedir [pedir?]<<create>> :Pedido :LineaDe Pedido :Item
PedidoItem ItemEntregado
[hayStock] <<create>>
Diagrama de Colaboracin
1: preparar :Interface Entrada Pedido :Pedido 2: *preparar :LineaDe Pedido
:Item
6: [pedir?]<<create>>
Diagrama de Estados
introducirProducto
Espera Venta
introducirProducto
Introduccion Productos
Diagrama de Actividades
Solicitar Producto
Procesar Pedido
Extraer Artculos
Enviar Pedido
Recibir Producto
Facturar al cliente
Pagar Factura
Cerrar Pedido
Componentes
explorador.java
JerarquaElementos
arbol.java
internet
Modem <<procesador>> servidor cache
<<procesador> servidor
<<procesador>> servidor
<<procesador>> servidor
Diagrama de Despliegue
Modelado de Requisitos
Diagramas de casos de uso
Modelado Estructural
Diagramas de clases Diagramas de objetos
Modelado Arquitectnico
Diagramas de componentes Diagramas de despliegue Paquetes
Modelo
Diagramas de Actividad
Distribucin
Metodologa desarrollo
Una metodologa de desarrollo de software OO consta de los siguientes elementos:
Diagramas y conceptos ( Modelado) Etapas y definicin de entrega en cada una de ellas. Actividades y recomendaciones.
Diseo
Diseo detallado
Anlisis de requerimientos
Actividades tcnicas 1. Identificar Casos de Uso del sistema 2. Dar detalle a los casos de uso descritos 3. Definir una interfaz inicial del sistema (si es aplicable) 4. Desarrollar el modelo del mundo 5. Validar los modelos
Documentos Entregables Diagrama actividades,Casos de uso iniciales ,borradores de interfaz, Modelo del mundo inicial (D.Clases)
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?
negocio segn los objetivos de la organizacin ( diagrama actividades) Definir un caso de uso del negocio para cada proceso del negocio, utilizando un diagrama de casos de uso del negocio para mostrar el contexto y los lmites de la organizacin bajo estudio.
Ejemplo
Empresa que fabrica productos bajo demanda
Objetivos Estratgicos Satisfacer pedido de cliente Subobjetivos Procesos del Negocio Incrementar las ventas un 25% Reducir tiempo de fabricacin un 15% ...
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.
: JefeProduccion
: Producto Especial
[ SI ] :Plantilla de Fabricacion
Ordenar fabricacion
p: Pedido [aceptado]
Planificar produccion
Fin OK
Rol Externo
Roles Internos
Fabricar producto
Gestionar almacen
Proveedor
darCursoPedido()
estudiarPedido() * analizarFabricacionProducto()
planificarFabricacion()
informarAnalisisPedido()
aceptarPedido()
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
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 -
Reglas Estructurales, de Derivacin y Restricciones - El cdigo de pedido identificarExistencia el de unvocamente el pedido, y ser asignado automticamente por
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. Caso de Uso : - por especificar-
Reglas de Operacin
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
...
Modelo de requisitos
Anlisis de requerimientos
Objetivo:
Se establecen los requisitos funcionales y no funcionales del sistema.
A partir del modelo del negocio se construye el modelo de casos de uso y el modelo conceptual inicial.
Modelo de requisitos
Anlisis de requerimientos
De un modo muy simple e intuitivo se obtienen
Modelo de requisitos
Anlisis de requerimientos
Se define un actor para cada rol del diagrama de proceso que interacta 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? Posibilidad de establecer jerarquas de casos de uso (jerarquas de actividades)
Modelo de requisitos
Anlisis de requerimientos
De los diagramas de proceso...
rol
actividad actor
Caso de Uso
No siempre
objeto
Clase del Dominio
Modelo de requisitos
Anlisis de requerimientos
Definicin de un CASO de USO
Un caso de uso especifica el comportamiento deseado del sistema. Representan los requisitos funcionales del sistema.
Un caso de uso especifica una secuencia de acciones, incluyendo variantes, que el sistema puede ejecutar y que produce un resultado observable de valor para un particular actor
Casos de Usos
Caso de uso Documento narativo de un proceso de un dominio del problema
Proceso Describe de comienzo a fin una secuencia de eventos para producir u obtener algo
Casos de Usos
Formato Caso uso: Nombre Actores: Lista actores Propsito: Intencin caso uso Resumen: Repeticin caso uso Tipo: 1. Primario, secundario u opcional 2. de alto nvel Esencial o real Referencias cruzadas: Casos relacionados usos y funciones
Segn la importancia
Primario, secundario u opcional
CASOS DE USOS
EJEMPLO Caso Uso: Comprar productos Actores: Cliente, Cajero Propsito: Capturar una venta y su pago Resumen: Un cliente llega a la caja con los productos que desea comprar. El cajero registra los productos y recibe el pago. Al terminar la transaccin, el cliente se marcha con el producto Tipo: Primario y esencial Referencias cruzadas R1.1, R1.2 y R1.3
Herencia
Extend
Procesar Prstamo
ResponsablePrestamos
asociacion
80
Ejemplo
extend
Hacer Pedido
(establecer prioridad)
Relacin de extensin
include
Relacin de inclusin
Comprobar clave
Validar Usuario
Generalizacin
Seguir Pedido
include
Examinar retina
JefeTecnico
Planificar Produccion
JefeProduccion
Varias versiones de un caso de uso complejo, para aadir complejidad de modo incremental.
Un caso de uso se va refinado en cada iteracin.
Modelo de requisitos
Anlisis de requerimientos
Modelo conceptual Los objetos informacin entrada y salida de las actividades representan entidades y conceptos del dominio. Se utilizan para crear un modelo conceptual inicial. Una clase para cada informacin que vaya a ser tratada por el sistema software. De la especificacin del diccionario se extraen:
atributos, asociaciones, responsabilidades, restricciones
Modelo de requisitos
Anlisis de requerimientos Objeto informacin Pedido Atributos: codigo, fechaRecepcion, importe, estado, fechaTopeEntrega Asociaciones: Pedido-Cliente y Pedido-Producto Restricciones: {fechaTopeEntrega > fechaRecepcion} Responsabilidades: obtenerProductos, cambiarEstado, calcularImporteTotal, calcularFechaTopeEntrega
Con el conjunto de objetos se crea el modelo conceptual
Producto Especial
Producto Catalogado
Catalogo
Cliente
Modelo Conceptual
En el diccionario de informaciones se establece una conexin entre clase y la informacin que representa. No preocuparse en las relaciones entre clases.
Algunos clases pueden representar roles. Es posible identificar del diagrama de procesos
Modelo de requisitos
Anlisis de requerimientos
Prototipo Inicial
Utilizar los casos de uso.
Incluye las interfaces de usuario
llegan a un acuerdo sobre la funcionalidad y vocabulario. Prototipo desechable Fcil de construir con herramientas visuales.
anterior (casos de uso esenciales pasarlos a expandidos y a : primarios secundarios o opcionales ) Crear los diagramas de casos de usos
Cajero
Comprar Articulos
Cliente
:Sistema
Requisitos no funcionales
Un sistema debe poseer caractersticas que no estn especficamente relacionadas con la funcionalidad del sistema.
Utilizacin del sistema
facilidad de uso, facilidad de aprendizaje, consistencia de la interfaz de usuario, documentacin del usuario
Cajero
Cliente
Registrar Productos
Casos de Uso
Gerente Inicia
Gestion Usuarios
Administrador Sistema
Modelo Conceptual
Descrita por
Registra venta de
1 Catalogo Productos 1 0..1 Tienda direccion nombre 1 Almacena 0..n Contiene 1..n Describe 0..n 1 Item Lineas Venta cantidad 1..n Contenidas en 1 Venta 1 1 pagado por 1 Pago 1 iniciada por 1 Cliente capturada en 1 1 Registra Ventas 1 Cajero TPV 1 Iniciado por 1 Gerente 0..n Producto
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.
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
Cajero
Comprar Articulos
Cliente
:Sistema
: Cajero
introducirItem(upc,cantidad)
finalizarVenta() hacerPago(cantidad)
CONTRATOS
:Sistema
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, es la actividad ms difcil del diseo orientado a objetos. Utilizaremos patrones de diseo.
Diagrama de Colaboracin
2: [nuev venta] crear() 1: IntroducirProducto(cup, cant) GUI : TPV 6: AddLineaVenta(esp, cant) : Venta
7: crear(esp,cant)
: Catalogo Productos
lv : Lineas Venta
: Producto
Diagramas de Interaccin
Para cada actor especificamos todas sus interacciones con el sistema mediante este tipo de diagrama. Se define un entorno de trabajo para cada usuario.
Facilita la construccin de un prototipo de validacin.
Subsistemas: Paquetes
Patrones de diseo Estructuras de datos