Programa do Módulo 2. Métodos Orientados a Objetos - MOO

Transcrição

1 3.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) Diagramas UML Diagrama de Caso de Uso Processo Unificado (RUP) Métodos Orientados a Objetos - MOO O paradigma objeto apareceu nos anos 80 como uma solução revolucionária para o desenvolvimento de software. 3.2 Os MOO tem sua origem ligada ao trabalho de Grady Booch sobre o projeto de software com a linguagem Ada. Software organizado como um grafo, com os arcos representando as relações de utilização e os nós representando os objetos Relação de herança adicionada posteriormente. Trabalhos sobre as linguagens originaram o aparecimento dos trabalhos sobre análise. Desde o início dos anos 90 diversos métodos de análise e projeto orientados a objetos foram propostos. Coad e Yourdon: variedade de conceitos e simplicidade; G. Booch/J. Rumbaugh: grande número de conceitos e detalhes Booch Projeto / Rumbaugh Análise Linguagem UML: Padronização Diversos Métodos RUP

2 Métodos Orientados a Objetos 3.3 Unified Modeling Language - UML UML é uma linguagem padrão para a visualização, especificação, construção e documentação dos elementos de um sistema de software. UML pode ser utilizado em todas as etapas do ciclo de desenvolvimento de um sistema de software. UML pode ser utilizado com diferentes tecnologias de implementação. UML combina o melhor de: Conceitos de Modelagem de Dados (Diagramas Entidade-Relacionamento) Modelagem Comercial (work flow) Modelagem Objeto Modelagem por Componentes Métodos Orientados a Objetos Porquê UML? 3.4 Necessidade de uma Linguagem de Modelagem Diagramas com notação clara Modelos variados/pontos de vista Flexibilidade Linguagem unificadora Necessidade de um Processo de Modelagem (dirigido pelos casos de uso) Modelos e visões integrando a arquitetura Interativo e incremental Pode ser adaptado... Para Documentar As necessidades A arquitetura A Concepção A codificação e os testes... Em diferentes Ambientes de Sistemas de Informação: SI de empresas Sistemas bancários, financeiros Telecomunicações, transportes Aeroespacial, científico Eletrônica, médico Serviços Web

3 1997 Métodos Orientados a Objetos Revisão Revisão Menor Novembro: Aceitação Setembro: submissão final Janeiro: submissão OMG Especificação na Internet Gênese de UML UML 1.3 UML 1.2 UML 1.1 UML 1.0 UML 0.9 Método Unificado 0.8 UML 2.0 UML 1.5 UML Outros Métodos OOAD Booch OMT Rumbaugh... OOSE Jacobson... Parceiros Métodos Orientados a Objetos UML Contribuições 3.6 Rumbaugh Booch Jacobson Meyer Pré e pós condições Harel State charts Gamma, et.al Frameworks, padrões, notas Fusion Descrição de operações, numeração de mensagens Embley Classes Singleton, vista de alto nível Wirfs-Brock Responsabilidades Shlaer- Mellor Ciclo de vida de objetos Selic, Gullekson, Ward ROOM (Real-Time Object-Oriented Modeling) Odell Classificação

4 Métodos Orientados a Objetos - UML Conceitos de Base Mecanismos Comuns: UML define um pequeno número de mecanismos comuns que garantem a integridade conceitual da notação: Notas Mecanismos de Extensão: Estereótipos, Restrições e Etiquetas Relações de Dependência Nota: é um símbolo gráfico que contém informações, um comentário, sobre um elemento, geralmente em forma textual Cada nota é ligada a um elemento de modelagem por uma linha tracejada. Nota 3.7 Métodos Orientados a Objetos UML Conceitos de Base Mecanismos Comuns 3.8 Mecanismos de Extensão: Estereótipo: é um mecanismo de extensibilidade de UML, permitindo uma meta-classificação de um elemento de UML. Possibilita aos usuários adicionar novos tipos de elementos de modelagem, permitindo uma extensão controlada, pelos usuários, dos elementos de UML. Um elemento do modelo associado a um estereótipo herda as definições do estereótipo Pode-se definir estereótipos para classes, associações, operações, estados, pacotes, etc. Objetivo: classificar estes elementos e reutilizar as descrições O nome do estereótipo é colocado entre guillemets antes do nome do elemento ao qual é aplicado o estereótipo. Restrições: é uma relação semântica qualquer entre elementos de modelagem definindo proposições que devem ser mantidas verdadeiras para garantir a validade do sistema modelado. Pode-se usar linguagem natural, pseudo-código ou OCL (linguagem formal) UML não especifica nenhuma sintaxe particular para as restrições. Uma restrição é definida por uma expressão booleana entre parênteses aplicada a um elemento CEP <<Comprador>> Cliente Informação {ou-exclusivo}

