Taller de Proyectos Software
Taller de Proyectos Software
Taller de Proyectos Software
Introducción
Modelo del Negocio
Modelo de Requisitos
Modelo de Análisis
Método
MÉTODO
TECNOLOGIA
(OO, UML)
ORGANIZACION PROCESO
(UTA) (Rational Unified Process: RUP)
TECNOLOGÍA
Conceptos
Orientación a objetos
Diseño estructurado
Notación
Especificaciones formales
Plantillas
Diagramas
PROCESO SOFTWARE
G. Booch
PROCESO SOFTWARE
Inicio
Comprender procesos del negocio.
Obtener y especificar requisitos del sistema.
Identificar y especificar clases y colaboraciones
para objetos del dominio (análisis).
Resolver problemas de diseño (arquitectura, base
de datos, redes, patrones, nuevas clases y
colaboraciones,..).
Implementación.
Validación.
ETAPAS DEL PROCESO
Situación Actual
Modelado del Negocio
Modelado de Requisitos
Implementación
Validación
ETAPA INICIAL (1)
Ejemplos:
Sistema de tutoría WEB.
Objetivos
Estratégicos
Satisfacer pedido Incrementar las Reducir tiempo de
...
de cliente ventas un 25% fabricación un 15%
Subobjetivos
Procesos del
Negocio Registrar Fabricar Gestionar Realizar
pedido de productos almacén de pedidos a
cliente pedidos materiales proveedores
Casos de Uso
del Negocio
Generar
Registrar Fabricar Gestionar pedidos a
pedido productos almacén proveedor
ETAPAS DEL MODELADO DEL NEGOCIO
<<initiator>>
Registrar pedido
Cliente
Fabricar producto
Gestionar almacén
Textual
Visual
Diagrama de Roles:
aspecto estructural de colaboración entre roles
Escenario:
aspecto de comportamiento de la colaboración
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.
<<role>> <<role>>
Cliente Comercial
*
*
<<role>> <<role>>
Jefe Tecnico. Jefe Producción
Escenario “Registrar Pedido”
darCursoPedido()
estudiarPedido()
* analizarFabricacionProducto()
planificarFabricacion()
informarAnalisisPedido()
aceptarPedido()
FLUJOS DE ACTIVIDADES
:Catalogo
p: Pedido
Rellenar pedido [propuesto]
:Plantilla de
Fabricacion
Cursar pedido p: Pedido
[en_evaluacion]
Analizar viabilidad
p:Pedido
[evaluado]
: Producto
Especial
Notificar rechazo [ NO ] ¿Viable?
de pedido
[ SI ]
Fin KO
:Plantilla de
p: Pedido Fabricacion
[rechazado]
Planificar produccion
p: Pedido
[aceptado]
Fin OK
DIAGRAMA DE PROCESO “REGISTRAR PEDIDO”
Demasiado compleja:
: Cliente : Comercial : JefeTecnico : JefeProduccion
:Catalogo
Rellenar pedido
p: Pedido
[propuesto] Descomposición
:Plantilla de
Fabricacion Jerárquica
Cursar pedido p: Pedido
[en_evaluacion]
Analizar viabilidad
p:Pedido
[evaluado]
: Producto
Especial
Notificar rechazo [ NO ] ¿Viable?
de pedido
[ SI ]
Fin KO
:Plantilla de
p: Pedido Fabricacion
[rechazado]
Planificar produccion
p: Pedido
[aceptado]
Fin OK
REGLAS DEL NEGOCIO
Reglas de restricción
Especifican políticas o condiciones que restringen la
estructura y comportamiento de las informaciones
Estímulo-Respuesta
Restricción de operación
Restricción de estructura
Reglas de derivación
Especifican políticas o condiciones para inferir nuevos
hechos a partir de otros.
GLOSARIO
... ...
Objeto de Información: Pedido Actividad: Ordenar fabricacion
…
...
GLOSARIO
... ...
Objeto de Información: Pedido Actividad: Ordenar fabricacion Reglas de
Atributos
Estímulo-Respuesta
Origen: Analizar viabilidad
Código de pedido Agente: Jefe Técnico
Fecha de solicitud Precondiciones: La fabricación de todos los productos
Fecha límite de entrega pedidos es viable. Existe una plantilla de fabricación para
Conjunto de {Producto}
Cliente Reglas
cada uno de dichos productos. Reglas de
Postcondiciones: Ha sido creada una orden de trabajo para
Importe total
Estructurales, Operación
cada producto, con estado pendiente, y ha sido enviada al
Estado Actual jefe de producción para su planificación.
de
- El código de pedido identificará Existencia
unívocamente el
pedido, y será asignado automáticamente por el
sistema Actividad: Notificar aceptacion de pedido
- La fecha de solicitud será anterior a la fecha límite de
entrega.
Origen: Analizar viabilidad
- Un pedido contendrá al menos un producto; no existe
Agente: Comercial
límite máximo de productos.
Precondiciones: La fabricación de todos los productos
- Un pedido siempre será solicitado por uno y pedidos es viable.
solamente un cliente. Postcondiciones: Se ha comunicad al cliente la aceptación
- El importe total será calculado a partir del precio de de su pedido. El estado del pedido es aceptado.
cada producto pedido.
Caso de Uso : - por especificar-
Clase del Dominio : - por especificar -
…
...
ESPECIFICACIÓN DE LAS ACTIVIDADES
Nombre de la información
Atributos: Listado de los atributos de la información
Restricciones: Restricciones sobre los atributos de la
información, referidas tanto al significado como al valor
de los mismos.
Clase: Nombre de la clase que modelará esta información.
En principio no se indica nada, y sólo 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.
Funcionales
No Funcionales
Usabilidad
Fiabilidad
Rendimiento
Adaptabilidad, Mantenimiento, Configurable
Implementación: lenguajes, herramientas,..
GUI
Legales
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
rol
actor
actividad Caso de Uso
Cliente
JefeTecnico
Comercial
Actor Principal
Personas involucradas e Intereses
Precondiciones
Postcondiciones
Escenario Principal (Flujo Básico)
Extensiones (Flujos Alternativos)
Requisitos especiales
Tecnología y Lista Variaciones de datos
Frecuencia
Cuestiones abiertas
CASO DE USO “ORDENAR FABRICACIÓN”
Realizar Venta
Cajero Cliente
Registrar Productos
Casos de Uso
Inicia
Gerente
Gestión Usuarios
Administrador
Sistema
CASO DE USO “REALIZAR VENTA”
Flujo Básico:
1. A: El cliente llega al TPV con los artículos.
2. A: El cajero inicia una nueva venta
3. A: El cajero introduce el identificador de cada artículo.
4. S: El sistema registra la línea de venta y presenta descripción del
artículo, precio y suma parcial.
El Cajero repite los pasos 3 y 4 hasta que se indique.
5. S: El Sistema presenta el total
6. A: El Cajero le dice al Cliente el total a pagar
7. S: El Cliente paga y el sistema gestiona el pago.
8. S: El Sistema registra la venta completa y actualiza Inventario.
9. S: El Sistema presenta recibo
CASO DE USO “REALIZAR VENTA”
Requisitos especiales:
- Interfaz de usuario con pantalla táctil en un monitor de pantalla plana. El
texto debe ser visible a un metro de distancia.
- Tiempo de respuesta para autorización de crédito de 30 sg. El 90% de las
veces
...
Lista de Tecnología y Variaciones de Datos:
- El identificador podría ser cualquier esquema de código UPC, EAN,..
- La entrada de información de la tarjeta se realiza mediante un lector de
tarjetas.
...
Cuestiones Pendientes:
- Explorar cuestiones de recuperación de accesos a servicios remotos
- ¿Qué adaptaciones son necesarias para diferentes negocios?
IDENTIFICACIÓN DE CASOS DE USO (LARMAN)
Objetivos Estrátegicos
Ej.: Evitar pérdidas
Objetivos de Usuario casos de uso
Ej.: Realizar Venta
Subfunciones ¿casos de uso?
Ej.: Iniciar sesión (Login)
IDENTIFICACIÓN DE CASOS DE USO
(LARMAN)
finalizarVenta
EsperandoPago
realizarPagoEnEfectivo
Autorizando
Pago
realizarPagoACredito
Procesar Venta
realizarPagoConCheque
DOCUMENTOS DE ANÁLISIS REQUISITOS
Casos de Uso
Especificación Complementaria
Captura otros requisitos
Glosario
Captura términos y definiciones
Visión
Define visión del producto de los stakeholders, en
términos de sus necesidades y características
ESPECIFICACIÓN COMPLEMENTARIA
Funcionalidad
Abarca varios casos de uso
Ej. “Almacenar información errores”, “Cualquier uso requiere
autenticación de usuario”
Requisitos No Funcionales (Atributos de calidad)
Usabilidad, Mantenimiento, Adaptación, Fiabilidad, Rendimiento
Restricciones Implementación (hardware, software, desarrollo)
Componentes comprados y free open source
Interfaces
Reglas de Negocio (Ej. Reglas de descuento, Cálculo impuestos)
Cuestiones Legales
Cuestiones sobre el entorno físico y operacionales
Información en dominios relacionados
VISIÓN
Oportunidad
Definición del problema
Alternativas
Descripción stakeholders
Objetivos usuario
Perspectiva del producto
Beneficios del producto
Lista de características del producto
Coste y precio
Otros requisitos y restricciones
MODELO CONCEPTUAL (O DOMINIO)
Categorías de clases
Contenedores de cosas
Cosas en un contenedor
Dispositivos externos al sistema
Conceptos abstractos
Eventos
Procesos
Reglas y Políticas
Catálogos
Contratos, documentos legales
Instrumentos y servicios financieros
Manuales, documentos, trabajos, libros
Modelo
Conceptual
Registra venta de
fabricado mediante
Producto Plantilla de Produccion
1..*
es solicitado en
base de
0..* 0..*
1..*
realizado por
Cliente
Objetivo:
A partir de los casos de uso obtener el diseño
preliminar del sistema que deberá ser refinado
en el modelo del diseño.
Nivel de abstracción más alto que en el diseño.
Visión ideal del sistema.
Se define una arquitectura del sistema.
MODELO DEL ANÁLISIS
:Sistema
: Cajero
crearNuevaVenta
Operacion
* introducirItem(upc,cantidad)
Operacion
finalizarVenta()
Operacion
crearPago(cantidad)
CONTRATOS
Diagrama de Secuencia del Sistema
(Caso de Uso “Realizar Venta”)
:Sistema
: Cajero
TPV con
item introducirItem (CUP, cantidad)
id item
4. Sistema registra
línea de
venta y presenta
parcial eventos del
sistema
4: esp:= especificacion(cup)
7: crear(esp,cant)
3: crear()
: Catalogo 8: add(lv)
Productos
lv : Lineas
5: esp:= find(cup) Venta
: Lineas
Venta
:
Producto
DIAGRAMA DE CLASES DEL ANÁLISIS
Hacer
Algo a uno mismo
Iniciar una acción en otros objetos
0..*
Producto
descripcion
precio
codigo
EJEMPLO 1
t:=total
* st:=subtotal
p:=getPrecio
EJEMPLO 2
Beneficios:
Bajo acoplamiento
BAJO ACOPLAMIENTO
agregarPago(p)
EJEMPLO
efectuarPago
efectuarPago
crear
ALTA COHESIÓN
Beneficios
Mejora reutilización
Clases más claras, se comprenden mejor
Mejora mantenimiento
CONTROLADOR
introItem introItem(cant,cod)
crearLineaVenta(cant,cod)
evento
:AppletTPV :Venta
introProd crearLineProd(cant,cod)
evento
Beneficios:
Favorece la reutilización
Posibilidad de capturar información sobre el estado del
proceso
POLIMORFISMO
¿Cómo manejar las alternativas basadas en el tipo?
¿Cómo crear componentes software conectables
(pluggable)?
class A { class B {
B at1; C at2;
void met1() { C getAt2() {return at2;}
C obj = at1.getAt2(); }
obj.met2();}
}
NO HABLES CON EXTRAÑOS
class A { class B {
B at1; C at2;
void met1(..) { C getAt2() {return at2;}
at1.met3;} void met3() {at2.met2;}
} }
class C {
void met2() {..}
}
class Registro {
private Venta venta;
public void metodoFragil () {
Dinero cantidad =
venta.getPago().getCantidadEntregada()
...
}
Dinero cantidad =
} venta.geCantidadEntregadaEnPago()
MODELO DEL DISEÑO
Objetivo:
Refinar el diseño del sistema del modelo del análisis
introduciendo los requisitos no funcionales y
restricciones del entorno de implementación.
Almacenamiento
VISTA-DATOS VS.
VISTA-MODELO-DATOS
ARQUITECTURA VISTA-DATOS
ARQUITECTURA VISTA-MODELO-DATOS