caso de estudio: post of sale : pos - ldc.usb.veci3715/teoria/html/cla_0006.pdf · caso de...

1

Fin de Fase de Inicio y realización de

Fase de Elaboración

A. Soriano1,2 – N. Zambrano1

1 Universidad Central de Venezuela2 Universidad Simón Bolivar

Octubre 2005

Caso de Estudio: Post of Sale : POS

2

Oct 2005A Soriano y N Zambrano

Proceso Unificado: Referencia Básica

Craig Larman

“Applying UML and Patterns: An Introduction to Object Oriented Analysis and Design and the Unified Process”

Segunda edición

Prentice-Hall, Inc. 2002 ISBN 0-13-092569

Descripción del problema: Cap. 3Del Inicio a la Elaboración: Cap 8De los Requerimientos al diseño: Cap 14Modelo del Dominio: Cap. 10, 11, 12Refinamiento del Modelo del Dominio: 26, 27

2

3


Proceso Unificado:Referencias Complementarias

“El Proceso unificado de desarrollo de Software”I. Jacobson, G. Booch y J.RumbaughAddison Wesley - Pearson Education 1999

“The Rational Unified Process”Ph. KruchtenAddison Wesley 2000

“El Lenguaje Unificado de Modelado: Manual de Referencia”J.Rumbaugh, I. Jacobson y G. BoochAddison Wesley - Pearson Education 2000.

4


- Computador,

- Lector de código de barra

- Sofware del Sistema.

- registrar ventas

- manejar los pagos

Caso de Estudio: Sistema de Punto de Venta

Punto de Venta para ventas al detal: POS (Post of Sale)

Uso principal:

Compuesto por: Ilustración extraída de:

Appliyng UML and patterns.

2° edición

C. Larman

Prentice Hall. 2002

Caso de Estudio:POS

3

5


Caso de Estudio: Arquitectura

Un típico Sistema de Información Orientado a Objeto está diseñado en términos de varias

capas arquitecturales o subsistemas.

Capa de Presentación

Capa Lógica o Dominio de la Aplicación

Capa de Almacenamiento

Interfaces de comunicación

Clases y Objetos del Dominio de la AplicaciónInformación persistente

(Base de Datos)

6


Proceso Unificado

Modelado del negocio

ImplementaciónPruebaEntrega

Analisis y Diseño

Disciplinas

Requerimientos

Gerencia de proyecto Ambiente

Fases

Iteraciones

ElaboraciónConstrucciónTransición

Gerencia de Configuración y Cambio

Inicio

4

7


De Inicio a Elaboración

Algunos artefactos construidos y otros por construirGrado de madurez del artefacto

8


Ejemplo de artefactos y momento de su concepción

refinarcomenzarCaso de Desarrollo

Ambiente

refinarcomenzarModelo de PruebaPrueba

refinarrefinarrefinarcomenzarPlan de desarrollo de SW

Gerencia del Proyecto

refinarrefinarcomenzarModelo de Implementación

Implementación

refinarcomenzarModelo de Datos

crearDocumento de Arquitectura de Software

refinarcomenzarModelo de DiseñoAnálisis y Diseño

refinarcomenzarGlosario

refinarcomenzarEspecificaciones Suplementarias

refinarcomenzarVisión

refinarcomenzarModelo de Casos de Uso

Requerimientos

crear o refinarcomenzar(opcional)

Modelo del Dominio

Modelado de Negocios

TransiciónConstrucciónElaboraciónInicioArtefactoDisciplina

5

9


Proceso Unificado

Modelado del negocio

ImplementaciónPruebaEntrega

Analisis y Diseño

Disciplinas

Requerimientos

Gerencia de proyecto Ambiente

Fases

Iteraciones

Elaboración Construcción Transición

Gerencia de Configuración y Cambio

Inicio

10


Proceso Unificado: Fase de Elaboración en una frase

tiempo

Inicio Elaboración Construcción Transición

Línea base de una arquitectura ejecutable• Construir el corazón de la arquitectura • Resolver los elementos de alto riesgo• Definir los principales requerimientos • Estimar cronograma y recursos

6

11


Diagramas

StateDiagramsState

DiagramsDiagrama de Clases

StateDiagramsState

DiagramsDiagrama de Objeto

UML 2.0: Modelos, Vistas y Diagramas

Use CaseDiagramsUse Case

DiagramsDiagrama de Casos de Uso

ScenarioDiagramsScenario

DiagramsDiagrama de Actividad

ScenarioDiagramsScenario

DiagramsDiagrama de Secuencia

Use CaseDiagramsUse Case

DiagramsDiagrama de