5 Métodos Orientados a Objetos - UML - Conceitos de Base Mecanismos Comuns 3.9 Etiquetas: é um par (nome, valor) que adiciona uma nova propriedade a um elemento de modelagem, permitindo a extensão dos atributos destes elementos. A propriedade pode representar uma informação de administração (autor, data, etc.), de geração de código. A adição de uma etiqueta é feita da seguinte maneira: {nome = valor}. Relações de Dependência: define uma relação de utilização unidirecional entre dois elementos de modelagem, chamados respectivamente fonte e alvo da relação. Indicam uma situação em que uma mudança no elemento alvo acarreta uma mudança no elemento fonte. Representada por uma flecha pontilhada do elemento fonte para o elemento alvo. Pessoal {Autor=JCFJ Versão=2.1 Data=10/04/02} Elemento Fonte Elemento Alvo Métodos Orientados a Objetos - UML Pacotes 3.10 Oferecem um mecanismo geral para a partição de modelos e para o reagrupamento de elementos de modelagem, assim como para o encapsulamento destes. Cada pacote corresponde a um sub-conjunto do modelo e contém, segundo o modelo, classes, objetos, relações, componentes ou nós, assim como os diagramas associados. Elementos em pacotes diferentes podem ter o mesmo nome. Cada pacote é um reagrupamento de elementos segundo um critério puramente lógico. Dois estereótipos podem ser aplicados: <<Categoria>>: pacotes ligados a uma visão lógica Aspectos estáticos dinâmicos do sistema. <<Sub-sistema>>: pacotes ligados a uma visão de implementação Organização dos módulos no ambiente de desenvolvimento. Nome do Pacote <<Categoria>> <<Sub-Sistema>>

6 Métodos Orientados a Objetos - UML - Pacotes 3.11 A forma geral de um sistema (arquitetura) é expressa pela hierarquia de pacotes e pela rede de relações de dependência entre pacotes. Um pacote pode conter outros pacotes, sem limite de níveis, e um nível pode conter pacotes e outros elementos de modelagem (Ex.: classes). O relacionamento entre pacotes é representado através de uma relação de dependência orientada do pacote cliente em direção do pacote fornecedor Esta relação entre os dois pacotes significa que ao menos uma classe de um pacote cliente utiliza serviços oferecidos por ao menos uma classe do pacote fornecedor. Fornecedor Cliente Conteúdo de Pacotes 3.12 Um Pacote, University Artifacts, contém outro pacote e cinco classes. University Artifacts Student Artifacts Course Professor Schedule Student CourseOffering

7 Métodos Orientados a Objetos - UML - Pacotes 3.13 Pacotes - Exemplos UML pour l analyse d un système d information C. Morley, J. Hugues, B. Leblanc - DUNOD Métodos Orientados a Objetos - UML Diagramas UML I Diagramas de Casos de Uso: representam as funções do sistema do ponto de vista do usuário. Diagramas de Classes: representam a estrutura estática em termos de classes e relações. Diagramas de Objetos: representam os objetos e suas relações Correspondem a diagramas de colaboração simplificados, sem a representação do envio de mensagens. Diagramas de Interação: utilizados para capturar os cenários: Diagramas de Seqüência: representação temporal dos objetos e suas interações. Diagramas de Colaboração (Comunicação): representação espacial dos objetos, das relações e das interações. Diagramas de Estado: representam o comportamento de uma classe em termos de estados. Diagramas de Atividades: representam o comportamento de uma operação em termos de ações. Diagramas de Componentes: representam os componentes físicos de uma aplicação. Diagramas de Instalação: representam a distribuição dos componentes nos dispositivos de hardware. Diagramas de Pacotes: representam os pacotes do sistema com ou sem seus constituintes. Diagramas de Visão Geral de Interação: composição de diagramas de atividades e seqüência, nos quais as atividades são substituídas por pequenos diagramas de seqüência Diagramas de Temporização: representam restrições de temporização, constituem uma outra forma dos diagramas de interação. Diagramas de Estruturas Compostas: representam a decomposição hierárquica de uma classe em sua estrutura interna. UML 1.5 UML

