UML - w3.ualg.ptw3.ualg.pt/~jvo/ep/uml.pdf · jvolivei/ep/ep.html 10-12-2000 / EP / UML - 12 Ordenação dos casos de utilização Os ciclos de desenvolvimento (iterações) estão

UMLjvo

http://w3.ualg.pt/~jvolivei/ep/ep.html 10-12-2000 / EP / UML - 1

UML

A Unified Modeling Language (UML) é uma linguagem,essencialmente gráfica, para modelar, especificar e documentarelementos de sistemas, não necessariamente informáticos.

É um standard reconhecido pelo OMG – Object ManagementGroup [http://www.omg.org].

Alguns Objectivos

1. Disponibili zar uma linguagem de modelação visual expressiva erigorosa;

2. Proporcionar mecanismos de extensibili dade e especializaçãopara estender os artefactos existentes;

3. Ser independente do processo de desenvolvimento e dalinguagem de programação;

4. Proporcionar uma base adequada para a compreensão dodomínio do problema;

5. Promover o crescimento do mercado OO;

6. Suportar conceitos de desenvolvimento de alto-nível, tais comopadrões (patterns), frameworks e componentes.

UMLjvo


Diagramas UML

� Perspectiva do utili zadoro Diagramas de Casos de Utili zação – Use case diagrams

� Estruturao Diagrama de Classes;o Diagrama de Objectos;

� Comportamentoo Diagramas de Sequência - Sequence diagramso Diagramas de Colaboração – Colaboration diagramso Diagramas (de Transicção) de Estados-Statechart diagramo Diagramas de Actividade - Activity diagram

� Implementaçãoo Diagramas de Componentes – Component diagramso Diagramas de Desdobramento - Deployment diagrams

UMLjvo


Estudo de Caso [Larman, 1997]

ÂmbitoDesenvolver um sistema para a gestão de um terminal de vendaretalhista – POST: Post Of Sale Terminal.

ClientesUma empresa multinacional.

ObjectivosO objectivo principal é aumentar a automatização do processo depagamento em lojas do mercado retalhista; Mais especificamente:

� Servir clientes mais rapidamente;� Análise de vendas mais rápida e fiável;� Controlo automático de existências

Funções representativas do sistema (as que serão consideradas)

Funções básicasRef. Função Categor ia1.1 Registar o ítem de compra actual Evidente1.2 Calcular o total de compras, incluíndo taxas e descontos Evidente1.3 Capturar a informação do ítem comprado usando um

leitor de códigos de barras, ou inserindo manualmente ocódigo universal de produto (UPC).

Evidente

1.4 Actualizar o valor das existências do produto vendido Escondido1.5 Registar as vendas feitas Escondido1.6 O(A) Caixa deve entrar no sistema com um ID e passwd Evidente1.7 Disponibili zar um mecanismo de gravação persistente. Escondido1.8 Proporcionar mecanismos comunicação inter-sistemas Escondido1.9 Mostrar a descrição e preço do item comprado Evidente

UMLjvo


Funções de pagamentoRef. Função Categor ia2.1 Aceitar pagamentos em dinheiro, através da leitura do

valor pago e do calculo do troco.Evidente

2.2 Aceitar pagamentos com cartão de crédito usando umleitor de cartões, ou inserção manual do número docartão, com autorização do serviço de autorizaçãoexterior acedido por modem.

Evidente

2.3 Aceitar pagamentos por cheque, inserindo manualmentea carta de condução, com autorização do serviço deautorização exterior acedido por modem

Evidente

2.4 Registar os pagamantos com cartão de crédito, uma vezque o total de pagamentos é mantido pelo serviço deautorização exterior.

Escondido

Atr ibutos de sistemaAtr ibuto Descrição TipoTempo deresposta

Quando se lê um ítem comprado, o seu preço edescrição deve aparecer dentro de 5 segundos;

Restrição

Interface A interface com o utili zador deve ser feita por janelasde diálogo;

A interface deve favorecer o uso do teclado (em vez dorato) como meio de navegação

Detalhe

Tolerânciaa falhas

Deve registar pagamentos a crédito na conta respectiva,num periodo de 24 horas, mesmo em caso de falhas.

Restrição

Plataforma Windows NT Detalhe

UMLjvo


Modelação de requisitos com casos de utili zação[Jacobson, 99 - Caps 6 e 7] [Larman, 98 - Cap. 6]

Um caso de utili zação ("use case") é um padrão de comportamento que umsistema exibe.

Um caso de utili zação representa uma iteracção típica que um actor tem como sistema para obter um resultado útil e consiste numa descrição de umasequência de acções, incluindo variantes, que o sistema executa paraproporcionar esse resultado.

Um actor é o papel que algo ou alguém desempenha quando interage com osistema.

UMLjvo


Sumário de passos relativos à captura e modelação de requisitos

1. Depois de li star as funções do sistema, definir a fronteira e identificar osactores (contexto do sistema);

2. Construir o modelo de casos de utili zação que consiste de uma descriçãoglobal, um ou mais diagramas e de uma descrição de cada caso deutili zação.

2.1. Identificar os casos de utili zação;

2.2. Escrever todos os casos de utili zação num formato de alto-nível;classificá-los como primários, secundários ou opcionais;

2.3. Desenhar um Diagrama de Casos;

2.4. Descrever os casos mais críticos, influentes ou com maior riscoassociado, usando um formato estendido essencial ou recorrendo aum diagrama apropriado à complexidade do caso (e.g., diagrama de(transicção) de estados);

Diferir a descrição mais detalhada dos casos menos críticos até aosciclos de desenvolvimento (ou iterações) em que serão tratados;

2.5. Ordenar os casos de utili zação;

3. Obter um conjunto de esboços e protótipos de interfaces;

4. Obter uma descrição suplementar para os requisitos não funcionais quenão são específicos de nenhum caso de utili zação.

UMLjvo


Exemplos de aplicação relativos ao POST(Não se pretende ser exaustivo)

Identifi cação de actores e casos de utili zação

Actor Caso de utili zaçãoCaixa Log in

Reembolso (Cash out)Cliente Compra items

Devolve itemsGestor Start up

Shut DownAdministrador de sistema Adiciona novos utili zadores

Descrição de alto-nível dos casos de utili zação

Caso de utili zação: Compra itemsActores: Cliente (initiator), CaixaTipo: primárioDescrição: Um Cliente chega a um terminal de venda com items

para comprar. O Caixa regista os items e recolhe opagamento. No fim, o Cliente sai com os itemscomprados.

Caso de utili zação: Star t UpActores: GestorTipo: primárioDescrição: Um Gestor liga um POST a fim de o preparar para ser

usado pelos Caixas. O Gestor verifica se a data e horaestão correctas, após o que o sistema está pronto a serusado.

UMLjvo


Descrição estendida do caso Compra items

Caso de utili zação: Compra itemsActores: Cliente (initiator), CaixaObjectivo: Capturar uma venda e seu pagamentoTipo: Primário e essencialDescrição: Um Cliente chega a um terminal de venda com items

para comprar. O Caixa regista os items e recolhe opagamento. No fim, o Cliente sai com os itemscomprados.

Funções: 1.1, 1.2, 1.3, 1.7, 1.9, 2.1, 2.2, 2.3

Casos de utili zação: O Caixa deve ter concluído o casode utili zação "Log in"

Sequência de eventos típica (ou pr incipal)

Acção do Actor Resposta do sistema1. Este caso começa quando um

Cliente chega a um POST comitems para comprar.

2. O Caixa regista cada item.

Se existir mais do que um item domesmo tipo, o Caixa pode registartambém a quantidade.

3. Determina o preço do item eadiciona a informação do item àtransacção de compra corrente.

Apresenta a descrição e o preçodo item.

4. Após registar todos os itens, oCaixa indica ao POST que aentrada de items terminou.

5. Calcula e apresenta o total dacompra.

6. O Caixa diz o total ao Cliente.

UMLjvo


Sequência típica de eventos (cont.)

Acção do Actor Resposta do sistema7. O Cliente escolhe o tipo de

pagamento:7.a. Se pagamento em dinheiro,

ver seccção Paga comDinheiro.

7.b. Se pagamento a crédito, versecção Paga a Crédito

7.c. Se pagamento com cheque,ver seção Paga com Cheque

8. Regista a compra total feita.9. Actualiza os valores das

existências10. Gera um recibo

11. O Caixa dá o recibo ao Cliente12. O Cliente sai com os items

comprados.

Sequência alternativa de eventos

Linha 2: Identificador de Item inválido. Indica erro;

Linha 7: O Cliente não pode pagar. Cancela a transacção de compra.

UMLjvo


Secção: Paga com dinheiro

Sequência típica de eventos

Acção do Actor Resposta do sistema1. O Cliente faz um pagamento em

dinheiro, possivelmente superiorao total da compra.

2. O Caixa regista o dinheirorecebido.

3. Apresenta o valor de troco adevolver ao Cliente.

4. O Caixa guarda o dinheirorecebido e retira a demasia.

O Caixa entrega a demasia aoCliente.

Sequência alternativa de eventos

Linha 1: O Cliente não tem dinheiro suficiente. Pode cancelar a compra ouiniciar outro meio de pagamento.

Linha 4: O Caixa não tem dinheiro suficiente para fazer o troco. O Caixapede dinheiro ao supervisor ou pede ao cliente outra quantia de dinheiro ououtro método de pagamento.

UMLjvo


Secção: Paga a créditoSequência típica de eventosAcção do Actor Resposta do sistema1. O Cliente comunica a sua

informação de crédito.2. Gera um pedido de pagamento e

envia-o para o Serviço deAutorização de Crédito (SAC).

3. O SAC autoriza o pagamento. 4. Recebe uma resposta deaprovação de crédito do SAC.

5. Regista o pagamento a crédito e ainformação de resposta no sistemade contas. (O SAC fica comdinheiro da Loja pelo que estadeve manter o registo dessedinheiro)

6. Mostra a mensagem deautorização concedida.

Sequência alternativa de eventosLinha 3: O SAC não autoriza pagamento. Sugere outra forma de pagamento.

Secção: Paga com chequeSequência típica de eventosAcção do Actor Resposta do sistema1. O Cliente passa um cheque e

identifica-se.2. O Caixa regista a identificação e

pede autorização de pagamentopor cheque.

3. Gera um pedido de pagamento porcheque e envia-o para a Serviçode Autorização de Cheques(SAX).

4. O SAX autoriza o pagamento. 5. Recebe uma resposta deaprovação do SAX.

6. Indica autorização concedida.Sequência alternativa de eventosLinha 4: SAX não autoriza pagamento. Sugere método de pagamentoalternativo.

UMLjvo


Ordenação dos casos de utili zação

Os ciclos de desenvolvimento (iterações) estão organizados em torno doscasos de utili zação. Isto é, a uma iteração é atribuído para desenvolvimentouma versão simpli ficada de um caso, um caso, ou vários casos.

Os casos de utili zação necessitam de ser ordenados, já que os maisrelevantes, em termos da arquitectura do sistema, deverão ser desenvolvidosprimeiro.

Os critérios que influenciam a relevância de um caso de utili zação paraefeitos de ordenação incluem:

1. O impacto significativo na arquitectura do sistema, tal como a adição demuitas classes ou a consideração de muitos serviços;

2. A relação entre informação obtida e o esforço realizado;

3. O risco, funções complexas ou temporalmente críticas;

4. Necessidade de investigação significativa ou aplicação de novastecnologias;

Exemplo de ordenação de casos para o POSTRank Caso JustificaçãoElevado Compra Items Pontua em praticamente todos os

critérios.Médio Adiciona novos utili zadores

Log InDevolve items

Afecta a segurançaAfecta a segurançaAfecta as existências

Baixo ReembolsoStart upShut Down

Efeito mínimo sobre a arquitecturaDepende de outros casosEfeito mínimo sobre a arquitectura

UMLjvo


Versões do caso de utili zação Compra Items - Versão 1

Simpli ficações, objectivos e suposições

� Só pagamentos em dinheiro;

� Sem manutenção das existências;

� Loja individual, independente de uma grande organização;

� Entrada manual do UPC; sem leitor de código de barras;

� Sem calculo de taxas;

� Sem descontos;

� Sem controlo de acesso; O Caixa não tem que entrar no sistema (Log in);

� Não existe registo de clientes nem dos seus hábitos de compra;

� Sem controlo das disponibili dades de caixa;

� O recibo mostra nome e endereço da loja, data e instante de compra;

� O recibo não mostra nem a identificação do Caixa, nem a identificaçãodo POST;

� As compras efectuadas são guardadas num registo histórico.

UMLjvo


Sequência típica de eventosAcção do Actor Resposta do sistema1. Este caso começa quando um

Cliente chega a um POST comitems para comprar.

2. O Caixa regista o UPC de cadaitem.

Se existir mais do que um item domesmo tipo, o Caixa pode registartambém a quantidade.

3. Determina o preço do item eadiciona a informação do item àtransacção de compra corrente.

Apresenta a descrição e o preçodo item.

4. Após registar todos os itens, oCaixa indica ao POST que aentrada de items terminou.

5. Calcula e apresenta o total dacompra.

6. O Caixa diz o total ao Cliente.7. O Cliente faz um pagamento em

dinheiro, possivelmente superiorao total da compra.

8. O Caixa regista o dinheirorecebido.

9. Apresenta o valor de troco adevolver ao Cliente.

Gera um recibo.10. O Caixa guarda o dinheiro

recebido e retira a demasia.

O Caixa entrega a demasia aoCliente.

11. Regista a compra total feita.

12. O Cliente sai com os itemscomprados.

Versões do caso de utili zação Compra Items - Versão 2Aplicam-se todas as simpli ficações da versão 1, excepto que o pagamentopode ser com dinheiro, a crédito ou com cheque.

UMLjvo


Análise[Jacobson, 99 - Cap. 8] [Larman, 98 - Caps. 8-14]

O resultado da análise é o modelo de análise (ou conceptual) que inclui osseguintes elementos:

� Classe de análiseRepresenta uma abstracção de uma ou mais classes (ou subsistemas) deprojecto.

� Centra-se em requisitos funcionais, deixando requisitos nãofuncionais para o Projecto;

� Em geral, estabelece uma interface em termos de responsabili dades(descrição textual de comportamento);

� Define atributos e relacionamentos de alto-nível;

� Podem usar-se estereótipos para especializar uma classe de análise:� Classe de Fronteira (Boundary class)� Classe de Entidade (Entity class)� Classe de Controlo (Control class)

� Realização de casos de utili zação - Análise

� Diagrama de classes

� Diagramas de interacção (diag. colaboração e diag. sequência)

� Fluxo de eventos (descrição textual de como os objectoscolaboram para implementar o caso de utili zação)

UMLjvo


Comparação entre o modelo de Casos e o modelo de Análise

Modelo de Caso Modelo de AnáliseDescrito usando a linguagem doutili zador;

Descrito usando a linguagem doanalista;

Vista externa do sistema; Vista interna do sistema

Estruturado em termos de casos deutili zação; Proporciona estrutura àvista exterior;

Estruturado por classes (e pacotes);Proporciona estrutura à vistainterna;

Usado como um contrato entre outili zador e o analista sobre o que osistema deve ou não deve fazer;

Usado pelos analistas paracompreender como o sistema deveser projectado e implementado;

É habitual que contenharedundâncias (e inconsistências)entre os requisitios;

Não deve conter redundâncias neminconsistências entre requisitos;

Captura a funcionalidade dosistema;

Define como implementar afuncionalidade; gera uma entradapara o modelo de projecto.

Define casos de utili zação queserão analizados no modelo deanálise.

Define realizações de casos deutili zação, cada uma das quaisrepresentando a análise de um casodo modelo de casos.

UMLjvo


Classes candidatas para a versão 1 do caso Compra Items do POST

LinhaItemVenda CatálogoProduto EspecificaçãoProduto

Venda Loja Item

Pagamento Cliente

POST Gestor

Caixa

quantidade: Inteiro descrição: Textopreço: Quantiaupc: Inteiro

data: Datahora: Tempo

endereço: Textonome: Texto

total: Quantia

UMLjvo


Diagrama de classes - Análise para a versão 1 do caso Compra Items

UMLjvo


Projecto[Jacobson, 99 - Cap. 9] [Larman, 98 - Caps. 15-22]

O modelo de projecto inclui os seguintes elementos:

� Classe de projectoAbstracção de uma classe de código.

� InterfaceProporciona uma forma de separar a especificação de funcionalidade dasua implementação.

� Realização de casos de utili zação - Projecto

Diagrama de classes; Diagramas de interacção; Fluxo de eventos; Requisitos de implementação - descrição textual de requisitos

capturados na realização de projecto de casos; a serem tratadosposteriormente durante a implementação.

� Modelo de desdobramento (deployment) - Distribuição da funcionalidadedo sistema pelos recursos computacionais.

UMLjvo


Comparação entre o modelo de Análise e o modelo de Projecto

Modelo de Análise Modelo de ProjectoModelo conceptual que ignoraaspectos de implementação;

Modelo físico que representacódigo;

Genérico: Aplicável a váriosprojectos;

Específico de uma implementação;

Estereótipos aplicáveis às classes:«control», «entity» e «boundary»;

Os estereótipos aplicáveis às classesdependem da linguagem deprogramação (e.g., «form»);

Menos formal; Mais formal;

Desenvolvimento menosdispendioso;

Desenvolvimento mais dispendioso;(5:1 relativamente à análise)

Poderá não ser possível manter omodelo de análise durante todo ociclo de vida do software;

Deverá ser mantido durante todo ociclo de vida do software;

Proporciona uma compreensãodetalhada dos requisitos; é umaentrada essencial para Projecto.

Molda o sistema enquanto tentapreservar a estrutura definida pelomodelo de análise.

UMLjvo


Noções de Projecto por Contrato

A técnica de Projecto por Contrato ("Design by Contract") foi inicialmente proposta porBertrand Meyer. Esta técnica é central na linguagem de programação orientada porobjectos Eiffel, também desenvolvida por Meyer, cf. [Meyer, 1997].

Esta técnica baseia-se na noção de asserção. Uma asserção é uma afirmação que nuncadeverá ser falsa. Tipicamente, num programa as asserções são apenas verificadas durantea fase de testes. Nessa altura, a existência de uma asserção com o valor lógico falsodeverá ser considerada um bug. Depois de depurado, um programa nunca deverá assumirque as asserções estão a ser testadas.

A técnica de Projecto por Contrato usa três tipos de asserções: pré-condições, pós-condições e condições invariantes de instância ou, simplesmente, invariantes. As pré epós condições aplicam-se aos métodos (ou operações). As invariantes aplicam-se a todasas instâncias (objectos) de uma classe.

Uma pré-condição é uma declaração de como esperamos que o estado do programa estejaantes de executada uma operação. Por exemplo, considere-se a função raiz quadrada, y =sqrt(x). A pré-condição - que terá de ser verificada necessariamente à priori - é x>=0. Apré-condição torna explícito quem deverá ser o responsável por fazer o teste: o cliente dafunção sqrt. Sem esta declaração explícita de responsabili dade poder-se-ia cair num dedois extremos: ausência de testes (quer o cliente quer o construtor da função presumemque a responsabili dade do teste é da outra parte), excesso de testes (quer o cliente quer oconstrutor efectuam o teste).

Uma pós-condição, por vezes também chamada condição objectivo, é uma afirmação decomo fica o estado do programa após executada uma operação. No caso da raiz quadradaa pós-condição seria y*y=x. A pós-condição é uma forma conveniente de separar ainterface (o que se faz) da implementação (como se faz).

A partir das noções de pré e pós-condição é possível estabelecer uma definição para otermo excepção: Uma excepção ocorre quando uma operação é chamada com a sua pré-condição satisfeita mas não pode satisfazer a sua pós-condição.

Uma invariante é uma afirmação que é verdadeira para todos os objectos (instâncias) deuma classe. A invariante poderá tornar-se momentaneamente falsa durante a execução deum método mas será restaurada antes que o método termine a sua execução e o seureceptor esteja disponível para receber outra mensagem.

UMLjvo


As asserções assuem particularmente relevo na presença de herança. Um dos problemasde herança é que é possível redefinir os métodos de uma subclasse de forma inconsistentecom os métodos da superclasse. A utili zação de asserções podem prevenir estes casos. Asinvariantes de uma classe, bem como as pós-condições de todos os seus métodos, devemaplicar-se a todas as suas subclasses. As subclasses poderão reforçar estas asserções masnão poderão relaxá-las. Por outro lado, as pré-condições não poderão ser fortalecidas maspoderão ser suavizadas.

Uma vez que uma instância de uma subclasse (pública) poderá ser usada num programaem todo o lado em que é possível usar uma instância da sua superclasse, uma subclassedeve estar preparada para aceitar os mesmos argumentos que a sua superclasse aceitaria.Assim, as pré-condições dos seus métodos não deverão ser mais fortes do que as pré-condições dos métodos da sua superclasse. Caso contrário, uma mensagem quefuncionasse quando enviada para um objecto de uma superclasse poderia não funcionarpara um objecto da uma subclasse que redefinisse o método correspondente. No entanto,é aceitável que uma subclasse proporcione um método mais geral, i.e., com uma pré-condição menos restrita, que funcione num maior número de situações.

Uma vez que as pós-condições descrevem o que o cliente pode assumir acerca do estadodo sistema após uma operação, as pós-condições numa subclasse devem ser, pelo menos,tão fortes quanto as pós-condições correspondentes da superclasse.

A técnica de Projecto por Contrato é útil na definição de interfaces claras.

A UML permite definir pré e pós-condições para os métodos de uma classe. As condiçõesinvariantes poderão ser definidas como restrições. A UML não impõe nenhum formatopara a definição destas asserções. Uma possibili dade é usar OCL - Object ConstraintLanguage.

UMLjvo


Exemplos de contratos relativos aos eventos de sistema do casoCompra Items - versão 1 - do POST

Contrato para entraItemNome: entraItem(upc: Inteiro, Quantidade: Inteiro)

Pré-condição: upc é um número válido

Pós-condição: Se nova Venda, uma Venda foi criada (criação de instância)

Se nova Venda, uma Venda associada com o POST(estabelecimento de associação)

Uma LinhaItemVenda foi criada (criação de instância)

Uma LinhaItemVenda foi associada à Venda(estabelecimento de associação)

quantidade foi atribuída a LinhaItemVenda.quantidade(modificação de atributo)

Uma LinhaItemVenda foi associada a umaEspecificaçãoProduto, baseada no upc (estabelecimento deassociação)

Excepções: Se upc é desconhecido indica erro

UMLjvo


Contrato para finalizaVendaNome: finalizaVenda()

Pré-condição:

Pós-condição: � Venda.estaCompleta foi alterada para true (modificação deatributo)

� Foi calculado o total de VendaExcepções: Se actualmente uma Venda não está a ser processada indica

erro.

Contrato para fazPagamentoNome: fazPagamento(totalEntregue: Número)

Pré-condição: totalEntregue > 0

Pós-condição: � Um pagamento foi criado (criação de instância)

� totalEntregue foi atribuído a Pagamento.total (modificaçãode atributo)

� Um Pagamento foi associado com a Venda(estabelecimento de associação)

� A Venda foi associada com a Loja (estabelecimento deassociação)

� Foi calculado o trocoExcepções: � Se a Venda não está completa indica erro

� Se o totalEntregue for menor do que total de Venda indicaerro

UMLjvo


Referências

[Larman, 98] Craig Larman, Applying UML and Patterns: an Introduction to Object-Oriented Analysis and Design, Prentice Hall PTR, Upper Saddle River,NJ, 1998.

[Meyer, 97] Bertrand Meyer, Object-Oriented Software Construction, Prentice Hall ,1997. Ver também http://www.eiffel.com.

[Jacobson, 99] I. Jacobson, G. Booch, J. Rumbaugh, The Unified Software DevelopmentProcess, Addison-Wesley, Reading, MA, 1999.

Documents

UML - w3.ualg.ptw3.ualg.pt/~jvo/ep/uml.pdf · jvolivei/ep/ep.html 10-12-2000 / EP / UML - 12 Ordenação dos casos de utilização Os ciclos de desenvolvimento (iterações) estão