You are on page 1of 8

RELACIÓN DE ARTEFACTOS UP

Domain Model

Sale Register ProductCatalog ...


Captured-on
timeStamp 1 1 ... ... ...

domain concepts

Use-Case Model

: System
Process Sale : Cashier
make Process
1. Customer NewSale() Sale
system
arrives ... Cashier
events enterItem
2. Cashier
makes new (id, quantity)
...
conceptual sale.
classes in 3. ...
the
domain Use Cases System Sequence Diagrams Use Case Diagrams
inspire the
names of
some
software use-case Design Model
classes in realization with
the design interaction : Register : ProductCatalog
diagrams
makeNewSale()
create() : Sale
enterItem(id, quantity)
spec := getSpecification( id )

addLineItem( spec, quantity )


...

the design
Register classes
ProductCatalog discovered
... 1 1 while designing
...
UCRs can be
makeNewSale() summarized in
getSpecification(...) : ProductSpecification
enterItem(...) class diagrams
...
...
Domain Model

Sale 1 1.. * Sales


...
LineItem
date
...
... quantity

the domain objects, attributes, and


domain objects
associations that undergo state changes

Use-Case Model

: System
Operation: makeNewSale
Process Sale : Cashier make
NewSale() Post-conditions:
1. Customer - ...
arrives ... system system
2. ... enterItem
events operations
3. Cashier (id, quantity)
enters item Operation: enterItem
identifier.
4.... endSale()
Post-conditions:
- A SalesLineItem instance
sli was created
makePayment - ...
(amount)

Use Cases System Sequence Diagrams Contracts

in addition to the use cases,


some ideas and inspiration for the post- requirements that must be
conditions derive from the use cases satisfied by the design of the
software

requirements that Design Model


must be satisfied by
the design of the : Register : ProductCatalog : Sale
software
enterItem
(itemID, quantity)

spec := getProductSpec( itemID )

addLineItem( spec, quantity )

...
ESCENARIO SIMPLE DE:

PROCESAR VENTA PARA PAGO EN EFECTIVO

1- El cliente llega al Terminal de PDV


2- El cajero inicia nueva venta
3- El cajero inserta el identificador del artículo
4- El sistema registra la línea de venta y presenta la descripción del artículo, precio
y suma parcial
5- El cajero repite los pasos 3 y 4 hasta que se indique
6- El sistema muestra el total de la venta con los impuestos calculados
7- El cajero le dice el total al cliente y le pide el pago
8- El cliente paga y el sistema gestiona el pago

:System
: Cashier
makeNewSale()

these input system events


addLineItem(itemID, quantity) invoke system operations

the system event


makeNewSale invokes a
description, total
system operation called
* [more items] makeNewSale and so forth

this is the same as in object-


endSale() oriented programming when
we say the message foo
invokes the method (handling
total with taxes operation) foo

makePayment(amount)

change due, receipt


CONTRATO: Introducir Artículo

Operación: Introducir Artículo (addLineItem)


(cup: Número, cantidad: Número)

Referencias Cruzadas: Caso de uso Procesar Venta

Precondiciones: Hay una venta en proceso


Poscondiciones:
 Se creó una instancia de línea de venta ldv, creación de instancias.
 Ldv se asoció con la venta actual (formación de asociaciones)
 Ldv. Cantidad, pasó a ser cantidad (modificación de atributos)
 Ldv se asoció con un Especificación del producto en base a la coincidencia del
artículoID (formación de asociaciones). ..Ldv.precio

by Creator
by Controller

enterItem(id, qty) 2: makeLineItem(spec, qty)


:Register :Sale

1: spec := getSpecification(id)
2.1: create(spec, qty)

:Product
by Expert
Catalog

sl: SalesLineItem
1.1: spec := find(id)
2.2: add(sl)

This find message is to the


Map object (the multiobject), SalesLineItem add the newly created
:Product :SalesLineItem
not to a ProductSpecification. Specification SalesLineItem instance to the
multiobject (e.g., List)

CAUTION:
CAUTION:
This is a multiobject collection (such as a Map), not a
This is a multiobject collection (such as a List), not a
ProductSpecification. It may contain many
SalesLineItem. It may contain many SalesLineItems.
ProductSpecifications.
Store Uses
1 address : Address 1
1
name : Text
ProductSpecification
ProductCatalog
addSale(...)
description : Text
... Contains
price : Money
1 Looks-in 1 1 1.. * itemID: ItemID
getSpecification(...)
...
Houses
1
1 1 Describes
Sale
Register date : Date
*
isComplete : Boolean SalesLineItem
...
Captures time : Time Contains quantity : Integer
endSale() 1 1 1 1.. *
becomeComplete()
enterItem(...) getSubtotal()
makeLineItem(...)
makeNewSale()
makePayment(...)
makePayment(...)
getTotal()

Logs-completed  * 1
Payment
Paid-by
amount : Money
A dependency of Register knowing about 1
ProductSpecification. ...

Recommended when there is parameter,


global or locally declared visibility.
Diagrama de Colaboración de venta-total
(caso de uso : procesar venta, contrato: obtener total de venta)

Note the semi-formal style of the constraint. "aSLI" is not


// observe the seudo code style here formally defined, but most developers will reasonably
{ understand this to mean an instance of SalesLineItem.
public void getTotal() Likewise with the expression aSLI.prodSpec.price.
{
int tot = 0; The point is that the constraint language can be informal,
for each SalesLineItem, sli to support quick and easy writing, if desired.
tot = tot + sli.getSubtotal();
return tot
}
}
{ st = aSLI.quantity * aSLI.prodSpec.price }

tot := getTotal() 1 *: st := getSubtotal()


:Sale : SalesLineItem
*
1.1: pr := getPrice()

:ProductSpecification
Aplicación de la operación iniciar al punto de Venta
(CU Iniciar, contrato Iniciar())

pass a reference to the


ProductCatalog to the
Register, so that it has
permanent visibility to it

create() :Store 2: create(pc) :Register

by Creator
create an empty multiobject (e.g., a
Map), not a ProductSpecification
1: create()
1.1: create()

pc: 1.2.2*: add(ps) :Product


ProductCatalog Specification

1.2.1*: create(id, price, description)


1.2: loadProdSpecs()

ps:
ProductSpecification
the * in sequence number
indicates the message occurs in
a repeating section
Sample UP Artifacts Partial artifacts,
refined in each
Domain iteration.
Business Model
Modeling *
* the domain objects,
attributes, and associations
that undergo state changes

Use-Case Model

:System

foo( x ) Glossary ...


Requirements
bar( y )
system
text use system operations
system
use case sequence operation
cases diagrams diagrams contracts

Design Model Software


the system operations are
Architecture Doc.
Design handled by designing
software to fulfill the post-
conditions of the
contracts

Software
Dev. Plan
Project
Management

Test
Plan Development
Case
Test Environment

You might also like