8 Métodos Orientados a Objetos - UML Diagramas UML II % da UML resolve 80% dos problemas Jacobson. Estruturas Compostas Visão Geral da Interação Diagramas Pacotes Classes Objetos Seqüência Comunicação Atividades Temporização Caso de Uso Estado Componentes Instalação Métodos Orientados a Objetos - UML Diagramas UML II % da UML resolve 80% dos problemas Jacobson. Estruturas Compostas Visão Geral da Interação Diagramas Pacotes Classes Objetos Seqüência Comunicação Atividades Temporização Caso de Uso Estado Componentes Instalação

9 Métodos Orientados a Objetos - UML Diagramas UML II % da UML resolve 80% dos problemas Jacobson. Diagramas UML 1.5. Diagramas Classes Objetos Seqüência Comunicação Atividades Caso de Uso Estado Componentes Instalação Métodos Orientados a Objetos UML Diagramas UML 3.18 Diagramas Diagramas UML 1.5. Classes Objetos Seqüência Comunicação Atividades Caso de Uso Estado Componentes Instalação Aspectos funcionais e dinâmicos: Diagrama de Caso de Uso: atores, utilização do sistema. Aspectos estruturais estáticos: Diagrama de Classes : classes e relações estáticas. Diagrama de Objetos: objetos e associações.

10 Métodos Orientados a Objetos UML Diagramas UML 3.19 Diagramas Aspectos dinâmicos: Diagrama de Seqüência: visão temporal das interações. Diagrama de Comunicação (colaboração): visão espacial das interações. Diagrama de Estados: comportamento dos objetos. Diagrama de Atividades: fluxo de controle interno das operações, descrição dos Classes Objetos Seqüência Comunicação Atividades Caso de Uso Estado Componentes Instalação casos de uso. Métodos Orientados a Objetos UML Diagramas UML 3.20 Diagramas Aspectos implantação: Classes Objetos Seqüência Comunicação Atividades Caso de Uso Estado Componentes Instalação Diagrama de Componentes: codificação. Diagrama de Instalação: implantação, distribuição.

11 Métodos Orientados a Objetos UML Diagramas UML 3.21 Analisar através de Casos de Uso, Casos de Uso (Diagramas de Atividades), Cenários: Colaboração e Seqüência Métodos Orientados a Objetos UML Diagramas UML Comportamento do Sistema 3.22 Todo sistema interage com pessoas ou outros sistemas Esta interação resulta em um resultado previsível Seu Comportamento. O Comportamento do Sistema é a maneira pela qual este age e reage e engloba as ações e atividades do sistema. Em UML o Comportamento do Sistema é capturado com Casos de Uso. Casos de Uso descrevem a interação entre o sistema e o ambiente ou partes do ambiente.

12 Métodos Orientados a Objetos UML 3.23 Diagramas de Casos de Uso (Use Cases) I Idéia de Ivar Jacobson sendo um modelo que descreve os Requisitos Funcionais de um sistema em termos de Casos de Uso. Um modelo que apresenta as funcionalidades do sistema (Casos de Uso) e o ambiente que interage com o sistema (Atores). Student View Report Card Register for Courses Login Diagramas de Caso de Uso descrevem através de ações e reações, o comportamento de um sistema do ponto de vista dos usuários, possibilitando a definição dos limites de um sistema e das relações entre o sistema e o ambiente. & JP mp & Métodos Orientados a Objetos UML 3.24 Diagramas de Casos de Uso (Use Cases) II Permitem aos usuários estruturar e articular seus desejos: Definição da maneira através da qual eles irão interagir com o sistema; Determinação das informações que serão manipuladas; Descrição do que deve ser feito para se obter o resultado esperado. Casos de uso são utilizados em todo o ciclo de vida de um sistema, desde a análise dos requisitos até a implementação Após a aprovação do modelo pelo cliente tem-se definido o que o sistema faz e o que o cliente quer O modelo pode ser usado então ao longo do desenvolvimento para as discussões com o cliente. Utilização: Participantes: entendimento do sistema. Projetistas: base para seu trabalho e como uma visão geral (overview) do sistema. Testadores: como uma base para a geração das atividades de teste o mais cedo possível. Escritores de Documentação: como uma base para a escrita dos manuais de usuários. Arquitetos: modelo a partir do qual se pode identificar funcionalidades arquiteturais significativas.... & JP mp &