Máquina de

Estado

Diagrama de Comunicación

ComponentDiagramsComponent

DiagramsDiagrama deComponentes

ComponentDiagramsComponent

DiagramsDiagrama de Despliegue

Diagramas

12


Modelo del Dominio

Dominio Modelo del Dominio

sistema

1..* 0..*

Vista estática del sistemaDiagrama de Clases

1..* 0..*1..* 0..*

Vista estática del sistemaDiagrama de Clases

Una visión conceptual de la conformación de un dominio a partir de los objetos que

lo conforman y sus relaciones

Es una abstracción de un cierto dominio del mundo real.Describe el sistema desde una perspectiva estática:

los objetos, las clases de objetos, sus relaciones.

7

13


Una representación visual de las clases de objetos del mundo real -en un dominio de

interés- y las relaciones entre ellas

Modelo del Dominio

Producto Punto de Venta

Tienda

¿POS?

.......

14


Clases: del modelo conceptual al modelo del diseño

Modelo del dominio(clase conceptual)

Dominio

Triángulo__________vértice1vértice2vértice3

Triángulo

v1, v2, v3: Vértices

área( ): Realcolorear()mover ()

nombre

atributos

métodos

Modelo de diseño(clase de software –perspectiva de especificación o de implementación)

8

15


Clases: del modelo conceptual al modelo del diseño

Términos en el Modelo del dominio Triángulo

p1, p2, p3: Vértices

área( ): Realcolorearmover ()escala ()

Triángulo__________punto1punto2punto3

nombre

atributos

métodos

Triángulo

p1, p2, p3: Vértices

área( ): Realcolorearmover ()escala ()

Triángulo__________punto1punto2punto3

nombre

atributos

métodosVocabulario

Términos en el Modelo de diseño

Términos en el software

16


Objetos significativos en el dominio

¿Cómo identificarlos?

– a partir de los Casos de Uso– a partir de listas de conceptos por categorías– a partir de patrones.

Identificación de clases conceptuales

9

17


Identificación de clases:listas de conceptos por categorías

Dominio Lista

Telecomunicaciones Enrutador, protocolo, mensaje, conexión, puerto,..

Cosas de un conjunto Item, elemento, ..

Punto de Venta Cajero, terminal, venta, tienda,..

18


Lista de Categorías o Clases Conceptuales

Objetos físicos o tangibles (Avión)Especificaciones, diseños o descripciones de cosas (Vuelo)Lugares (Aeropuerto)Transacciones (Reservación)Elementos de una transacción (asiento)Roles de personas (Piloto)Contenedores de otras cosas (Avión)Elementos en un contenedor (Pasajero)Conceptos abstractos (Claustrofobia)Otros Sistemas (Control de Tráfico Aéreo)Organizaciones (Aerolínea)Eventos (Venta)Procesos (Buscar un asiento)Reglas y políticas (Condiciones de cancelación)Catálogos (Lista de Productos)Registros financieros, trabajos, contratos, elementos legales (Histórico de mantenimiento)Instrumentos financieros y servicios (Tarjeta de crédito)Manuales, documentos, artículos de referencias, libros (Manuales de reparación)

10

19


Identificación de clases:revisión de los casos de uso

Caso de Estudio:POS

Servicio de Autorizaciones de Pago

<<actor>> Sistema de

Suscripciones

<<actor>> Sistema Calculador

de ImpuestosManejar Seguridad

Manejar Usuarios

Analizar Actividad

Procesar Venta

Manejar Devoluciones

Alquilar

POS

Cajero

Administrador del Sistema

<<actor>> Sistema de

Actividad de Ventas

Cobrar

......

20


Identificación de clases:revisión de los casos de uso

Caso de Estudio:POS

1) El Cliente llega a la tienda, selecciona productos y va al POS de salida para pagar

2) El Cajero inicia una nueva venta

3) El Cajero introduce la identificación del producto y la cantidad

– El sistema registra la línea de venta del producto y presenta la descripción del artículo, precio y el totalasi como el total acumulado

– El sistema presenta el total con el impuesto calculado

4) El cajero muestra el total al Cliente y éste entrega el pagoy recibe la factura

– el sistema maneja el pago.

Procesar Venta

Cajero

Cobrar

Iniciar

Introducir Id

Introducircantidad

Mostrarresultados

<<include>>

<<include>>

<<include>>

<<include>>

11

21


Identificación de clases:Caso de estudio

Producto

Punto de Venta(POS)

Tienda

VentasLíneaDe

Productos

Pago___________

monto

Venta

Factura ?

Caso de Estudio:POS

