Análise e Projeto de Sistemas

  • 3,321 views
Uploaded on

Análise e Projeto de Sistemas

Análise e Projeto de Sistemas

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,321
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
183
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Introdução a UML Definição (1/2) • A UML (Unified Modeling Language) é: – Linguagem de modelagem utilizada para especificar, visualizar, construir e documentar os artefatos de um Análise e Projeto de Sistemas sistema de software; – Unificação das notações dos métodos de Booch, OMT e OOSE, assim como as melhores idéias de um grupo de metodologistas; – Padrão industrial para a modelagem em todo o ciclo Aula expositiva 04 de desenvolvimento de software. – Sistema de notação dirigido à modelagem de sistemas orientados a objetos. Professor José Luiz Bastos – Captura a estrutura de sistemas orientados a objetos e utiliza diversos diagramas para expressá-la e fornecer múltiplas visões daqueles. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Introdução a UML Introdução a UML Definição (2/2) Modelagem visual (1/3)• A UML tem se tornado um padrão mundial utilizado • Veja a seguinte descrição: por desenvolvedores, autores e fornecedores de – A classe Aluno possui os seguintes atributos: ferramentas CASE, pois procura integrar as melhores práticas existentes no mercado para matrícula (string), nome (string), data de nascimento especificar, visualizar e construir os artefatos de (date), data de matrícula (date), valor da mensalidade sistemas de software. (real);• A UML é aplicável em: – E as seguintes operações: – Modelagem de processos de negócio; matricular aluno, reajustar mensalidade (que recebe – Modelagem de casos de uso; como parâmetro o percentual de reajuste), trancar – Modelagem de classes e objetos; matricula, emitir boleto de pagamento (que recebe – Modelagem de interação entre objetos; como parâmetro o mês/ano de referência). – Modelagem de componentes; – Modelagem de implantação de componentes. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 1
  • 2. Introdução a UMLModelagem visual (2/3) Diagramas da UML 2.0 • Cada diagrama da UML tem como objetivo analisar o sistema sob uma perspectiva. • Alguns apresentam uma visão externa do sistema, outros apresentam uma visão mais interna do sistema com características mais técnicas ou detalhadas de partes do mesmo. • Os diferentes diagramas da UML permitem a descoberta de erros e a avaliação da integração entre os modelos do sistema ainda em projeto. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.Diagramas da UML 2.0 Diagramas da UML 2.0 Diagrama de Caso de uso • Esse diagrama é utilizado para representar a especificação funcional do sistema e se popularizou devido à sua notação gráfica simples e à sua descrição em linguagem natural, já que o seu propósito primário é descrever as funções essenciais do sistema, o seu comportamento dinâmico, bem como os seus limites e abrangência. • Ajuda a especificar, visualizar e documentar as características, funções e serviços do sistema através da perspectiva do usuário e de uma linguagem simples, possibilitando a compreensão do comportamento externo do sistema por qualquer pessoa. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 2
  • 3. Diagramas da UML 2.0 Diagramas da UML 2.0 Diagrama de Caso de uso Diagrama de Caso de uso• As características anteriores permitem que o diagrama de casos de uso seja utilizado nas etapas de Levantamento e Análise de Requisitos e que seja apresentado durante as reuniões iniciais com os clientes, como uma forma de ilustrar o comportamento do sistema, facilitar a compreensão dos usuários e auxiliar na identificação de possíveis falhas de especificação. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagramas da UML 2.0 Diagramas da UML 2.0 Diagrama de Caso de uso Diagrama de Caso de uso• Ementa desta aula: SISTEMA: – Sistema; – Requisitos do Sistema; – Caso de Uso; – Fluxos do Caso de Uso; – Fronteira do Sistema; – Ator; – Lista de Atores; – Relacionamentos; – Documentação de Casos de Uso; – Requisitos Não Funcionais; – Engenharia de Requisitos. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 3
  • 4. Diagramas da UML 2.0 Diagramas da UML 2.0 Diagrama de Caso de uso Diagrama de Caso de uso• Requisitos do Sistema: • Desenvolvedor: – Um requisito descreve uma condição com a qual o sistema – O que o é esperado desse sistema? deve estar conforme; • Usuário: – Esta condição pode ser uma necessidade dos usuários, – Eu tenho uma loja de peças. Gostaria que o meu processo estabelecida em um contrato, uma norma ou padrão, uma de vendas fosse interligado com meu estoque e que eu especificação, formalizado em algum documento; pudesse, a qualquer momento, alterar valores das formas – UML: Um requisito é uma funcionalidade desejada, uma de pagamento. Posso oferecer descontos a alguns tipos de propriedade ou um comportamento do sistema; clientes, mas preciso autorizar essa operação. – Uma vez que o Analista levante os requisitos com o usuário, – No fim do mês quero um relatório dos produtos que mais é necessário documentá-los para entendimento e validação; venderam. Preciso também saber a estatística de vendas – Essa documentação deve servir de base não ambígua para por forma de pagamento. toda a equipe de desenvolvimento; – De tempos em tempos deve aparecer na tela do sistema – A documentação de requisitos evita que informações uma promoção relâmpago que dê um brinde ao cliente. importantes se percam. – Preciso que o sistema controle os pedidos também. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagramas da UML 2.0 Diagramas da UML 2.0 Diagrama de Caso de uso Diagrama de Caso de uso• O que é ambíguo ou não compreensível • Utilizando a modelagem de casos de uso, o nessa descrição? desenvolvedor deve separar as – Que tipos de clientes podem receber descontos? funcionalidades do sistema; – Como seria feita esta autorização de desconto e por • Essas funcionalidades agrupam um conjunto quem? de ações que tenham um objetivo bem – Que quantidade de produtos deve aparecer no relatório dos mais vendidos? definido; – A estatística leva em conta qual período (semanal, • Os casos de uso representam essas quinzenal, mensal, etc.)? funcionalidades. – Quanto tempo significa “de tempos em tempos”? – Quais pedidos precisam ser controlados: os dos clientes ou os feitos aos fornecedores? © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 4
  • 5. Diagramas da UML 2.0 Diagramas da UML 2.0 Diagrama de Caso de uso Diagrama de Caso de uso Algumas funcionalidades que caberiam para o exemplo dado:• Sistema de Vendas: – Consultar informações sobre um produto; – Efetuar reserva; – Emitir comprovante de reserva; – Efetuar venda; – Emitir nota fiscal; – Realizar fechamento do caixa. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagramas da UML 2.0 Diagramas da UML 2.0 Diagrama de Caso de uso Diagrama de Caso de uso • Cada caso de uso possui um conjunto de ações que precisam ser executadas para que o objetivo da funcionalidade seja alcançado; • No caso de efetuar venda: identificar o vendedor, identificar o produto, a quantidade vendida, etc; • Essas ações constituem os fluxos que são realizados pelos casos de uso para disponibilizar o resultado desejado. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 5
  • 6. Diagramas da UML 2.0 Diagramas da UML 2.0 Diagrama de Caso de uso Diagrama de Caso de uso• Fluxo principal: Exemplo: Caso de Uso “Emitir Saldo”: – Descreve uma seqüência de ações que serão Fluxo principal: executadas, considerando que nada de errado 1. O sistema realiza a leitura do cartão ocorrerá durante a execução da seqüência (o chamado caminho “feliz” do caso de uso); magnético do correntista; – Apenas 1 por caso de uso; 2. O sistema solicita a digitação da senha; 3. O sistema valida a senha digitada;• Fluxos alternativos: 4. O correntista seleciona a opção de saldo; – Representam sub-itens do fluxo principal; 5. O sistema questiona o tipo de saldo: conta – Representam os tratamentos de exceção; corrente, poupança, aplicações; – Nenhum ou vários por caso de uso. 6. O sistema processa e mostra o saldo solicitado pelo cliente. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagramas da UML 2.0 Diagramas da UML 2.0 Diagrama de Caso de uso Diagrama de Caso de usoFluxo alternativo Problema na leitura do cartão Fluxo alternativo Senha inválida: magnético:1. Se o sistema não conseguir ler os dados do 1. Se a senha digitada pelo correntista não for cartão magnético, tentar novamente por, no igual à senha cadastrada no sistema, máximo, mais duas vezes; informar ao mesmo e solicitar nova digitação.2. Caso persista o problema, encerrar o caso Esse processo pode ser repetido por no de uso. máximo três tentativas (incluindo a primeira). Após a terceira tentativa, a conta do usuário deve ser bloqueada e o caso de uso encerrado. Inclusão: Bloquear Conta. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 6
  • 7. Diagramas da UML 2.0 Diagramas da UML 2.0 Diagrama de Caso de uso Diagrama de Caso de usoFluxo alternativo Conta inexistente: TENHA EM MENTE!!!! • Ao modelarmos um sistema, precisamos saber até que ponto devemos nos preocupar;1. Se o correntista não possuir o tipo de conta selecionada, informar ao mesmo e encerrar o • Esses pontos-limite são a fronteira do sistema. Exemplo: caso de uso. – Imagine que estamos modelando um Sistema de Controle de Vendas; – Em algum momento o Sistema de Controle de Vendas emite o faturamento semanal ou mensal de cada vendedor para o Departamento Pessoal; – Não é responsabilidade do Sistema de Controle de Vendas saber o que o Departamento Pessoal fará com essa informação. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagramas da UML 2.0 Diagramas da UML 2.0 Diagrama de Caso de uso Diagrama de Caso de uso • Os sistemas recebem e enviam informações FRONTEIRA para o mundo externo através de suas fronteiras; • Alguém ou algo deve ser responsável por enviar e/ou receber informações do sistema; • Na modelagem de casos de uso, esse papel externo é exercido por um ator. Esse ator representa um papel que pode ser: – Uma pessoa; – Um grupo de pessoas; – Um outro sistema; – Sensores. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 7
  • 8. Diagramas da UML 2.0 Diagramas da UML 2.0 Diagrama de Caso de uso Diagrama de Caso de uso• Ator: • Um ator representa um papel exercido por – Representa qualquer coisa que interaja com o sistema, um usuário ou outro sistema ao interagir com ou seja, que troque dados ou eventos com o sistema; o sistema em questão. Exemplo: – Atores não fazem parte do sistema; – Uma pessoa (João) pode assumir o papel de cliente – Atores podem ser usuários ou outros sistemas; ao realizar um saque em um caixa de auto- – Atores identificam elementos externos ao sistema; atendimento; – Atores delimitam as fronteiras do sistema; – A mesma pessoa (João) pode assumir o papel de – Atores podem ativar os casos de uso ou não. operador ao realizar a manutenção de um caixa de auto-atendimento. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagramas da UML 2.0 Diagramas da UML 2.0 Diagrama de Caso de uso Diagrama de Caso de uso • Outro exemplo: – Em um Sistema de Controle Acadêmico, a rotina de atualizar a frequência dos alunos pode ser executada pelos funcionários da secretaria, pelo próprio professor ou pelo Sistema de Avaliação On-line; – Esses papéis são representados por atores. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 8
  • 9. Diagramas da UML 2.0 Diagramas da UML 2.0 Diagrama de Caso de uso Diagrama de Caso de uso• Casos de uso: • Casos de uso: – Devem descrever uma rotina bem definida do sistema; – Devem identificar com quais atores interagem, com – Devem ser totalmente compreensíveis pela equipe e isso o projetista tem informação para criar os perfis de pelos usuários; acesso ao sistema; – Devem ser utilizados durante todo o processo de – Devem especificar como alcançar a realização de um desenvolvimento: procedimento, sem relacionar detalhes de • Criação dos modelos de análise e projeto; implementação; • Criação dos modelos de implementação; – Exemplo: • Criação das especificações de testes do sistema. • O cliente seleciona na lista o produto desejado. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagramas da UML 2.0 Diagramas da UML 2.0 Diagrama de Caso de uso Diagrama de Caso de uso• Relacionamentos: Relacionamentos: – Não devem representar validações que todo sistema já • Entre casos de uso: possuir por padrão: – Generalização; • Exemplo: checar se a data é uma data válida do calendário; – Extensão; – Inclusão; – Devem expressar validações que refiram às regras de negócio; • Entre atores: • Exemplo: a data de rescisão do contrato deve estar – Generalização; dentro do mês corrente; – Pode-se iniciar a modelagem por uma lista de casos • Entre atores e casos de uso: de uso ou uma lista de atores. – Associação. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 9
  • 10. Diagramas da UML 2.0 Diagramas da UML 2.0 Diagrama de Caso de uso Diagrama de Caso de uso• Associação: – Ocorre entre um ator e um caso de uso; – Representa a interação do ator com o caso de uso. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagramas da UML 2.0 Diagramas da UML 2.0 Diagrama de Caso de uso Diagrama de Caso de uso• Extensão: • Exemplo: Caso de Uso “Efetuar Venda”; – Ocorre entre casos de uso; Fluxo Principal: – Indica que um deles (caso de uso base) terá seu 1. ... procedimento acrescido no ponto de extensão 2. Escolher a forma de pagamento; especificado; 3. Se cliente VIP, calcular desconto especial; – Os pontos de extensão são rótulos que aparecem nos Extensão: Efetuar desconto especial; fluxos dos casos de uso; 4. Apresentar o valor total; – É permitido colocar diversos pontos de extensão no mesmo caso de uso. 5. ... © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 10
  • 11. Diagramas da UML 2.0 Diagramas da UML 2.0 Diagrama de Caso de uso Diagrama de Caso de uso• Quando usar pontos de extensão: • Exemplo: no cadastro de uma venda, a rotina – Para expressar rotinas de exceção; de desconto só pode ser executada pelo – Para expressar fluxos alternativos; gerente. – Para separar um comportamento obrigatório de outro opcional; – Para separar um trecho do caso de uso que será usado somente em determinadas condições; – Para separar trechos que dependam da interação com um determinado ator. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagramas da UML 2.0 Diagramas da UML 2.0 Diagrama de Caso de uso Diagrama de Caso de uso• Inclusão: • Exemplo: Caso de Uso “Matricular nos – Ocorre entre casos de uso; cursos”; – Indica que um deles terá o seu procedimento copiado Fluxo Principal: em um local especificado em outro caso de uso; 1. ... – São usados quando existem ações que servem a mais 2. O aluno digita a sua matrícula; de um caso de uso; 3. O sistema verifica se a matrícula é válida e ativa; – Evita a cópia de trechos idênticos nos fluxos de mais Inclusão: Validar matrícula; de um caso de uso; 4. Se matrícula é válida o sistema apresenta nos cursos; – Ganha-se tempo em modelagem, implementação e manutenção. 5. … © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 11
  • 12. Diagramas da UML 2.0 Diagramas da UML 2.0 Diagrama de Caso de uso Diagrama de Caso de uso• Generalização: – Ocorre entre casos de uso ou entre atores; – Representa dois elementos semelhantes com um deles realizando um pouco mais; – É o mesmo conceito de herança da orientação a objetos: • Um caso de uso no qual C2 herda de C1, significa que C1 é mais genérico e C2 é mais específico; – Exemplo de generalização entre atores: • Aluno, Aluno Matriculado, Aluno Ouvinte. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagramas da UML 2.0 Diagramas da UML 2.0 Diagrama de Caso de uso Diagrama de Caso de uso IMPORTANTE: • Os atores representam os papéis realizados pelos usuários, e não a pessoa do usuário; – Certo: Gerente, Funcionário, Estudante, Professor; – Errado: Pedro, João, Maria, José. • Uma vez identificado o caso de uso, descreva seu fluxo principal; • A partir do fluxo principal identifique e descreva os fluxos alternativos; • Caso descubra fluxos comuns utilize inclusão; • Para casos de uso muito complexos utilize extensão. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 12
  • 13. Diagramas da UML 2.0 Diagramas da UML 2.0 Diagrama de Caso de uso Diagrama de Caso de uso• Organizando o modelo com pacotes: • Organizando o modelo com pacotes: © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagramas da UML 2.0 Diagrama de Caso de uso• Organizando o modelo com pacotes: Análise e Projeto de Sistemas Aula expositiva 05 Professor José Luiz Bastos © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 13
  • 14. Introdução a UML Introdução Diagrama de classes (1/36)• O diagrama de classes é considerado o mais • Uma classe é representada por um retângulo importante diagrama da UML, pois serve de com três seções: base para a maioria dos outros diagramas – Nome da classe; desta linguagem de modelagem. Ele oferece – Atributos; uma visão estática do sistema que permite a – Operações. visualização das classes que o compõem, seus atributos e as operações, bem como os relacionamentos entre as mesmas. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Introdução a UML Introdução a UML Diagrama de classes (2/36) Diagrama de classes (3/36)• Proteção de dados visa garantir o acesso • Um atributo é uma propriedade de uma apenas sobre operações e atributos classe que descreve um conjunto de valores disponibilizados pela interface da classe; que as instâncias da classe, objetos, podem – Modificadores de acesso: Public (+); atribuir a essa propriedade. – Protected (#); – Package (~); – Private (-). © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 14
  • 15. Introdução a UML Introdução a UML Diagrama de classes (4/36) Diagrama de classes (5/36)• Um atributo derivado é um atributo cujo • Um atributo estático é um atributo cujo valor valor pode ser calculado baseado no valor de é compartilhado por todas as instâncias, outro(s) atributo(s): objetos, da classe: – Atributo objA.média. – Atributo Funcionário.PISO_SALARIAL. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Introdução a UML Introdução a UML Diagrama de classes (6/36) Diagrama de classes (7/36)• Um atributo não estático possui um valor • Uma operação é um serviço que pode ser único para cada objeto, instância da classe: requisitado por qualquer objeto da classe – Atributo objA.nome. para obter um comportamento: – Operação objA.obterNome(). Operações © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 15
  • 16. Introdução a UML Introdução a UML Diagrama de classes (8/36) Diagrama de classes (9/36)• Uma operação abstrata é aquela que não • Uma operação estática é independente de possui um método que a implemente na objeto e acessa apenas atributos estáticos; classe: • O acesso a operações estáticas é – Operação objA.obterIdade(); independente de objeto:• Uma classe que possui uma ou mais – Funcionário.obterPisoSalarial(). operações abtratas é dita classe abstrata: – Classe Pessoa. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Introdução a UML Introdução a UML Diagrama de classes (10/36) Diagrama de classes (11/36)• Um estereótipo define um novo elemento de • A especialização de objetos segundo os 3 modelagem em termos de um elemento estereótipos propostos por Jacobson auxilia inicial; na construção de sistemas fáceis de serem• Algumas vezes é necessário acrescentar estendidos e alterados; novos elementos ao modelo para torná-lo • Estereótipos propostos por Jacobson: mais aderente ao domínio da aplicação; – Fronteira;• Os novos elementos são definidos a partir – Controle; – Entidade. dos elementos primitivos já existentes na UML. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 16
  • 17. Introdução a UML Introdução a UML Diagrama de classes (12/36) Diagrama de classes (13/36) • Uma classe de fronteira modela a comunicação entre a vizinhança de um sistema e seus componentes internos; • As classes de fronteira provêem a interface com o usuário ou outro sistema; • Classes de fronteira típicas: – Janelas e relatórios (interface com o usuário); – Protocolos de comunicação (interface com o sistema); – Interface com dispositivos de hardware. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Introdução a UML Introdução a UML Diagrama de classes (14/36) Diagrama de classes (15/36)• Classes de entidade: • Classes de controle: – Modelam itens importantes de informação: – Modelam o comportamento de controle específico a • Geralmente são as primeiras levantadas na análise dos um ou mais casos de uso. fluxos dos casos de uso; – Criam, iniciam e excluem objetos controlados; – Tipicamente independentes da aplicação; – Coordenam a ação dos objetos controlados; – Tipicamente essenciais: • Necessárias para cumprir alguma responsabilidade do produto; • Exemplos: – Freqüentemente persistentes: – Controlador de conexão; • Correspondem a entidades de bancos de dados. – Controlador de impressão; – Controlador de matrícula; – Controlador de pedido; – Controlador de faturamento. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 17
  • 18. Introdução a UML Introdução a UML Diagrama de classes (16/36) Diagrama de classes (17/36)• Classe abstrata: • Interfaces: O propósito de uma interface é – O nome da classe aparece em itálico: encapsular um conjunto de operações • Classe Pessoa. oferecidas pela classe; – É comum apresentarmos na interface apenas parte das operações; – A interface especifica a assinatura das operações; – O relacionamento utilizado é o de realização. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Introdução a UML Introdução a UML Diagrama de classes (18/36) Diagrama de classes (19/36)• Uma outra classe que use ou requeira • Nome de relacionamentos: operações supridas pela interface é ligada a – É mostrado próximo à linha do relacionamento, de esta por uma dependência. forma centralizada; – Deve ser um nome que exprima o significado do relacionamento. – Pode também ser um verbo, desde que esteja claro qual é o sujeito e qual é o objeto. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 18
  • 19. Introdução a UML Introdução a UML Diagrama de classes (20/36) Diagrama de classes (21/36)• Papéis em relacionamentos: • Multiplicidade é o número de instâncias – Um papel denota o propósito ou capacidade em que possíveis em um relacionamento entre uma classe se associa com outra; classes (é o número de instâncias de uma – O nome de um papel é colocado ao longo da linha de classe relacionada a uma instância de outra associação, próximo à classe referenciada; classe); – Um ou ambos os lados da associação podem ter nomes de papéis. • Para cada relacionamento devem ser tomadas duas decisões de multiplicidade: uma para cada lado da associação. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Introdução a UML Introdução a UML Diagrama de classes (22/36) Diagrama de classes (23/36)• Consiste de um conjunto de números inteiros não-negativos;• Se contiver um asterisco *, ele significa uma faixa infinita de números inteiros não- negativos; 1 ou 1..1 = exatamente 1 0..* = zero ou mais 1..* = um ou mais 0..1 = zero ou um 5..8 = intervalo específico 4..7, 9 = combinação (4,5,6,7,9) © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 19
  • 20. Introdução a UML Introdução a UML Diagrama de classes (24/36) Diagrama de classes (25/36)• Navegabilidade: – Os relacionamentos podem ser bidirecionais ou unidirecionais; – Uma seta é adicionada ao relacionamento quando a navegação vem apenas em uma direção; – Quando a seta é omitida a navegação é desconhecida ou é bidirecional; – Exemplo: Um eleitor deve saber em quem votou, mas o candidato não deve saber quem votou nele. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Introdução a UML Introdução a UML Diagrama de classes (26/36) Diagrama de classes (27/36)• Associação binária conecta duas classes; • Associações reflexivas são associações de uma classe com ela própria.• Associação n-ária possui três ou mais classes ligadas pelo relacionamento. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 20
  • 21. Introdução a UML Introdução a UML Diagrama de classes (28/36) Diagrama de classes (29/36)• Uma restrição XOR indica que apenas uma • Uma classe de associação é responsável dentre as várias associações representadas por dados e comportamento de uma pode ocorrer. Ambas não podem ocorrem ao associação; mesmo tempo. • De um modo geral, surge como responsável por atributos/serviços, resultado de um relacionamento n-n entre duas classes. OU © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Introdução a UML Introdução a UML Diagrama de classes (30/36) Diagrama de classes (31/36)• Agregação é uma forma especial de • Agregações reflexivas são agregações de associação onde o todo está relacionado às uma classe com ela mesma. suas partes. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 21
  • 22. Introdução a UML Introdução a UML Diagrama de classes (32/36) Diagrama de classes (33/36)• Composição indica ciclos de vida • Composições reflexivas são composições de dependentes. uma classe com ela mesma; © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Introdução a UML Introdução a UML Diagrama de classes (34/36) Diagrama de classes (35/36)• Herança simples: • Herança múltipla: © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 22
  • 23. Introdução a UML Diagrama de classes (36/36)• Dependências: Análise e Projeto de Sistemas Aula expositiva 06 Professor José Luiz Bastos © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagrama de Objetos (1/5) Diagrama de Objetos (2/5)• Representa uma instância de um Diagrama • Deve mostrar apenas os objetos relevantes de Classes em um determinado contexto; em um determinado contexto;• Pada cada classe temos um objeto (sua • Notação UML para objetos: instância); – nomeDoObjeto : nomeDaClasse;• É útil para: – Visualizar mais claramente a relação entre os objetos das classes; – Visualizar dados reais; – Validar o modelo de classes; – Identificar problemas na execução de uma aplicação. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 23
  • 24. Diagrama de Objetos (3/5) Diagrama de Objetos (4/5)• Notação UML para atributos dos objetos: • Relacionamentos entre os objetos são feitos nomeDoAtributo: tipo = valor; através de links;• Se o tipo for citado, deve ser o mesmo da • Um link éuma instância de uma associação; classe, mas pode ser omitido; • O nome do papel pode ser mostrado ao final• Atributos cujos valores podem mudar durante do link; o processamento apresentam uma lista de • O nome da associação pode ser mostrado valores. próximo ao link; • Multiplicidades não são mostradas pois os links já são instâncias; • Agregação, composição e navegação podem ser mostradas. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagrama de Objetos (5/5) Diagrama de Atividades (1/12) • Aplicação: – Modelagem de workflow; – Modelagem de processamento paralelo; – Modelagem de fluxos de casos de uso; – Descrição de algoritmos seqüenciais; • Não devem ser usados em: – Modelagem de comportamento de objetos (usar os diagramas de interação neste caso) ; – Modelagem do ciclo de vida de objetos (usar o diagrama de estados neste caso). © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 24
  • 25. Diagrama de Atividades (2/12) Diagrama de Atividades (3/12)• Uma atividade é um estado de realização de • Comportamento condicional: algo: – É delineado por desvios e intercalações; – Um processo do negócio; – Desvio: – Uma rotina de software; • Uma transição de entrada; • Várias transições de saída guardadas; • Somente uma transição de saída pode ser tomada;• Um Diagrama de Atividades: – Descreve uma seqüência de atividades; – Suporta comportamento condicional e paralelo. – Intercalação: • Múltiplas transições de entrada; • Uma transição de saída; • Marca o final de um desvio. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagrama de Atividades (4/12) Diagrama de Atividades (5/12) • Comportamento paralelo: – É indicado por separações e junções; – Separação: • Uma transição de entrada; • Várias transições de saída; • Uma transição de entrada dispara todas as transições de saída; – Junção: • Múltiplas transições de entrada; • Sincroniza as atividades que acontecem em paralelo; • Separação e junção devem se completar. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 25
  • 26. Diagrama de Atividades (6/12) Diagrama de Atividades (7/12) • Thread condicional: – Atividade com uma condição de guarda antes; – Se a condição for falsa a atividade é considerada completada; – Permite que junções sejam feitas sem que atividades paralelas sejam executadas. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.Diagrama de Atividades (8/12) Diagrama de Atividades (9/12) • Subatividades: – Uma atividade pode ser dividida em subatividades; – Pode-se usar estados de início e fim no subdiagrama; – Pode-se projetar transições diretamente para dentro ou para fora do subdiagrama. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 26
  • 27. Diagrama de Atividades (10/12) Diagrama de Atividades (11/12) • Raias: – Dizem quem faz o quê; – Deve-se organizar o diagrama em zonas verticais separadas por linhas; – Cada raia representa a responsabilidade de uma classe, ator, departamento, etc. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.Diagrama de Atividades (12/12) Análise e Projeto de Sistemas Aula expositiva 07 Professor José Luiz Bastos © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 27
  • 28. Diagrama de Estados (1/19) Diagrama de Estados (2/19)• O Diagrama de Estados descreve o • Estado: comportamento de objetos em relação a – É uma condição detectada durante o ciclo de vida de eventos; um objeto quando ele: • Satisfaz alguma condição;• Apresenta uma seqüência de estados e • Realiza alguma atividade; ações que ocorrem durante a vida do objeto, • Aguarda por algum evento; em resposta a eventos;• O Diagrama de Estados mostra o ciclo de – O Estado de um objeto é uma das possíveis condições vida de um objeto, ou seja, seus estados, os nas quais ele pode existir durante a sua vida. eventos que causam a transição de um estado para outro e as ações que resultam de uma mudança de estado. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagrama de Estados (3/19) Diagrama de Estados (4/19)• Um estado é representado graficamente Compartimentos: como um retângulo com cantos • Um estado pode ser opcionalmente arredondados; subdividido em compartimentos:• O nome do estado é colocado no centro do – Compartimento de Nome: mesmo. • Armazena o nome do estado, como uma string; – Compartimento de transições internas: • Armazena uma lista de ações ou atividades internas que são executadas enquanto o objeto se apresenta no estado em questão. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 28
  • 29. Diagrama de Estados (5/19) Diagrama de Estados (6/19) • Estados x atributos: – O estado de um objeto pode ser caracterizado pelo valor de um ou mais de seus atributos. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagrama de Estados (7/19) Diagrama de Estados (8/19)• Estados podem ser caracterizados pela • Estado inicial: existência de um relacionamento com outro – Indica o local de início do diagrama de estados; objeto; – Cada diagrama deve possuir um e apenas um estado inicial(exceto para diagramas aninhados); • Representação: Um círculo preenchido.• Diagrama de estados da classe Professor: © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 29
  • 30. Diagrama de Estados (9/19) Diagrama de Estados (10/19)• Estado final: • Transição: – Indica o fim da existência de um objeto ou o final da – Relacionamento entre dois estados; realização de uma atividade (para diagramas – Indica que haverá uma mudança de estado e que aninhados); determinadas ações serão executadas; – Um diagrama pode ter múltiplos estados finais. – Pode ocorrer como resultado de algum evento. – Pode ter que satisfazer a alguma condição; – O estado sucessor pode ser o estado original; – É representada com uma seta do estado de origem para o estado de destino. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagrama de Estados (11/19) Diagrama de Estados (12/19) assinaturaDoEvento [condiçãoDeGuarda] / expressãoAção • [condiçãoDeGuarda] – Quando verdadeira, permite que a transição seja feita; – Só é avaliada depois que o evento ocorre; – Várias transições a partir do mesmo estado de origem, identificadas com o mesmo evento, se diferenciam pela condição de guarda; – É colocada entre colchetes; • Exemplo: Checar Estoque [estoqueAtual <= EstoqueMínimo] © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 30
  • 31. Diagrama de Estados (13/19) Diagrama de Estados (14/19)assinaturaDoEvento [condiçãoDeGuarda] / expressãoAção• expressãoAção: – Somente é executada no início da transição, se esta ocorrer; – Pode ser descrita com operações; – É precedida por uma barra /;• Exemplo: – Nota lançada [nota = 7.0] / FechaProvasRegulares() © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagrama de Estados (15/19) Diagrama de Estados (16/19)• Transições internas: • Atividade: – Atividades associadas ao estado e que devem ocorrer – É uma operação que leva tempo para terminar; na entrada, na permanência, ou na saída do mesmo; – São associadas a um estado; – São associadas com qualquer transição entrando ou – Começa quando o objeto entra no estado; saindo do estado; – Pode executar até terminar ou pode ser interrompida – São mostradas dentro do ícone do estado precedidas pelo disparo de uma transição. pela palavra “entry”, “exit”ou “do”. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 31
  • 32. Diagrama de Estados (17/19) Diagrama de Estados (18/19)• Estados compostos: – Estados compostos podem ser utilizados para simplificar diagramas de estados; – Um estado composto é um estado que engloba estados internos concorrentes ou seqüenciais; – Estados internos são denominados subestados; – Cada região de um estado composto pode possuir estados inicial e final; – Uma transição para um estado composto representa uma transição para o estado inicial do referido estado composto. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagrama de Estados (19/19)• Crie diagrama de estados apenas para classes com um comportamento dinâmico significativo; Análise e Projeto de Sistemas• Classes de Fronteira e Controle normalmente possuem um comportamento dinâmico Aula expositiva 08 interessante de ser capturado em um diagrama de estados. Professor José Luiz Bastos © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 32
  • 33. Diagramas de Interação (1/27) Diagramas de Interação (2/27)• Interação corresponde a um conjunto de • Mostram as interações entre os objetos; mensagens trocadas entre objetos, com o • Representam cenários de casos de uso e objetivo de alcançar determinado propósito, são formados por: respeitando-se o contexto do sistema; – objetos; – mensagens; – relacionamentos;• Não confundir com iteração, que representa repetição. • Podem ser representados de quatro formas: – Diagrama de Seqüência; – Diagrama de Comunicação; – Diagrama de Interação; – Diagrama de Temporização. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagramas de Interação (3/27) Diagramas de Interação (4/27)• Diagrama de Seqüência: • Diagrama Sumário de Interação: – Focaliza a ordem temporal de um fluxo; – É uma variação do Diagrama de Atividades; – Enfatiza a seqüência de mensagens dentro de uma – Várias atividades são combinadas em seqüência linha de tempo; criando interações sumário;• Diagrama de Comunicação: • Timing Diagram: – Focaliza a comunicação entre os objetos; – Focaliza a interação entre objetos e mudanças de – Enfatiza os relacionamentos estruturais entre os estados destes objetos ao longo do tempo; objetos, sem se preocupar com o tempo; – Provê uma visão sobre a interação entre objetos e seus estados com outros objetos em um sistema.• É interessante ressaltar que esses diagramas apresentam formas diferentes de modelar os mesmos elementos. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 33
  • 34. Diagramas de Seqüência (5/27) Diagramas de Comunicação (6/27) © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagramas de Interação (9/27) Diagramas de Interação (10/27)Mensagem: • As mensagens podem ir da esquerda para a direita – Uma mensagem é representada por uma seta, com o ou da direita para a esquerda; nome da mensagem; • A ordem das mensagens indica a seqüência – O sentido da seta indica a origem da mensagem a temporal, sendo a primeira localizada mais acima; partir do objeto considerado cliente nesta relação. O • Mensagem de retorno: destino da seta indica o objeto servidor. – O diagrama pode incluir o retorno de uma mensagem; – Caracterize o retorno apenas quando melhorar a compreensão do diagrama. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 34
  • 35. Diagramas de Seqüência (11/27) Diagramas de Comunicação (12/27) © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagramas de Interação (13/27) Diagramas de Interação (14/27)• Linha de vida: • Foco de controle: – Representa a vida do objeto dentro de um – Representa o tempo durante o qual um objeto fica com determinado período de tempo. o controle do fluxo de execução. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 35
  • 36. Diagramas de Interação (15/27) Diagramas de Interação (16/27)• Notas: • Os diagramas podem ser melhorados através – Um diagrama pode incluir anotações com o objetivo de de descrições; adicionar informação. • Descrições podem ser escritas em linguagem natural ou pseudo-código. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagramas de Interação (17/27) Diagramas de Interação (18/27)• Um objeto que já existe quando a transação • O objeto pode ser criado no momento do tem início é mostrado alinhado ao topo do envio da mensagem; diagrama, de forma a ficar acima da primeira • A seta da mensagem aponta diretamente seta de mensagem. para o objeto em questão. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 36
  • 37. Diagramas de Interação (19/27) Diagramas de Interação (20/27)• O objeto pode ser destruído logo após o • Condições são colocadas dentro de tratamento da mensagem, ou em qualquer colchetes; momento antes do fim da interação; • A mensagem só será disparada se a• Um X é colocado na linha de vida para condição for verdadeira; indicar a destruição do objeto. • Exemplo 1: – [Mensalidade.pago = true] EmitirAutorizacaoDeProva() © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagramas de Interação (21/27) Diagramas de Interação (22/27)• Iteração: – Repetição (não confundir com interação); – Representa o envio da mesma mensagem diversas vezes para o mesmo objeto; – A iteração é representada entre colchetes, precedida de um asterisco *; – Dentro do colchete está a condição que determinará quantas vezes a mensagem será passada; – Exemplo: • Calcular a média dos alunos da turma da seguinte maneira: para cada aluno da turma chamar a operação CalcularMedia(); * [para cada aluno da turma] CalcularMedia() © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 37
  • 38. Diagramas de Comunicação (23/27) Diagramas de Seqüência (24/27)• Outra maneira de visualizar a interação entre • Exemplo de fluxo: Exclusão de mercadoria; objetos; – O Gerente de Compras seleciona excluir uma mercadoria;• A maioria das ferramentas CASE cria de – O sistema verifica se existe algum pedido pendente forma automática um Diagrama de que contenha esta mercadoria; Comunicação a partir de um Diagrama de – Se não houver pedido pendente contendo a Seqüência e vice-versa. mercadoria a ser excluída: • O sistema desvincula a mercadoria dos fornecedores (os fornecedores não mais fornecerão a mercadoria que esta sendo excluída); • O sistema faz a remoção da mercadoria; – Se houver pedido pendente contendo a mercadoria a ser excluída: • O sistema emite uma mensagem de erro. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. Diagramas de Seqüência (25/27) Diagramas de Interação (26/27) Operações: • Mensagens nos diagramas de interação: – São mapeadas em operações da classe receptora; – Os nomes das operações devem ser relativos à classe receptora; – A criação das operações pode ser adiada enquanto se discutem alternativas de realização. © 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr. 38
  • 39. Diagramas de Interação (27/27)Relacionamentos:• Podem ser descobertos através das operações: – Existência de mensagens entre objetos nos diagramas de interação; – Existência de algum tipo de relacionamento entre as classes correspondentes. © 2008 José Luiz G. Bastos Jr. 39