13 Métodos Orientados a Objetos - UML 3.25 Diagramas de Casos de Uso (Use Cases) III O formalismo dos casos de uso, baseado na utilização da linguagem natural, é naturalmente acessível aos usuários, facilitando a comunicação Cliente Desenvolvedor. Um caso de uso é utilizado na representação dos requisitos do sistema Representa uma maneira específica de utilizar um sistema; Constitui a imagem de uma funcionalidade do sistema, ativada em resposta a um estímulo de um agente externo. Diferentes níveis de atores (principal, secundário, hardware, sistema) Relações (comunicação, uso, extensão) Componentes: Ator: representa um papel interpretado por uma pessoa ou algo que interage com o sistema. Casos de Uso: modelam um diálogo entre os atores e o sistema, representando as funcionalidades que serão oferecidas aos atores pelo sistema A coleção dos casos de uso de um sistema representa todas as maneiras através das quais o sistema pode ser utilizado. Métodos Orientados a Objetos - UML Diagramas de Casos de Uso Benefícios do Diagrama de Casos de Uso 3.26 Comunicação Identificação Verificação Comunicação Caso de Uso Identificação Verificação Usuário Final Especialista do Domínio Usuários

14 Métodos Orientados a Objetos - UML Diagramas de Casos de Uso O que é um Ator? 3.27 Atores representam papéis que os usuários do sistema podem desempenhar Podem representar uma pessoa, uma máquina, ou outro sistema. Eles podem realizar um intercâmbio de informações com o sistema. Eles podem fornecer informações ao sistema. Eles podem ser um recipiente passivo de informações. Eles são determinados através da observação dos usuários diretos do sistema, daqueles responsáveis por sua utilização e por sua manutenção, assim como dos sistemas que interagem com o sistema sendo desenvolvido Atores são descritos por pequenos textos em linguagem natural. Atores não fazem parte do sistema, eles são Externos ao sistema. Ator Métodos Orientados a Objetos - UML Diagramas de Casos de Uso O que é um Caso de Uso? 3.28 É uma seqüência de ações que o sistema realiza e que conduzem a um resultado observável para um ator em particular. Um caso de uso modela O QUÊ o sistema deve fazer e não Como. Um caso de uso modela um diálogo entre um ou mais atores e o sistema. Um caso de uso descreve as ações que o sistema toma para entregar algo de valor para o ator. Casos de uso servem para modelar o comportamento de um elemento, sistema, subsistemas, classe. Casos de uso podem ser apresentados com diferentes estereótipos: normal, lógica de negócio, realização, etc. Um caso de uso tem uma série de propriedades que inclui: breve descrição, fluxo de eventos, requisitos especiais, diagramas de atividades, etc. Caso de Uso

15 Métodos Orientados a Objetos - UML Diagramas de Casos de Uso Casos de Uso e Atores 3.29 Um caso de uso modela um diálogo entre atores e o sistema. Um caso de uso é iniciado por um ator para invocar uma funcionalidade do sistema Um caso de uso pode iniciar uma comunicação com um ator, normalmente neste caso um ator não humano. Atores podem se conectar a casos de uso UNICAMENTE por associações Associações indicam que atores e casos de uso se comunicam, cada um deles podendo enviar e receber mensagens. A seta na ponta da associação é opcional e indica simplesmente QUEM inicia a comunicação. Associação Caso de Uso Ator Métodos Orientados a Objetos - UML Diagramas de Casos de Uso Como você leria este Diagrama? 3.30 View Report Card Student Professor Register for Courses Login Select Courses to Teach Submit Grades De que casos de uso um Student participa? E um Professor? E o Course Catalog? Se Charlie for um estudante e professor, que casos de uso ele executa? Descreva a funcionalidade deste sistema. Course Catalog Registrar Billing System Maintain Professor Information Maintain Student Information Close Registration Descreva os relacionamentos dos casos de uso Close Registration e Select Courses to Teach. Qual caso de uso precisa ser executado primeiramente, Register for Courses ou View Report Card?

