uml josé vargas mery. diagramas uml uml ofrece cinco grupos diferentes de diagramas para modelar un...
TRANSCRIPT
UML
José Vargas Mery
Diagramas UML
UML ofrece cinco grupos diferentes de diagramas para modelar un sistema– Casos de Uso– Estructura– Estado– Comportamiento– Implementación
Diagramas UML
Diagramas de
Casos de UsoDiagramas
de Clases
Diagramas
de Objetos
Diagramas de Colaboración
Diagramas de Secuencia
Diagramas de Estados
Diagramas de Actividades
Diagramas de Despliegue
Diagramas de Componentes
Modelo del
Sistema
Diagramas UML
Casos de Uso– Diagramas de Casos
de Uso
Estructura– Diagramas de Clases– Diagramas de Objetos
Estado– Diagramas de Estados– Diagramas de
Actividades
Comportamiento– Diagramas de
Secuencia– Diagramas de
Colaboración
Implementación– Diagramas de
Componentes– Diagramas de
Despliegue
Actividades Generales del análisis Orientado Objeto
1. Modelar las funciones del sistema.2. Encontrar e identificar los objetos del
negocio.3. Organizar los objetos e identificar sus
relaciones.4. Modelar el comportamiento de los objetos.
Modelación de Casos de Uso
Modelación de las funciones de un sistema en términos de los eventos del negocio, quién los inicia, y cómo responde el sistema a ellos.
Caso de Uso
Secuencia de pasos o actividades relacionadas por su comportamiento (un escenario), tanto automatizadas como manuales, que tienen como fin completar una única tarea del negocio.
Notación en UML
Comprar productos
Actor
Representa cualquier cosa que necesita interactuar con el sistema para intercambiar información.
Un actor es un usuario del sistema, un rol, que puede ser tanto una persona como un sistema externo.
En un caso de uso, hay un actor que inicia la acción y, posiblemente, otros actores participantes.
Notación en UML Cajero
Casos de Uso - ejemplo El siguiente caso de uso de alto nivel describe el
proceso de comprar artículos en una tienda cuando se emplea una terminal en el punto de venta.
Caso de uso: Comprar productos
Actores: Cliente, Cajero
Tipo: Primario
Descripción: Un Cliente llega a la caja registradora con los artículos que comprará. El Cajero registra los artículos y cobra el importe. Al terminar la operación, el Cliente se marcha con los artículos comprados.
Cursos de Eventos
Curso normal de los eventos– Describe en detalles la interacción entre los
actores y el sistema.– Un aspecto esencial es que explica la
secuencia más común de los eventos; no incluye situaciones alternativas.
Curso alternativo de los eventos– Describe importantes opciones o excepciones
que pueden presentarse en relación con el curso normal.
– Si son complejas, se pueden expandir y convertir en otros casos de uso.
Curso Normal de Eventos
Acción de los actores Respuesta del sistema1. Este caso de uso comienza cuando unCliente llega a una caja TPDV (Terminalde Punto de Ventas) con productos que
desea comprar.2. El Cajero registra la identificación de cada
producto.Si hay varios productos de una misma
categoría, el Cajero también puede introducirla cantidad.
3. Determina el precio del producto eincorpora a la transacción actual lainformación correspondiente.
Se presentan la descripción y el precio delproducto actual.
4. Al terminar de introducir los productos, elCajero indica al TPDV que se concluyó lacaptura de productos.
5. Calcula y presenta el total de la venta.
6. El Cajero indica el total al Cliente.
Curso Normal de Eventos
7. El Cliente efectúa el pago en efectivo – el“efectivo ofrecido” – posiblemente mayor
que el total de la venta.8. El Cajero registra la cantidad de efectivo
recibida.9. Muestra al cliente la diferencia. Genera un
recibo.10. El Cajero deposita el efectivo recibido yextrae el cambio de pago.El Cajero le da al Cliente el cambio y el
recibo impreso.
11. Registra la venta concluida.
12. El Cliente se marcha con los artículoscomprados.
Cursos alternativos· Línea 2: introducción del identificador inválido. Indicar error.· Línea 7: el cliente no tenía suficiente dinero. Cancelar la transacción de venta.
Casos de Uso – Eventos Temporales
Evento temporal– Es un evento del sistema que es gatillado
por el paso del tiempo.– El actor del caso de uso de un evento
temporal es el tiempo.
Beneficios de la Modelación de Casos de Uso
Base para identificar objetos y sus relaciones y responsabilidades de alto nivel.
Visualizar el comportamiento del sistema desde el punto de vista de una persona externa.
Herramienta eficaz para validar requisitos. Herramienta eficaz de comunicación. Base para un plan de prueba. Base para un manual de usuario.
Proceso de Modelación de Casos de Uso
Paso 1: Identificar Actores y Casos de Uso Paso 2: Construir un Diagrama de Casos de
Uso Paso 3: Documentar el Curso Normal del Caso
de Uso Paso 4: Definir Caso de Uso de Análisis
MemberServicesSystem
MarketingDepartment
PotentialMember
ClubMember
Warehouse
AccountsReceivable
PastMember
MemberServices
various Inquiry Reponses
various Sales Reports
variousPromotion Reports
Subscription Offer
Member Order
New Subscription
Promotion
Subscription Renewal
Resubscription Offervarious MemberReports
various Subscription Reports
Subscription ProgramNew Promotion
Revised Packing Order
MemberCreditStatus
Diagrama de Contexto – Sistema de Servicio al Cliente
ActorPotentialMemberClubMemberClubMemberClubMemberClubMemberClubMemberPastMemberMarketing
Marketing
Marketing
Time
Time
Time
Time
Time
Use Case NameSUBMIT NEWSUBSCRIPTIONPLACE NEW MEMBERORDERMAKE ACCOUNT INQUIRY
MAKE PURCHASE INQUIRY
MAINTAIN MEMBER ORDER
SUBMIT CHANGE OFADDRESSSUBMITRESUBSCRIPTIONSUBMIT NEW MEMBERSUBSCRIPTION PROGRAMSUBMIT PAST MEMBERRESUBSCRIPTIONPROGRAMSUBMIT NEW PROMOTION
GENERATE QUARTERLYPROMOTION ANALYSISGENERATE QUARTERLYSALES ANALYSISGENERATE QUARTERLYMEMBERSHIP ANALYSISGENERATE ANNUAL SALESANALYSISGENERATE ANNUALMEMBERSHIP ANALYSIS
Use Case DescriptionPotential member joins the club by subscribing. (“Take anu 12 CDs for one penny and agree to buy 4 more at regular club prices within two years.”)Club member places order.
Club member wants to examine his or her account history.(90-day time limit)Club member inquires about his/her purchase history.(three-year time limit)Club member wants to revise an order or cancel an order.
Club member changes address.(including e-mail and privacy code)Past member rejoins the club by resubscribing.
Marketing establishes a new membership resubscription plan to entice new members.Marketing establishes a new membership resubscription plan to lure back former members.
Marketing initiates a promotion.(Note: A promotion features specific titles, usually new, that company is trying to sell at a special price. These promotions are integrated into a catalog sent (or communicated) to all members.)Print quarterly promotion analysis report.
Print annual sales analysis report.
Print annual membership analysis report.
Print annual sales analysis report.
Print annual membership analysis report.
Paso 1:Identificar Actores y Casos de Usos
Paso 2:Construir un Diagrama de Casos de Usos
Paso 3:Documentar curso normal del caso de uso
Paso 3:Documentar curso normal del caso de uso
Paso 3:Documentar curso normal del caso de uso
Referencia a los requerimientos con los cuales está relacionado.
El curso común del evento que describe los pasos principales del caso del uso, desde cuando comienza hasta cuando termina la interacción con el actor.
Cursos alternativos que describen excepciones al curso común del evento.
Precondición que describe el estado en que debe estar el sistema para que se ejecute el caso del uso.
Poscondición que describe el estado en que queda el sistema después de que se ejecuta el caso del uso.
Supuestos, que incluye cualquier tópico no relacionado con el comportamiento del caso de uso, tales como rendimiento o seguridad, que está asociado al caso de uso. En general, son aspectos que son difíciles de modelar dentro del curso de eventos del caso de uso.
1
2
3
4
5
6
Tipos de Casos de Usos
Caso de Uso de Extensión– Amplía la funcionalidad (curso normal) de un
cierto caso de uso.– Un caso de uso de extensión puede ser
invocado solamente por el caso del uso que está ampliando.
Caso de Uso Abstracto– Contiene los cursos normales que son
comunes a dos o más casos de uso originales.– Un caso de uso abstracto reduce redundancia
y promueve la reutilización.
Representación usando la notación de UML
Generar Orden deDespacho
Calcular Subtotal eImpuestos Pedido
Completar PedidoCliente Nuevo
Revisar Dirección
Solicitar Cambiode Dirección
«extends» «extends»
«uses»
«uses»
Casos de Uso – Relaciones
UML define tres tipos de relación en los Diagramas de Casos de Uso
Comunicación
ActorCaso de Uso
Casos de Uso – Relaciones
Inclusión– Una instancia del Caso de Uso origen
incluye también el comportamiento descrito por el Caso de Uso destino
<<include>> es equivalente a <<uses>>
Caso de Uso Origen Caso de Uso Destino
<<include>>
Casos de Uso – Relaciones
Extensión– El Caso de Uso origen extiende el
comportamiento del Caso de Uso destino
Caso de Uso Origen Caso de Uso Destino
<<extend>>
Paso 4:Definir Caso de Uso de Análisis
Paso 4:Definir Caso de Uso de Análisis
Actividades Generales del Análisis Orientado Objeto
1. Modelar las funciones del sistema.2. Encontrar e identificar los objetos del
negocio.3. Organizar los objetos e identificar sus
relaciones.4. Modelar el comportamiento de los objetos.
Encontrar e Identificar Objetos del Negocio Paso 1: Encontrar objetos potenciales
– Subrayar (o destacar) los sustantivos del caso de uso
Paso 2: Seleccionar los objetos propuestos– Quitar los sustantivos que representan:
• Sinónimos• Sustantivos fuera del alcance del sistema• Sustantivos que son roles que no tienen un
comportamiento único o que son externos• Sustantivos confusos que necesitan ser
reenfocados• Sustantivos que son en realidad acciones o
cualidades
Caso de uso con Sustantivos Subrayados
Caso de uso con Sustantivos Subrayados
Objetos Potenciales
Extraídos desde el caso de uso
Análisis de Objetos Potenciales
POTENTIAL OBJECT LISTAccounts Receivable DepartmentAmount Due Club Member Credit Card InformationCredit Problem NoticeCredit Status File Marketing DepartmentMember AddressMember OrderMember Phone NumberMember Services DepartmentMember Services SystemOrder Order Confirmation NoticeOrder Sales TaxOrder Status Order SubtotalOrdered ProductOrdered Product InformationOrdered Product QuantityPast Member Payments Potential MemberProduct Product InventoryProduct NumberStreet Address Transaction Warehouse Warehouse Packing Order
POTENTIAL OBJECT LISTAccounts Receivable DepartmentAmount Due Club Member Credit Card InformationCredit Problem NoticeCredit Status File Marketing DepartmentMember AddressMember OrderMember Phone NumberMember Services DepartmentMember Services SystemOrder Order Confirmation NoticeOrder Sales TaxOrder Status Order SubtotalOrdered ProductOrdered Product InformationOrdered Product QuantityPast Member Payments Potential MemberProduct Product InventoryProduct NumberStreet Address Transaction Warehouse Warehouse Packing Order
Not relevant for current project Attribute of “MEMBER ORDER” Type of “MEMBER”
Attribute of “MEMBER”
Potential Interface item to be addressed in object-oriented design Attribute of “MEMBER” Not relevant for current project Not relevant for current project Attribute of “MEMBER” “MEMBER ORDER”
Attribute of “MEMBER”
Not relevant for current project
Not relevant for current project
Another name for “MEMBER ORDER”
Potential Interface item to be addressed in object-oriented design Attribute of “MEMBER ORDER”
Attribute of “MEMBER ORDER”
Attribute of “MEMBER ORDER”
“MEMBER ORDERED PRODUCT”
Unclear noun
Attribute of “MEMBER ORDERED PRODUCT” Type of “MEMBER” Type of “TRANSACTION”
Type of “MEMBER”
“PRODUCT”
Attribute of “PRODUCT”
Attribute of “PRODUCT”
Attribute of “MEMBER”
“TRANSACTION”
Not relevant for current project
Potential Interface item to be addressed in object-oriented design
REASONxx
xxxxxx
xxxxxxxx
xx
xxx
xx
/
////
/
/
/
Resultadosdel Análisis
PROPOSED OBJECT LISTCLUB MEMBER
MEMBER ORDERMEMBER ORDERED PRODUCTPAST MEMBERPAYMENTPOTENTIAL MEMBERPRODUCTTRANSACTION
AGREEMENTAUDIO TITLE
MERCHANDISE
GAME TITLEPROMOTION
RETURNTITLEVIDEO TITLE
-- PLUS --
Actividades Generales delAnálisis Orientado Objeto
1. Modelar las funciones del sistema.2. Encontrar e identificar los objetos del
negocio.3. Organizar los objetos e identificar sus
relaciones.4. Modelar el comportamiento de los objetos.
Diagramas que muestran la estructura del sistema
Diagrama de clases– Muestra las clases de objetos de las que
está compuesto el sistema, así como las relaciones que existen entre ellos.
Diagrama de objetos– Similar al anterior, pero muestra instancias
individuales de cada clases.
Objetos, Atributos, e Instancias
Objeto– Es algo (persona, lugar, cosa, o evento) que
es visto, tocado, o percibido de alguna manera, y sobre el cual los usuarios almacenan datos y le asocian un cierto comportamiento.
Atributos– Datos que representan características de
interés de un objeto. Instancia
– Una instancia (o instancia de un objeto) está formada por los valores para cada uno de los atributos que describen un objeto específico.
Objetos, Atributos, e Instancias
412209: Customer
customer number = 412209last name = Bentleyfirst name = Lonniehome phone = 317-463-9593street = 2625 Darwin Dr.city = West Lafayettestate = Indianazip code = 47906etc.
0256101329: Book
ISBN = 0256101329type = textbooktitle = Systems Analysis & Design Methodscopyright = 1996
0256102219: Book
ISBN = 0256102219type = workbooktitle = Projects and Cases to Accompany SADMcopyright = 1996
(a)
(b)
Método
Se entiende por comportamiento a todo aquello que el objeto pueda hacer y que corresponde a funciones que actúan sobre los datos (atributos) del objeto.
En el contexto de orientación a objetos, se utiliza el concepto de método (o servicio) para referirse al comportamiento de un objeto.
Encapsulación
Es la agrupación de varios elementos en una unidad.
Los atributos y métodos se encapsulan en el objeto. La única forma de acceder a los atributos de un objeto es a través de sus métodos.
Clases de Objetos
Es un conjunto de objetos que tienen en común los mismos atributos y el mismo comportamiento.
Las clases también se denominan clases de objetos.
Open()Close()
ISBNtypetitlecopyright
Book Customer
customer numberlast namefirst namehome phonestreetcitystatezip codeetc.
changeAddress()
Herencia
Describe el mecanismo mediante el cual los atributos y/o métodos definidos para una clase de objetos puede ser heredado o reutilizado por otra clase de objetos.
Generalización/Especialización– Es una técnica donde los atributos y
métodos que son comunes a varios tipos de clases de objetos se agrupan en su propia clase, llamada supertipo. Los atributos y métodos de la clase de objetos supertipo son heredados a las clases de objetos originales.
Supertipos y Subtipos
Clase Supertipo– Es una clase de objetos cuyas instancias
almacenan atributos que son comunes a una o más clases subtipos.
Clase Subtipo– Es una clase de objetos cuyas instancias
heredan algunos atributos comunes de una clase supertipo, y luego agregan otros atributos que son únicos para las instancias del subtipo.
Supertipos y Subtipos
Clase Persona(supertipo)
Clase Alumno(subtipo)
Clase Profesor(subtipo)
Alumno A Alumno B Alumno C Profesor A Profesor B
Generalización/Especialización en UML
walk()jump()talk()sleep()eat()etc.()
last namefirst namebirth dategender
Person
enroll()displayGPA()
GPAclassification
Student
lecture()
rank
Teacher
Puntas de flechas indican relación degeneralización/especialización
Relaciones entre clases de objetos
Es una asociación natural de negocios que existe entre una o más clases de objetos.
0..*Customer Order
Places
Multiplicidad
Define como varias instancias de una clase de objetos puede ser asociada con una sola instancia de otra clase de objetos.
Multiplicity Multiplicity
Works for
0..1Has
0..*Makes
UML Notation
Association with Multiplicity Association Meaning
Exactly 1
1
or
leave blank
DepartmentEmployee1Works for
DepartmentEmployee
An employee works for one and only one department.
Zero or one 0..1 SpouseEmployeeAn employee has either one or no
spouse.
Zero or more
0..*
or
*
PaymentCustomer
PaymentCustomerMakes *
A customer can make no payment
up to many payments.
One or more 1..* CourseUniversityOffers 1..* A university
offers at least 1 course up to
many courses.
Specific range 7..9 GameTeam
7..9Has
scheduled A team has either 7, 8, or 9 games
scheduled
Notación de Multiplicidad en UML
Book
Cover Table of Contents
Chapter Index
Page
Paragraph
Word
1 1..*0..1 0..1
1..*
0..*
1..*
Diamante sólido indica relación de agregacióncompuesta
Ejemplo en UML de una relación de agregación compuesta
Team
Player
0..*
0..*Diamante hueco indicauna relación deagregación compartida
Ejemplo en UML de una relación de agregación compartida
Mensaje
Customeradd ordermodify orderdelete orderdisplay statusetc.
order numberorder dateorder statusetc.
Order
display order statusof order 23161
MENSAJESOLICITADO
(contiene nombre del método solicitado y los atributos requeridos por la clase ORDER)
Se pasa un mensaje cuando un objeto invoca uno o más métodos de otro objeto para requerir información o producir una acción.
Construcción de un Diagrama de Clases
Paso 1: Identificar Asociaciones y Multiplicidad– Subrayar (o destacar) los sustantivos del
caso de uso Paso 2: Identificar relaciones de
Generalización /Especialización Paso 3: Identificar relaciones de Agregación Paso 4: Preparar el diagrama de Clases
<<actor>>Club Member
Member-Date-Of-Last-OrderMember-Daytime-Phone-NumberMember-Credit-Card-Expire-DateMember-Credit-Card-NumberMember-Credit-Card-TypeMember-Balance-DueMember-Bonus-Balance-AvailableAudio-Category-PreferenceAudio-Media-PreferenceDate-EnrolledEmail-AddressGame-Category-PreferenceGame-Media-PreferenceNumber-Of-Credits-EarnedPrivacy-CodeVideo-Category-PreferenceVideo-Media-Preference
persistent
Member Order
Order-NumberOrder-Creation-DateOrder-Fill-DateShipping-Address-NameShipping-Street-AddressShipping-CityShipping-StateShipping-Zip-CodeShipping-InstructionsOrder-Sub-TotalOrder-Sales-TaxOrder-Shipping-MethodOrder-Shipping-&-Handling-CostOrder-StatusOrder-Prepaid-AmountOrder-Prepayment-Method
persistent
ProductProduct-NumberUPC-Quantity-In-StockProduct-TypeSuggested-Retail-PriceDefault-Unit-PriceCurrent-Special-Unit-PriceCurrent-Month-Units-SoldCurrent-Year-Units-SoldTotal-Lifetime-Units-Sold
persistent
Video Title
ProducerDirectorVideo-CategoryVideo-Sub-CategoryClosed-CaptionedLanguageRunning-TimeVideo-Media-TypeVideo-EncodingScreen-AspectMPA-Rating-Code
persistent
Audio Tilte
ArtistAudio-CategoryAudio-Sub-CategoryNumber-Of-Units-In-PackageAudio-Media-CodeContent-Advisory-Code
persistent
Transaction
Transaction-Reference-NumberTransaction-DateTransaction-TypeTransaction-DescriptionTransation-Amount
persistent
MemberMember-NumberMember-NameMember-StatusMember-Street-AddressMember-PO-BoxMember-CityMember-StateMember-Zip-Code
persistent
Agreement
Agreement-NumberAgreement-Expire-DateAgreement-Active-DateFulfillment-PeriodRequired-Number-Of-Credits
persistent
Game Title
ManufacturerGame-CategoryGame-Sub-CategoryGame-PlatformGame-Media-TypeNumber-Of-PlayersParent-Advisory-Code
persistent
Title
Title-Of-WorkTitle-CoverCatalog-DescriptionCopyright-DateEntertainment-CompanyCredit-Value
persistent
Member Ordered Product
Quantity-OrderedQuantity-ShippedQuantity-BackorderedPurchase-Unit-PriceCredits-Earned
persistent
Merchandise
Merchandise-NameMerchandise-DescriptionMerchandise-TypeUnit-of-Measure
persistent
Promotion
Promotion-NumberPromotion-Release-DatePromotion-StatusPromotion-Type
persistent
<<actor>>Potential Member
persistent
<<actor>>Past Member
Expiration-Date
persistent
Return
persistent
1..*
1binds
1
0..*
Conducts
1
0..*
Haspurchased
0..10..*
Generates0..*
1..*
Features
1
0..*Sold as
0..*
1
Places
1
1..*
Sells
Diagrama de Clases del Sistema de Servicio a Clientes
Actividades Generales del Análisis Orientado Objeto
1. Modelar las funciones del sistema.2. Encontrar e identificar los objetos del
negocio.3. Organizar los objetos e identificar sus
relaciones.4. Modelar el comportamiento de los
objetos.
Diagramas que describen el estado de los objetos
Diagramas de Estados– Los diagramas de estados se utilizan para
modelar el comportamiento dinámico de un objeto particular.
– Ilustran el ciclo de vida de un objeto – los varios estados que un objeto puede asumir y los eventos que causan la transición del objeto de un estado a otro.
estado"PRE-LANZAMIENTO"
estado“VUELO"
“Despegue"
Ejemplo de Estados de un Objeto
Posibles “estados” del Trasbordador Espacial
Diagrama de estados
Modela el ciclo de vida de un solo objeto. Representa los diversos estados que un objeto
puede tener, los eventos que hacen que el objeto cambie de estado en el tiempo, y las reglas que gobiernan la transición del objeto entre los estados.
Especifica de qué estado de un objeto es posible la transición a otro estado.
Los diagramas de estados no son requeridos para todos los objetos. Típicamente, un diagrama de estados se construye solamente para aquellos objetos que tienen estados claramente identificables y un comportamiento complejo.
Diagrama de estados – teléfono
Ocioso Activo
descolgar auricular
colgar auricular
Estado
Estado inicial
TransiciónEvento
Diagrama de estados – casos de uso
Una aplicación útil de este tipo de diagramas consiste en describir la secuencia permitida de eventos externos que reconoce y maneja un sistema dentro del contexto de un caso de uso.
Es útil para describir el orden legal de los eventos externos.
Diagrama de estados – casos de uso
Ejemplos:– En el caso Comprar Productos de la
aplicación del punto de venta, no está permitido efectuar la operación efectuarPagoConTarjeta mientras no haya ocurrido el evento terminarVenta.
– En el caso Procesar Documento en un procesador de texto, no está permitido efectuar la operación Guardar en Archivo mientras no haya ocurrido el evento Crear Archivo Nuevo o Abrir Archivo.
Diagrama de estados – comprar productos
EnEsperadelaVenta
EnEsperadelPago
efectuarPago
Evento del sistema(externo)
IntroduciendoProductosintroducirProducto
terminarVenta
introducirProducto
Order Shipped
Order Released Order Filled
Order Invoiced
PendingIn Process
Order Backordered
Order ClosedMember Order final
state
Member Order finalstate
Member Order initial state
Order pending awaiting payment or additional member information
Order rejected based on Member's past history
Member order archived after 90 days
Invoice sent to member for payment
Response received from memberOrder released
to the warehouse
Order shipped to club member
Order filled by the warehouse
Not all product available
Final payment received
Order submitted
Product received
Diagrama de estadosdel Sistema de Servicio a Clientes
Diagramas que describen el estado de los objetos
Diagramas de Actividades– Los diagramas de actividades se utilizan
para representar gráficamente el flujo secuencial de actividades de un proceso de negocios o un caso de uso.
– También pueden ser utilizados para modelar las acciones que serán realizadas cuando una operación se está ejecutando así como los resultados de dichas acciones.
Input Request Route to Manager
Evaluate Need
Check Budget
[need][budget]
[no need] [no budget
DisapproveRequest
ApproveRequest
Route to Purchasing Agent
Diagrama de Actividades
Diagramas que describen el comportamiento de los objetos
Diagramas de Secuencia– Los diagramas de secuencia representan
gráficamente cómo los objetos interactúan entre sí vía mensajes en la ejecución un caso de uso.
– Ilustran cómo se envían y reciben los mensajes entre los objetos y en qué secuencia.
Eventos y operaciones del sistema
Evento del sistema– Es un hecho externo que un actor realiza y
produce una entrada al sistema.
Operación del sistema– Es una acción que el sistema ejecuta en
respuesta a una evento del sistema.
Los eventos de un sistema (y sus operaciones asociadas) deben expresarse en el nivel de propósito y no en el nivel del medio físico de entrada o de elementos de la interfaz.
Eventos y operaciones del sistema (2)
Ejemplo:– Cuando un cajero genera un evento
introducirProducto, causa la ejecución de la operación introducirProducto.
El nombre del evento y de la operación son idénticos; la distinción reside en que el evento es el estímulo y la operación es la repuesta (lo mismo sucede con los mensajes y los métodos).
Registro de las operaciones de un sistema
Para determinar el conjunto de operaciones requeridas del sistema se identifican sus eventos.
Cuando se utilizan parámetros, las operaciones son las siguientes: – IntroducirProducto(CUP, Cantidad) – TerminarVenta()– EfectuarPago(monto)
Diagrama de Secuencia – Comprar Productos
Identificar eventos del sistema:– Primero debemos determinar los actores
que interactúan directamente con el sistema de software.
– El cliente interactúa con el cajero, pero no directamente con el sistema TPDV; esto sólo lo hace el cajero.
– Por tanto, el cliente no es un generador de eventos del sistema, sólo el cajero lo es.
Diagrama de Secuencia – Comprar Productos Curso normal de los eventos en el caso
Comprar Productos
: Cajero
:Sistema
1: introducir Producto(CUP, cantidad)
2: terminarVenta()
3: efectuarPago(monto)
Sistema como caja negra
Evento del sistemaInicia una operación de sistema
Actor
Diagrama de Secuencia
También mejora la claridad si el nombre de un evento del sistema comienza con un verbo (agregar, introducir, terminar, efectuar), ya que recalca que los eventos están orientados a comandos.
– Así, terminarVenta es preferible a OprimaTeclaEnter porque capta mejor el propósito de la operación: mantiene un carácter abstracto y no se pronuncia respecto a las decisiones de diseño sobre cuál interfaz sirve para capturar el evento del sistema.
Diagrama de Secuencia
En cuanto a expresar las operaciones en el nivel de propósito, se debe tratar de alcanzar el nivel más alto o la meta final para asignar nombre a la operación. Por ejemplo, respecto a la operación que captura el pago:– IntroducirImporteOfrecido(monto) – deficiente– IntroducirPago(monto) – mejor– EfectuarPago –mejor aún
a Producta Member
Ordera Member
Ordered Productan Order Processor
a Club Member
display member information
validate item
create item
enter item (product number)
select new order
update address (address)
verify member (member number)
Diagrama de Secuencia
Diagrama de Secuencia
Los diagramas de secuencia se utilizan para modelar la lógica de los escenarios de uso.– Un escenario de uso es la descripción de una
manera potencial en que se utilizará el sistema.
Los diagramas de secuencia modelan de una manera visual el flujo de la lógica dentro de un sistema, permitiendo tanto documentar como validar la lógica subyacente.
Se utilizan tanto para el análisis como para el diseño.
Diagrama de Secuencia
La lógica de un escenario de uso puede describir:
– Un caso de uso; la lógica descrita por el curso normal de los eventos o una porción de éste, más unos o más escenarios alternativos.
– Parte de un caso de uso, quizás un curso alternativo.
– Un conjunto de paso con la lógica contenida en varios casos de uso.
• Por ejemplo, un alumno se inscribe en la universidad y además se inscribe inmediatamente en tres cursos.
Diagrama de Secuencia
Elementos de un Diagrama de Secuencia
Los rectángulos en la parte superior del diagrama representan objetos, clases, actores, o casos de uso.
Objetos y Clases– Dado que es posible enviar mensajes tanto a objetos
como a clases, tiene sentido incluir tanto a objetos como a clases en los diagramas de secuencia.• Los objetos responden a los mensajes a través de
la llamada a una operación.• Las clases lo hacen a través de la llamada a una
operación estática.
Actores– Los actores inician y tienen una participación activa en
los escenarios de uso.
Elementos de un Diagrama de Secuencia
Para los objetos, clases y actores se utilizan etiquetas estándar en el formato UML:
Objetos: “nombre:NombreDeLaClase”– Donde “nombre” es opcional (los objetos a
los que no se les da un nombre en el diagrama se llaman objetos anónimos).
Clases: “NombreDeLaClase”
Actores: “NombreActor”
Elementos de un Diagrama de Secuencia
Ejemplo:
Cliente
Elementos de un Diagrama de Secuencia
Las líneas discontinuas que cuelgan de los rectángulos se llaman líneas de vida del objeto, y representan la vida del objeto durante el escenario que está siendo modelado.
Los rectángulos largos y finos en las líneas de vida son rectángulos de invocación a métodos, e indican que operación se debe ejecutar en el objeto/clase que está recibiendo el mensaje.
Elementos de un Diagrama de Secuencia
La "X" en la parte inferior de un rectángulo de invocación es una convención de UML para indicar que un objeto ha sido eliminado de la memoria, típicamente como resultado de recibir un mensaje con el estereotipo <<destroy>>.
Los mensajes se indican como flechas etiquetadas– Cuando el emisor y el receptor de un mensaje es un
objeto o una clase, la etiqueta corresponde al método que se invocará como respuesta al mensaje.
– Si el emisor o el receptor es un actor humano entonces el mensaje se etiqueta con un texto breve que describe la información que está siendo comunicada.
Diagramas que describen el comportamiento de los objetos
Diagramas de Colaboración– Los diagramas de colaboración son
similares a los diagramas de secuencia, pero no se centran en la sincronización o "secuencia" de mensajes, si no que presentan la interacción (o colaboración) entre los objetos en un formato de red.
Diagrama de Colaboración
El diseño orientado a objetos tiene por objetivo definir las especificaciones lógicas del software que cumplan con los requisitos funcionales.
Un paso esencial en esta fase es la asignación de responsabilidades entre los objetos y mostrar como interactúan a través de mensajes.
El diagrama de colaboración presenta el flujo de mensajes entre las instancias y la invocación de métodos.
Diagrama de Colaboración – juego de dados
La figura muestra gráficamente los elementos esenciales del juego, enviando mensajes a las instancias de las clases Jugador y Dado.
:Jugador d1:Dadojugar()
1:r1:= lanzar()
d2:Dado2:r2:= lanzar()
Diagramas de Colaboración y de Secuencia
Los diagramas de colaboración describen las interacciones entre los objetos en un formato de grafo o red:
Los diagramas de secuencia describen las interacciones en una especie de formato de cerca o muro:
Instancia1 : ClaseA Instancia2 : ClaseB
1: mensaje2() 2: mensaje3()mensaje1()
Instancia1 :ClaseA
Instancia2 :ClaseB
mensaje2()
mensaje3()
mensaje1()
Diagramas que describen la implementación de los objetos
Diagramas de Componentes– Los diagramas componentes se utilizan para
representar gráficamente la arquitectura física del sistema. Pueden ser utilizados para demostrar cómo el código de programación se divide en módulos (o componentes).
Client Source Code
Comment
(client.exe)
Drawing Library
Comment
(drawing.dll)dependency
Diagrama de Componentes
Diagramas que describen la implementación de los objetos
Diagramas de Despliegue– Los diagramas del despliegue describen la
arquitectura física del hardware y software en el sistema. Representan las componentes de software, los procesadores, y los dispositivos que forman la arquitectura del sistema.
Application Server - Compaq PIII 500
Client WorkstationHP Kayak XU-400
Database Server - Compaq PIII 500
SAP R/3Comment
Client Source CodeComment
(client.exe)
Oracle 8Comment
TCP/IP
TCP/IP
Diagrama de Despliegue