1) El Cliente llega a la tienda, selecciona productos y va al POS de salida para pagar

2) El Cajero inicia una nueva venta3) El Cajero introduce la identificación del producto y la cantidad

– El sistema registra la línea de venta del producto y presenta la descripción del artículo, precio y el totalasi como el total acumulado

– El sistema presenta el total con el impuesto calculado

4) El cajero muestra el total al Cliente y éste entrega el pago y recibe la factura

– el sistema maneja el pago.

22


Identificación de clases: ¿Incluir factura?

No, La información puedeser derivada de otroobjeto y podríaexcluirseEs un reporte de venta y en este niveldel problema podría no considerarse.

SiSi el caso de uso considera el devolución de artículos, jugaría unpapel importante.

Caso de Estudio:POS

12

23


Guías para modelar el dominio

Identificar las clases conceptuales– Usar los nombres existentes en el dominio– Excluir objetos del dominio que no son

relevantes al problema en consideración– Excluir elementos que no están en el dominio

del problema en consideración (no agregar lo que no existe)

Agregar las asociaciones entre las clasesAgregar los atributos de las clases.

24


Guías para modelar el dominio: ¿item o especificación del item?

¿Objeto o descripción del objeto?

Item____________Descripción

PrecioNumeroSerialIdentificador

...

¿o bien ?

ItemElemento físico

DescripciónItem_______________

DescripciónPrecio

identificador

Item_____________NúmeroSerial

Descripción del ItemProporciona información

acerca del Item

Caso de Estudio:POS

13

25


Guías para modelar el dominio: item o especificación del item?

¿Cuándo se requiere la descripción de un item?Cuando hay necesidad de la descripción de un elemento independiente de si existe o no,y para evitar repetición de información o bien pérdida de información.


DescripciónPrecio

identificador


1 *DescripciónItem_______________

DescripciónPrecio

identificador


1 *

26


Identificación de clasesCaso de estudio

Producto

Punto de Venta

Tienda

LíneaDeVenta

DeProductos

Pago___________

monto

Venta Cajero

Cliente

DescripciónProducto

CatálogoProducto

Caso de Estudio:POS

√

√

√

√

14

27


Objeto

Entidad con identidad única que encapsula estado y comportamiento

La notación UML

triángulo: Polígono

vértices = ((0,0),(4,0),(4,3))color-borde = negrocolor-relleno = blanco

triángulo

:Polígono

triángulo: Polígono

28


Modelo del dominio:agregando asociaciones

¿Qué es una asociación?Una relación significativa entre dos clases -o entre sus instancias-Conexión semántica entre elementos del modelo.

Compañía Persona1 1..*

Trabaja-para

La flecha -opcional-indica la dirección de lectura del nombre de la asociación

15

29


Asociaciones binarias

Conexión semántica bidireccional entre elementos, de modelo e incluye: un nombre (nombre de la asociación, vinculada a un comportamiento específico) y un rol (nombre, dirección y multiplicidad del extremo de una asociación).

La notación UML

dirige

Compañía1 1..*

emplea

Trabaja parajefe

*

0..1

empleado

Persona

30


Roles de una asociación

Cada extremo de una asociación se llama rol

El rol puede tener:NombreMultiplicidadDirección o navegabilidad.

Pedido

Fecha¿Es prepagado?NúmeroCosto

despacho( )

CantidadPrecio¿Satisfecho?

Producto

contiene

16

31


Multiplicidad

Indica cuántas instancias puedenparticipar en la relación en un momento dado

ClienteNombre..

*

ClienteNombre..

1..*

ClienteNombre..

1..10

ClienteNombre..

5

0 ó más (muchos)

1 ó más

Rango especificado (1 a 10)

Exactamente 5

ClienteNombre..

2,4 Alternativas indicadas (2 o 4)

32


Nombre del rol

Nombre del Rol = identifica el extremo de la asociación

NombreCédula de IdentidadDirección

PersonaGerente de Ventas

Supervisa

Vendedor

NombreDirección

CompañíaTrabaja para

NombreCédula de IdentidadDirección

Persona

empresa empleado

El nombre del rol es obligatorio paraasociaciones entre objetos de la misma clase

17

33


Convenciones para asociaciones

LíneaAérea

Supervisa

Emplea

Asignado-a

1

1..*

Piloto Vuelo RutaAsignado-a

1 11 *

* *

Convención de lectura de los nombres de las asociaciones

34


Guías para identificar asociaciones


DescripciónPrecio

identificador


1 *

• Centrarse en las relaciones que deben ser preservadas sin depender de la existencia de instancias

• Evitar asociaciones redundantes o derivables