16 Métodos Orientados a Objetos - UML Diagramas de Casos de Uso 3.31 Exemplo 1: Reservar um vôo em uma data precisa O cliente interroga o sistema, seja passando em uma agência, seja via internet, para garantir que ele pode fazer a reserva desejada. A reserva pode ser feita para um transporte de passageiros (um ou diversos) ou para o transporte de carga. Uma solução sendo encontrada, o sistema registra a reserva (nome do(s) passageiro(s) e/ou característica da(s) carga(s)) e realiza o pagamento através do meio que convier ao cliente (dinheiro, cheque, cartão de crédito). O ou os bilhetes correspondentes são entregues, diretamente na agência, pelo correio, ou disponibilizados na aeroporto. Cliente Reservar Informação é atachada a todo UC, para definir Seu papel e conteúdo Métodos Orientados a Objetos - UML Diagramas de Casos de Uso Exemplo 1 Requisitos 3.32 (Sistema) RESERVAR Cliente Interrogar no guichê Interrogar possibilidade-vôo Interrogar via internet Generalização/Especialização segundo o modo de acesso Componentes são somente os elementos presentes na análise de requisitos Visão Análise de Requisitos: Um ator, o cliente O UC RESERVAR decomposto como pacote-diagrama de UC RESERVAR

17 Métodos Orientados a Objetos - UML Diagramas de Casos de Uso 3.33 (Sistema) RESERVAR Interrogar no guichê Cliente Interrogar possibilidade-vôo Registrar reserva Interrogar via internet Visão Análise de Requisitos Métodos Orientados a Objetos - UML Diagramas de Casos de Uso 3.34 (Sistema) RESERVAR Interrogar no guichê Cliente Interrogar possibilidade-vôo Registrar reserva Interrogar via internet Registrar carga Registrar passageiros Especialização segundo o objeto do transporte Visão Análise de Requisitos

18 Métodos Orientados a Objetos - UML Diagramas de Casos de Uso 3.35 (Sistema) RESERVAR Interrogar no guichê Cliente Interrogar possibilidade-vôo Registrar reserva Pagar Interrogar via internet Registrar carga Registrar passageiros Visão Análise de Requisitos Métodos Orientados a Objetos - UML Diagramas de Casos de Uso 3.36 (Sistema) RESERVAR Interrogar no guichê Cliente Interrogar possibilidade-vôo Registrar reserva Pagar Interrogar via internet Registrar carga Registrar passageiros Caso de Uso em diversos níveis O Caso de Uso é representado como um Pacote Obter bilhetes Visão Análise de Requisitos Ativação do sistema

19 Métodos Orientados a Objetos - UML Diagramas de Casos de Uso Exemplo 1 Análise (Sistema) RESERVAR 3.37 Interrogar no guichê Gestor interface Interrogar via internet Interrogar possibilidade-vôo Sub-sistemas externos Gestor dos vôos Cliente Adiciona-se os componentes descobertos no processo de análise Visão Análise (refinamento) especificação Métodos Orientados a Objetos - UML Diagramas de Casos de Uso 3.38 (Sistema) RESERVAR Interrogar no guichê Gestor interface Interrogar possibilidade-vôo Interrogar via internet Registrar reserva Pagar Registrar carga Registrar passageiros Gestor dos vôos Cliente Gestor financeiro Visão Análise

