UML jvo. 1. Disponibilizar uma linguagem de modelação visual expressiva e rigorosa;

Transcrição

1 UML A Unified Modeling Language (UML) é uma linguagem, essencialmente gráfica, para modelar, especificar e documentar elementos de sistemas, não necessariamente informáticos. É um standard reconhecido pelo OMG Object Management Group [ Alguns Objectivos 1. Disponibilizar uma linguagem de modelação visual expressiva e rigorosa; 2. Proporcionar mecanismos de extensibilidade e especialização para estender os artefactos existentes; 3. Ser independente do processo de desenvolvimento e da linguagem de programação; 4. Proporcionar uma base adequada para a compreensão do domínio do problema; 5. Promover o crescimento do mercado OO; 6. Suportar conceitos de desenvolvimento de alto-nível, tais como padrões (patterns), frameworks e componentes / EP / UML - 1

2 UML Diagramas UML Perspectiva do utilizador o Diagramas de Casos de Utilização Use case diagrams Estrutura o Diagrama de Classes; o Diagrama de Objectos; Comportamento o Diagramas de Sequência - Sequence diagrams o Diagramas de Colaboração Colaboration diagrams o Diagramas (de Transicção) de Estados-Statechart diagram o Diagramas de Actividade - Activity diagram Implementação o Diagramas de Componentes Component diagrams o Diagramas de Desdobramento - Deployment diagrams / EP / UML - 2

3 UML Estudo de Caso [Larman, 1997] Âmbito Desenvolver um sistema para a gestão de um terminal de venda retalhista POST: Post Of Sale Terminal. Clientes Uma empresa multinacional. Objectivos O objectivo principal é aumentar a automatização do processo de pagamento 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ásicas Ref. Função Categoria 1.1 Registar o ítem de compra actual Evidente 1.2 Calcular o total de compras, incluíndo taxas e descontos Evidente 1.3 Capturar a informação do ítem comprado usando um Evidente leitor de códigos de barras, ou inserindo manualmente o código universal de produto (UPC). 1.4 Actualizar o valor das existências do produto vendido Escondido 1.5 Registar as vendas feitas Escondido 1.6 O(A) Caixa deve entrar no sistema com um ID e passwd Evidente 1.7 Disponibilizar um mecanismo de gravação persistente. Escondido 1.8 Proporcionar mecanismos comunicação inter-sistemas Escondido 1.9 Mostrar a descrição e preço do item comprado Evidente / EP / UML - 3

4 Funções de pagamento Ref. Função Categoria 2.1 Aceitar pagamentos em dinheiro, através da leitura do Evidente valor pago e do calculo do troco. 2.2 Aceitar pagamentos com cartão de crédito usando um Evidente leitor de cartões, ou inserção manual do número do cartão, com autorização do serviço de autorização exterior acedido por modem. 2.3 Aceitar pagamentos por cheque, inserindo manualmente Evidente a carta de condução, com autorização do serviço de autorização exterior acedido por modem 2.4 Registar os pagamantos com cartão de crédito, uma vez que o total de pagamentos é mantido pelo serviço de autorização exterior. Escondido Atributos de sistema Atributo Descrição Tipo Tempo de Quando se lê um ítem comprado, o seu preço e Restrição resposta descrição deve aparecer dentro de 5 segundos; Interface A interface com o utilizador deve ser feita por janelas de diálogo; Detalhe A interface deve favorecer o uso do teclado (em vez do rato) como meio de navegação Tolerância Deve registar pagamentos a crédito na conta respectiva, Restrição a falhas num periodo de 24 horas, mesmo em caso de falhas. Plataforma Windows NT Detalhe / EP / UML - 4

5 Modelação de requisitos com casos de utilização [Jacobson, 99 - Caps 6 e 7] [Larman, 98 - Cap. 6] Um caso de utilização ("use case") é um padrão de comportamento que um sistema exibe. Um caso de utilização representa uma iteracção típica que um actor tem com o sistema para obter um resultado útil e consiste numa descrição de uma sequência de acções, incluindo variantes, que o sistema executa para proporcionar esse resultado. Um actor é o papel que algo ou alguém desempenha quando interage com o sistema / EP / UML - 5

6 Sumário de passos relativos à captura e modelação de requisitos 1. Depois de listar as funções do sistema, definir a fronteira e identificar os actores (contexto do sistema); 2. Construir o modelo de casos de utilização que consiste de uma descrição global, um ou mais diagramas e de uma descrição de cada caso de utilização Identificar os casos de utilização; 2.2. Escrever todos os casos de utilizaçã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 risco associado, usando um formato estendido essencial ou recorrendo a um 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é aos ciclos de desenvolvimento (ou iterações) em que serão tratados; 2.5. Ordenar os casos de utilizaçã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 que não são específicos de nenhum caso de utilização / EP / UML - 6

7 Exemplos de aplicação relativos ao POST (Não se pretende ser exaustivo) Identificação de actores e casos de utilização Actor Caixa Cliente Gestor Administrador de sistema Caso de utilização Log in Reembolso (Cash out) Compra items Devolve items Start up Shut Down Adiciona novos utilizadores Descrição de alto-nível dos casos de utilização Caso de utilização: Compra items Actores: Cliente (initiator), Caixa Tipo: primário Descrição: Um Cliente chega a um terminal de venda com items para comprar. O Caixa regista os items e recolhe o pagamento. No fim, o Cliente sai com os items comprados. Caso de utilização: Start Up Actores: Gestor Tipo: primário Descrição: Um Gestor liga um POST a fim de o preparar para ser usado pelos Caixas. O Gestor verifica se a data e hora estão correctas, após o que o sistema está pronto a ser usado / EP / UML - 7

8 Descrição estendida do caso Compra items Caso de utilização: Compra items Actores: Cliente (initiator), Caixa Objectivo: Capturar uma venda e seu pagamento Tipo: Primário e essencial Descrição: Um Cliente chega a um terminal de venda com items para comprar. O Caixa regista os items e recolhe o pagamento. No fim, o Cliente sai com os items comprados. Funções: 1.1, 1.2, 1.3, 1.7, 1.9, 2.1, 2.2, 2.3 Casos de utilização: O Caixa deve ter concluído o caso de utilização "Log in" Sequência de eventos típica (ou principal) Acção do Actor 1. Este caso começa quando um Cliente chega a um POST com items para comprar. 2. O Caixa regista cada item. Se existir mais do que um item do mesmo tipo, o Caixa pode registar também a quantidade. 4. Após registar todos os itens, o Caixa indica ao POST que a entrada de items terminou. 6. O Caixa diz o total ao Cliente. Resposta do sistema 3. Determina o preço do item e adiciona a informação do item à transacção de compra corrente. Apresenta a descrição e o preço do item. 5. Calcula e apresenta o total da compra / EP / UML - 8

9 Sequência típica de eventos (cont.) Acção do Actor Resposta do sistema 7. O Cliente escolhe o tipo de pagamento: 7.a. Se pagamento em dinheiro, ver seccção Paga com Dinheiro. 7.b. Se pagamento a crédito, ver secção Paga a Crédito 7.c. Se pagamento com cheque, ver seção Paga com Cheque 11. O Caixa dá o recibo ao Cliente 12. O Cliente sai com os items comprados. 8. Regista a compra total feita. 9. Actualiza os valores das existências 10. Gera um recibo 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 / EP / UML - 9

10 Secção: Paga com dinheiro Sequência típica de eventos Acção do Actor 1. O Cliente faz um pagamento em dinheiro, possivelmente superior ao total da compra. 2. O Caixa regista o dinheiro recebido. 4. O Caixa guarda o dinheiro recebido e retira a demasia. Resposta do sistema 3. Apresenta o valor de troco a devolver ao Cliente. O Caixa entrega a demasia ao Cliente. Sequência alternativa de eventos Linha 1: O Cliente não tem dinheiro suficiente. Pode cancelar a compra ou iniciar outro meio de pagamento. Linha 4: O Caixa não tem dinheiro suficiente para fazer o troco. O Caixa pede dinheiro ao supervisor ou pede ao cliente outra quantia de dinheiro ou outro método de pagamento / EP / UML - 10

11 Secção: Paga a crédito Sequência típica de eventos Acção do Actor 1. O Cliente comunica a sua informação de crédito. Resposta do sistema 2. Gera um pedido de pagamento e envia-o para o Serviço de Autorização de Crédito (SAC). 3. O SAC autoriza o pagamento. 4. Recebe uma resposta de aprovação de crédito do SAC. 5. Regista o pagamento a crédito e a informação de resposta no sistema de contas. (O SAC fica com dinheiro da Loja pelo que esta deve manter o registo desse dinheiro) 6. Mostra a mensagem de autorização concedida. Sequência alternativa de eventos Linha 3: O SAC não autoriza pagamento. Sugere outra forma de pagamento. Secção: Paga com cheque Sequência típica de eventos Acção do Actor 1. O Cliente passa um cheque e identifica-se. 2. O Caixa regista a identificação e pede autorização de pagamento por cheque. Resposta do sistema 3. Gera um pedido de pagamento por cheque e envia-o para a Serviço de Autorização de Cheques (SAX). 4. O SAX autoriza o pagamento. 5. Recebe uma resposta de aprovação do SAX. 6. Indica autorização concedida. Sequência alternativa de eventos Linha 4: SAX não autoriza pagamento. Sugere método de pagamento alternativo / EP / UML - 11

12 Ordenação dos casos de utilização Os ciclos de desenvolvimento (iterações) estão organizados em torno dos casos de utilização. Isto é, a uma iteração é atribuído para desenvolvimento uma versão simplificada de um caso, um caso, ou vários casos. Os casos de utilização necessitam de ser ordenados, já que os mais relevantes, em termos da arquitectura do sistema, deverão ser desenvolvidos primeiro. Os critérios que influenciam a relevância de um caso de utilização para efeitos de ordenação incluem: 1. O impacto significativo na arquitectura do sistema, tal como a adição de muitas 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 novas tecnologias; Exemplo de ordenação de casos para o POST Rank Caso Justificação Elevado Compra Items Pontua em praticamente todos os critérios. Médio Baixo Adiciona novos utilizadores Log In Devolve items Reembolso Start up Shut Down Afecta a segurança Afecta a segurança Afecta as existências Efeito mínimo sobre a arquitectura Depende de outros casos Efeito mínimo sobre a arquitectura / EP / UML - 12

13 UML Versões do caso de utilização Compra Items - Versão 1 Simplificaçõ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 disponibilidades 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ção do POST; As compras efectuadas são guardadas num registo histórico / EP / UML - 13

14 Sequência típica de eventos Acção do Actor 1. Este caso começa quando um Cliente chega a um POST com items para comprar. 2. O Caixa regista o UPC de cada item. Se existir mais do que um item do mesmo tipo, o Caixa pode registar também a quantidade. 4. Após registar todos os itens, o Caixa indica ao POST que a entrada de items terminou. 6. O Caixa diz o total ao Cliente. 7. O Cliente faz um pagamento em dinheiro, possivelmente superior ao total da compra. 8. O Caixa regista o dinheiro recebido. 10. O Caixa guarda o dinheiro recebido e retira a demasia. Resposta do sistema 3. Determina o preço do item e adiciona a informação do item à transacção de compra corrente. Apresenta a descrição e o preço do item. 5. Calcula e apresenta o total da compra. 9. Apresenta o valor de troco a devolver ao Cliente. Gera um recibo. 11. Regista a compra total feita. O Caixa entrega a demasia ao Cliente. 12. O Cliente sai com os items comprados. Versões do caso de utilização Compra Items - Versão 2 Aplicam-se todas as simplificações da versão 1, excepto que o pagamento pode ser com dinheiro, a crédito ou com cheque / EP / UML - 14

15 UML 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 os seguintes elementos: Classe de análise Representa uma abstracção de uma ou mais classes (ou subsistemas) de projecto. Centra-se em requisitos funcionais, deixando requisitos não funcionais para o Projecto; Em geral, estabelece uma interface em termos de responsabilidades (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 utilizaçã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 objectos colaboram para implementar o caso de utilização) / EP / UML - 15

16 Comparação entre o modelo de Casos e o modelo de Análise Modelo de Caso Descrito usando a linguagem do utilizador; Vista externa do sistema; Estruturado em termos de casos de utilização; Proporciona estrutura à vista exterior; Usado como um contrato entre o utilizador e o analista sobre o que o sistema deve ou não deve fazer; É habitual que contenha redundâncias (e inconsistências) entre os requisitios; Captura a funcionalidade do sistema; Define casos de utilização que serão analizados no modelo de análise. Modelo de Análise Descrito usando a linguagem do analista; Vista interna do sistema Estruturado por classes (e pacotes); Proporciona estrutura à vista interna; Usado pelos analistas para compreender como o sistema deve ser projectado e implementado; Não deve conter redundâncias nem inconsistências entre requisitos; Define como implementar a funcionalidade; gera uma entrada para o modelo de projecto. Define realizações de casos de utilização, cada uma das quais representando a análise de um caso do modelo de casos / EP / UML - 16

17 Classes candidatas para a versão 1 do caso Compra Items do POST LinhaItemVenda CatálogoProduto EspecificaçãoProduto quantidade: Inteiro descrição: Texto preço: Quantia upc: Inteiro Venda Loja Item data: Data hora: Tempo endereço: Texto nome: Texto POST Gestor Pagamento total: Quantia Cliente Caixa / EP / UML - 17

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

19 UML Projecto [Jacobson, 99 - Cap. 9] [Larman, 98 - Caps ] O modelo de projecto inclui os seguintes elementos: Classe de projecto Abstracção de uma classe de código. Interface Proporciona uma forma de separar a especificação de funcionalidade da sua implementação. Realização de casos de utilizaçã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 tratados posteriormente durante a implementação. Modelo de desdobramento (deployment) - Distribuição da funcionalidade do sistema pelos recursos computacionais / EP / UML - 19

20 Comparação entre o modelo de Análise e o modelo de Projecto Modelo de Análise Modelo conceptual que ignora aspectos de implementação; Genérico: Aplicável a vários projectos; Estereótipos aplicáveis às classes: «control», «entity» e «boundary»; Menos formal; Desenvolvimento menos dispendioso; Poderá não ser possível manter o modelo de análise durante todo o ciclo de vida do software; Proporciona uma compreensão detalhada dos requisitos; é uma entrada essencial para Projecto. Modelo de Projecto Modelo físico que representa código; Específico de uma implementação; Os estereótipos aplicáveis às classes dependem da linguagem de programação (e.g., «form»); Mais formal; Desenvolvimento mais dispendioso; (5:1 relativamente à análise) Deverá ser mantido durante todo o ciclo de vida do software; Molda o sistema enquanto tenta preservar a estrutura definida pelo modelo de análise / EP / UML - 20

21 Noções de Projecto por Contrato A técnica de Projecto por Contrato ("Design by Contract") foi inicialmente proposta por Bertrand Meyer. Esta técnica é central na linguagem de programação orientada por objectos 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 nunca deverá ser falsa. Tipicamente, num programa as asserções são apenas verificadas durante a fase de testes. Nessa altura, a existência de uma asserção com o valor lógico falso deverá ser considerada um bug. Depois de depurado, um programa nunca deverá assumir que 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óscondições e condições invariantes de instância ou, simplesmente, invariantes. As pré e pós condições aplicam-se aos métodos (ou operações). As invariantes aplicam-se a todas as instâncias (objectos) de uma classe. Uma pré-condição é uma declaração de como esperamos que o estado do programa esteja antes 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. A pré-condição torna explícito quem deverá ser o responsável por fazer o teste: o cliente da função sqrt. Sem esta declaração explícita de responsabilidade poder-se-ia cair num de dois extremos: ausência de testes (quer o cliente quer o construtor da função presumem que a responsabilidade do teste é da outra parte), excesso de testes (quer o cliente quer o construtor efectuam o teste). Uma pós-condição, por vezes também chamada condição objectivo, é uma afirmação de como fica o estado do programa após executada uma operação. No caso da raiz quadrada a pós-condição seria y*y=x. A pós-condição é uma forma conveniente de separar a interface (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 o termo 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) de uma classe. A invariante poderá tornar-se momentaneamente falsa durante a execução de um método mas será restaurada antes que o método termine a sua execução e o seu receptor esteja disponível para receber outra mensagem / EP / UML - 21

22 As asserções assuem particularmente relevo na presença de herança. Um dos problemas de herança é que é possível redefinir os métodos de uma subclasse de forma inconsistente com os métodos da superclasse. A utilização de asserções podem prevenir estes casos. As invariantes de uma classe, bem como as pós-condições de todos os seus métodos, devem aplicar-se a todas as suas subclasses. As subclasses poderão reforçar estas asserções mas não poderão relaxá-las. Por outro lado, as pré-condições não poderão ser fortalecidas mas poderão ser suavizadas. Uma vez que uma instância de uma subclasse (pública) poderá ser usada num programa em todo o lado em que é possível usar uma instância da sua superclasse, uma subclasse deve 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 que funcionasse quando enviada para um objecto de uma superclasse poderia não funcionar para 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 estado do 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ções invariantes poderão ser definidas como restrições. A UML não impõe nenhum formato para a definição destas asserções. Uma possibilidade é usar OCL - Object Constraint Language / EP / UML - 22

23 UML Exemplos de contratos relativos aos eventos de sistema do caso Compra Items - versão 1 - do POST Contrato para entraitem Nome: 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 uma EspecificaçãoProduto, baseada no upc (estabelecimento de associação) Excepções: Se upc é desconhecido indica erro / EP / UML - 23

24 UML Contrato para finalizavenda Nome: finalizavenda() Pré-condição: Pós-condição: Venda.estaCompleta foi alterada para true (modificação de atributo) Excepções: Foi calculado o total de Venda Se actualmente uma Venda não está a ser processada indica erro. Contrato para fazpagamento Nome: 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ção de atributo) Um Pagamento foi associado com a Venda (estabelecimento de associação) A Venda foi associada com a Loja (estabelecimento de associação) Excepções: Foi calculado o troco Se a Venda não está completa indica erro Se o totalentregue for menor do que total de Venda indica erro / EP / UML - 24

25 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, [Meyer, 97] Bertrand Meyer, Object-Oriented Software Construction, Prentice Hall, Ver também [Jacobson, 99] I. Jacobson, G. Booch, J. Rumbaugh, The Unified Software Development Process, Addison-Wesley, Reading, MA, / EP / UML - 25