• Chequear lista de asociaciones típicas.

18

35


Guías para identificar asociaciones:lista de categorías de asociaciones

Cliente - CajeroA se comunica con B

Cajero - TiendaA es miembro de B

DescripciónProducto - ProductoA es una descripción de B

Producto esta en la TiendaA está contenida en B

Gaveta de la Caja RegistradoraA es parte física de B

SistemaCategoría

36


Modelo del dominio:agregando asociaciones

Producto

Punto de Venta

Tienda

LineadeVenta

deProducto

Pago_________

monto

Venta

O..1 1Registra-venta-de

1

1registrada-en

1..*

1

tiene

1

1..*

Contenida-en

1

1

Cancelado-porEsto es unaasociación

Caso de Estudio:POS

1

Almacenado-en*

19

37


Modelo del dominio:agregando clases y asociaciones

Producto

Punto de Venta

Tienda

VentasLíneaDe

Productos

Pago_________

monto

Venta

1..*

1..*

O..1

*

1Registra-venta-de

registra-en

Almacenado-en

Tiene

Contenida-en

Cancelado-por

Cliente Cajero Manager


Descritas-por

CatalogoProductoIniciado-por Iniciado-por

Iniciada-por

*

1..**

1: si se omite multiplicidad √

√

√√√

Caso de Estudio:POS

38


Modelo del dominio:agregando clases y asociaciones

Producto

Punto de Venta

Tienda

VentasLíneaDe

Productos

Pago_________

monto

Venta

1..*

1..*

O..1

*

1Registra-venta-de

registra-en

Almacenado-en

Tiene

Contenida-en

Cancelado-por

Cliente Cajero Manager


Descritas-por


Iniciada-por

*

1..**

√

√

√√√

Caso de Estudio:POS

20

39


Modelo del dominio:colocando los atributos

¿Qué es un atributo?Una información significativa de una clase -o de su instancia- que es necesaria para la comprensión del modelo y para satisfacer un requerimiento.

Tiendadirección: Textnombre: Text

Ventafecha: Fechahora: Time

1 *

realiza

Se indica el nombre y el tipo del atributo

Caso de Estudio:POS

40


Modelo del dominio:sumando atributos

Caso de Estudio:POS

¿Cuáles atributos?Información significativa para satisfacer un requerimiento

La factura de una venta, incluye fecha, hora, precio por itemla cantidad por item,

el total por linea de itemy el total a cancelar

Ejemplo : sea el requerimiento de “dar factura al cliente”, para hacer esa factura se requieren datos, los cuales deben ser atributos de alguna clase (Venta)

21

41


Guías para modelar el dominio:Clase o atributo?

¿Clase o atributo?

Vuelo___________

destino

Aeropuerto___________

nombreVuelo¿o bien ?

42


Modelo del dominio:agregando atributos

Producto

Punto de Venta

Tiendadirecciónnombre

LíneaDeVentaDeProductocantidad

Pago

monto

Ventafechahora

1..*

1..*

O..1

1

*

1

1

1Registra-venta-de

registra-en

Almacenado-en

Tiene

Contenida-en

Cancelado-por

Cliente Cajero Gerente


descripciónprecio

id

Descritas-por


Iniciada-por

* 1

1..** 1

√

√

√

√√

Caso de Estudio:POS

22

43


Está listo el modelo del dominio?

Todo modelo es una aproximación del dominio que intenta comprender

Un buen modelo debe capturar lo esencial para comprender el dominio en el contexto de los requerimientos

El modelo ayuda a entender el dominio, sus conceptos, terminología y relaciones

Cada modelo tiene un nivel de granularidaddependiente del grado del detalle.

44


Modelando Relaciones de mayor complejidad

Relaciones: conexiones semánticas entre elementos del modelo– Asociación binaria– Agregación– Generalización– Dependencia.

La notación UML

23

45


Generalización / Especialización

Relación entre un elemento más general y un elemento más específico

Caso de Estudio:POS

Refinamiento caso de uso proceso de venta:

.........curso normal: pago efectivocursos alternos: - pago por cheque o

- pago por tarjeta de crédito...........

Cómo se expresa en el diagrama del modelo del dominio?

46


Generalización

Se crea una clase (superclase), que generaliza las propiedades comunes de varias clases

PagoCrédito PagoChequePagoEfectivo

Pago Superclase

Concepto más general

SubclaseConcepto más especializado

Caso de Estudio:POS

24

47


Especialización o partición

Se crean otras clases (subclases) que especializan una clase dada

Pago

PagoCrédito PagoChequePagoEfectivo

Caso de Estudio:POS

48