20 Métodos Orientados a Objetos - UML Diagramas de Casos de Uso 3.39 (Sistema) RESERVAR Interrogar no guichê atores secundário Gestor interface principal Interrogar possibilidade-vôo Interrogar via internet Registrar reserva Pagar Registrar carga Registrar passageiros Gestor dos vôos Atores secundários Cliente Obter bilhetes Gestor financeiro Visão Análise Métodos Orientados a Objetos - UML Diagramas de Casos de Uso 3.40 Relações nos Diagrama de Caso de Uso I Inexistência de relação de Composição-Decomposição: (para o refinamento) mas um UC se descreve em detalhes através de um pacote associado ao UC a detalhar Este pacote é descrito por Diagramas de UC que definem o conteúdo do pacote (T3.36). Inclusão «include»: (para a reutilização) A inclui B <<include>> e lhe utiliza Relação de dependência entre UC de um mesmo diagrama O UC, incluso, pode ser utilizado Caso de Uso A Caso de Uso B em outros diagramas; (exemplo tipo: Validar e Registrar pedido) Extensão «extend»: (para a extensibilidade) B estende A, em... Relação de dependência entre UC de um mesmo <<extend>> diagrama O UC, que estende, deve ter um ponto de inserção no UC estendido ; (exemplo: Consultar as promoções ) Caso de Uso A Caso de Uso B Generalização : (para os mecanismos de herança e versões) relação hierárquica (uma especialização garante a função do UC pai) que possibilita que se tenha diversos ambientes com o mesmo objetivo. (exemplo : Interrogar no guichê e Interrogar via Internet)

21 Métodos Orientados a Objetos - UML Diagramas de Casos de Uso 3.41 Relações nos Diagrama de Caso de Uso II [FK02] Deve-se utilizar Inclusão quando um comportamento estiver sendo utilizado em dois ou mais casos de uso diferentes. Deve-se utilizar Generalização quando se deseja descrever, sem muito rigor, uma variação do comportamento normal de um caso de uso. Deve-se utilizar Extensão quando se deseja descrever com rigor, declarando o que pode ser estendido, uma variação do comportamento normal de um caso de uso. Métodos Orientados a Objetos - UML Diagramas de Casos de Uso include e extend Definição UML include: Uma relação de um caso de uso de base para um caso de uso de inclusão, especificando como o comportamento do caso de uso de base contém o comportamento do caso de uso de inclusão. O comportamento é inserido no local onde é definido no caso de uso de base. O caso de uso de base depende da execução do comportamento do caso de uso de inclusão, mas não de sua estrutura (i.e., atributos ou operações). extend Um relacionamento de um caso de uso de extensão para uma caso de uso de base, especificando como o comportamento definido para o caso de uso de extensão aumenta (sujeito a condições especificadas na extensão) o comportamento definido para o caso de uso de base. O comportamento é inserido no local definido pelo ponto de extensão no caso de uso base. O caso de uso base não depende da execução do comportamento do caso de uso de extensão.

22 Métodos Orientados a Objetos - UML Diagramas de Casos de Uso Exemplo 1 Projeto 3.43 Sistema de Reserva Sub-sistema Gestão de reservas Tele-sistema Agente de reserva Agência <<include>> <<include>> <<include>> Reservar <<include>> Validar pedido Registrar pedido Adiciona-se os componentes descobertos no processo de projeto Cliente Editar bilhetes Gerir pagamentos Registrar passageiros Registrar carga Métodos Orientados a Objetos - UML Diagramas de Casos de Uso Exemplo 1 Extensão: Sistemas Evolutivos 3.44 Interrogar possibilidade-vôo Pontos de extensão. Pacotes. Viagens Nacionais Interrogar via internet <<extend>> (Pacotes, Viagens Nacionais) 1. O caso de uso Consultar as promoções estende o caso de uso Interrogar via internet. 2. A extensão é permitida unicamente para algumas funcionalidades. 3. O pontos de inserção, que definem o que pode ser estendido, são declarados no caso de uso base e na associação entre os casos de uso. 4. Um caso de uso pode ter vários pontos de extensão e um caso de uso de extensão pode aumentar um ou mais destes pontos de extensão. Fonte: [FK02] Consultar as promoções

23 Métodos Orientados a Objetos - UML Diagramas de Casos de Uso Descrição dos Casos de Uso 3.45 MODELO X: Fluxo de eventos para o caso de uso <nome do caso de uso>; X.1 Breve Descritivo X.2: Pré-condições: condições que devem ser verificadas para que o caso de uso possa ser iniciado; X.3 Atores Envolvidos X.4: Fluxo principal; X.5: Sub-fluxos (quando se puder aplicar); X.6: Fluxos alternativos. APLICAÇÃO AO CASO DE USO GERIR PAGAMENTOS Fluxo de eventos para o caso de uso Gerir Pagamentos 1.1 Descrição: este caso de uso aborda a gestão de pagamentos. 1.2: Pré-condições: para que este caso de uso seja executado o caso de uso Reservar já deve ter sido executado. 1.3 Atores Envolvidos: Cliente, Agente de Reserva. 1.4: Fluxo principal: Este caso de uso se inicia quando um pagamento tiver que ser realizado. Caso o meio de pagamento não apresente fundos (E1) o caso finaliza. Pode-se escolher entre pagar com cartão (CARTAO) ou cheque (CHEQUE). Se for escolhido CARTAO o sub-fluxo S1-Pagar com Cartao será executado : Sub-fluxos S1-Pagar com cartao: o sistema apresenta uma janela para entrada dos dados e o : Fluxos alternativos E1: o meio de pagamento do cliente apresenta problemas e portanto... Métodos Orientados a Objetos - UML Diagrama de Atividades 3.46 Um Diagrama de Atividades pode ser utilizado para capturar as atividades e ações realizadas em um caso de uso Descrição gráfica do fluxo de eventos. É essencialmente um diagrama de fluxo que mostra o fluxo de controle de uma atividade ou ação para outra. Ele será introduzido aqui e detalhado futuramente para outras utilizações. APLICAÇÃO AO CASO DE USO GERIR PAGAMENTOS Fluxo de eventos para o caso de uso Gerir Pagamentos 1.1 Descrição: este caso de uso aborda a gestão de pagamentos. 1.2: Pré-condições: para que este caso de uso seja executado o caso de uso Reservar já deve ter sido executado. 1.3 Atores Envolvidos: Cliente, Agente de Reserva. 1.4: Fluxo principal: Este caso de uso se inicia quando um pagamento tiver que ser realizado. Caso o meio de pagamento não apresente fundos (E1) o caso finaliza. Pode-se escolher entre pagar com cartão (CARTAO) ou cheque (CHEQUE). Se for escolhido CARTAO o sub-fluxo S1-Pagar com Cartao será executado : Sub-fluxos S1-Pagar com cartao: o sistema apresenta uma janela para entrada dos dados e o : Fluxos alternativos E1: o meio de pagamento do cliente apresenta problemas e portanto... Inicialização S1 S2 &

24 Métodos Orientados a Objetos UML Diagramas de Atividades O que é uma Atividade? 3.47 O comportamento é expresso como um fluxo de execução via seqüenciamento de unidades subordinadas Unidades subordinadas incluem atividades aninhadas e em último nível ações individuais. Ações constituem atividades primitivas que podem ser compreendidas como a menor unidade computacional que pode ser apresentada. Atividades e Ações podem conter expressões com restrições booleanas que restringem seu início e término Atividades: <<Precondition>> e <<Postcondition>> e Ações: <<localprecondition>> e <<localpostcondition>>. Atividade p <<Precondition>> Restrição Booleana Atividade n Atividade m <<Postconditon>> Restrição Booleana Métodos Orientados a Objetos UML Diagramas de Atividades Diagrama de Atividades: Exemplo 3.48 Processamento Concorrente Sentinela Check Schedule Assign to Course Select Course [ add course ] [ delete course ] Check Pre-requisites [ checks completed ] [ checks failed ] Resolve Conflicts Decisão Delete Course Atividade/Ação Barra de Sincronização (Fork) Barra de Sincronização (Join) Transição Update Schedule