Guías para modelar el dominio:¿Cuándo generalizar?

• Es útil realizar la partición

• Las definiciones asociadas a la superclase debenser aplicables a las subclases (regla 100%)

• Todos los miembros de una clase deben ser miembros de la superclase: regla “es un (a)”

Cliente

ClienteMasculinoClienteFemenino

Cliente

ClienteMasculinoClienteFemenino

?

25

49


Guías para modelar el dominio:cuándo especializar ?

¿Cuándo dividir una clase en subclases?

• La subclase tiene atributos, o asociaciones u operaciones adicionales de interés

• La subclase incluye un comportamiento (manipulación, reacción, etc.) diferente al de la clase.

50


Guías para modelar el dominio:cuándo generalizar ?

¿Cuándo definir una superclase?

• Cuando se identifican atributos, o asociaciones u operaciones comunes entre potenciales subclases, que pueden ser asociados a la superclase

• La subclase cumple las reglas del 100% y la regla “es un(a)” respecto a la potencial superclase.

26

51


Herencia

Una clase B hereda de una clase A si adquiere las propiedades (estructura, comportamiento y relaciones) definidas en la clase AA es una superclase de la clase BB es una subclase de la clase A.

A

B

<<hereda>>

52


Modelando otras relaciones

Relaciones: conexiones semánticas entre elementos del modelo– Asociación binaria– Agregación– Generalización– Dependencia.

La notación UML

27

53


Agregación(todo/partes)

Venta VentaLineaProducto

11..* Agregación

Caso de Estudio:POS

CatálogoProductos


1 1..*Agregación

{ordenada}

Mano Dedo1 1..5

Agregación

54


Guías para modelar el dominio:¿Cuándo introducir una agregación?

• Hay un conjunto indisoluble lógico o físico de la parte y el todo

• Hay una dependencia crear/eliminar de la parte y el todo

• Operaciones aplicadas al todo se propagan a las partes (movimiento,...)

• Propiedades del todo se propagan a las partes (localización, ...)

• Si hay duda de lo anterior, no introduzca agregación.

28

55


Asociaciones complejas:Clase Asociación

Se utiliza cuando los atributos no pertenecen a las clases sino a la asociación

PrioridadDerechoAcceso

UsuarioAutorizado en EstaciónTrabajo

Autorización

InicioSesión

Directorio

Tomado de Univ. Calgary

56


Guías para modelar el dominio:cuándo crear una clase asociación?

• Un atributo está relacionado a la asociación

• Instancias de la clase asociación tienen un tiempo de vida dependiente de la asociación

• Generalmente parten de asociaciones mucho-mucho entre dos clases

• Hay dos clases asociadas y no se esta claro en cual clase colocar el atributo.

29

57


Asociaciones complejas:asociaciones n-arias

Vuelo Asiento

Persona

asientovuelo

pasajero

reservación

La notación UML

58


Resumen: notación básica pararelaciones

Clase B Clase ANombre-de-la-asociaciónrol_Arol_B

Superclase

Subclase2 Subclase 3Subclase1

Parte*

1

Todo

1 1..*

asociaciones

Generalización Agregación

Parte

30

59


Administración del Modelo:organización en paquetes

– Paquetes

– Modelo

Un modelo es una abstraccióndel sistema físico.

Describe el sistema desde un punto de vista y a un

cierto nivel de abstracción

Los paquetes permiten agrupar elementos del

modelo

60


Paquetes: Notación

Dominio

Ventas

contenidoElementos Sistema

31

61


Paquetes

El paquete es una agrupación de elementos del modelo

Un paquete puede:- estar incluido dentro de otro paquete,- contener otra clase de elementos del

modelo.

Cada elemento pertenece a un único paquete.

62


Dependencias entre paquetes

Los paquetes pueden hacer referencia a otros paquetes

Dominio

contenido

ElemSist Ventas

Paquete Ventas es dependiente del Paquete ElemSist

32

63


Guías para particionar el modelo del dominio

¿Cómo organizar las clases del modelo del dominio en paquetes?• Pertenecen al mismo subdominio, con

conceptos o propósitos relacionados• Participan en el mismo caso de uso• Están fuertemente relacionados• Pertenecen a la misma jerarquía de clases• Grado de granularidad.

64


Recomendaciones

Tratar de evitar ciclos en la estructura de dependencias

Si hay muchas dependencias analizar la modularización del sistema

Construir un diagrama de paquetescuando el diagrama de clases del sistemano sea legible en una página.

caso de estudio: post of sale : pos - ldc.usb.veci3715/teoria/html/cla_0006.pdf · caso de...

Documents