25 Métodos Orientados a Objetos UML Revisão 3.49 O que é Comportamento do Sistema? O que é um Diagrama de Caso de Uso? Quais são seus benefícios? O que é um Ator? Um Caso de Uso? O que é um Diagrama de Atividades? Métodos Orientados a Objetos - UML Diagramas de Casos de Uso 3.50 Exercício: Sistema de Controle de Pedidos Uma empresa pretende desenvolver um Sistema de Informação para a gerência dos pedidos recebidos pela empresa. Este sistema de informação deve ser capaz de controlar o cadastro dos clientes, dos pedidos e dos produtos com todas as funcionalidades características (inclusão, alteração, supressão). Para realizar qualquer operação com o sistema o funcionário deve ter realizado o login no sistema. No sistema um login é caracterizado por um username e uma password. Os Clientes que serão gerenciados pelo SI podem ser do tipo Cliente Corporativo ou Cliente Pessoal. Cada Cliente pode estar associado a diversos Pedidos, mas um Pedido está associado unicamente a um Cliente. Um Pedido é composto por diversas Linhas de Pedido e cada Linha de Pedido logicamente só pode fazer parte de um único Pedido. As linhas de Pedido nascem e morrem com os Pedidos. Cada Linha de Pedido está associada a unicamente um Produto, mas um Produto pode estar associado a diversas Linhas de Pedido. Clientes Corporativos são definidos por um código, um nome, um endereço, um nome de contato, uma classe de crédito e um limite de crédito. Clientes Pessoais são definidos por um código, um nome, um endereço, e um número de cartão de crédito. Um Pedido é definido por uma data, um preço e um número. Cada Linha do Pedido é definida por uma quantidade e um preço e cada Produto é definido por um código, uma descrição e um preço.

26 Métodos Orientados a Objetos UML - Exercício: Sistema de Controle de Pedidos Diagramas de Casos de Uso I 3.51 Métodos Orientados a Objetos UML - Exercício: Sistema de Controle de Pedidos Diagramas de Casos de Uso II 3.52 Fluxo de eventos para o caso de uso Inserir Cliente 1.1 Descrição: este caso de uso aborda o procedimento adotado para o cadastro de clientes no sistema. 1.2: Pré-condições: para que este caso de uso seja executado o caso de uso Logar deve ter sido executado; o funcionário já deve ter feito o login no sistema. 1.3 Atores Envolvidos: Funcionário. 1.4: Fluxo principal: Este caso de uso se inicia quando o funcionário se loga no Sistema de Registro e entre seu/sua senha. O sistema verifica se a senha é válida (E-1) e solicita ao funcionário que defina o tipo de cliente a ser cadastrado, Corporativo ou Pessoal. O funcionário entra o tipo desejado: Corporativo (CC) ou Pessoal (CP). Se o tipo de cliente for Corporativo (CC), o sub-fluxo S-1: Adicionar Cliente Corporativo será executado. Se o tipo de cliente for Pessoal (CP), o sub-fluxo S-2: Adicionar Cliente Pessoal será executado. 1.5: Sub-fluxos S1-Inserir Cliente Corporativo: o sistema apresenta uma janela para entrada dos seguintes dados, código (E2), nome, endereço, nome de contato, classe de crédito e limite de crédito. O funcionário salva os dados e o caso de uso reinicia. S2-Inserir Cliente Pessoal: o sistema apresenta uma janela para entrada dos seguintes dados, código (E2), um nome, um endereço, e um número de cartão de crédito. O funcionário salva os dados e o caso de uso reinicia. 1.6: Fluxos alternativos E1: um usuário ou senha inválido foi fornecido. O funcionário pode fornecer novamente o username e senha ou terminar o caso de uso E2: houve uma tentativa de cadastro de um cliente já cadastrado. A situação é informada e o caso de uso se reinicia.

27 Métodos Orientados a Objetos UML - Exercício: Sistema de Controle de Pedidos Diagrama de Atividades 3.53 Caso de Uso Inserir Cliente Métodos Orientados a Objetos UML Bibliografia 3.54 [FK02] Martin Fowler e Kendall Scott, UML Essencial 2 ª Edição, Bookman, [FOO04] Martin Fowler, UML Essencial 3 ª Edição, Bookman, [MED04] Ernani Medeiros, Desenvolvendo Software com UML2.0, Pearson Makron Books, 2004 [IBM04] IBM Corporation, Essentials of Visual Modeling with UML 2.0, Material disponibilizado através do programa University da IBM. [UML04] Object Management Group OMG, UML 2.0: Infrastructure Specification, Acessado em 04/2004.