Aulas de análise

1,234 views
1,188 views

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,234
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
47
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Aulas de análise

  1. 1. Prof: Rilmar Gomes Copyleft2010 – Prof: Rilmar Gomes<rilmargomes@hotmail.com>
  2. 2. Pressupõe que o mundo é composto porobjetosObjeto é uma entidade que combinaestrutura de dados e comportamentofuncionalOs sistemas são modelados como umnúmero de objetos que interagem entre siEm POO, temos que:◦ Estrutura de dados + funções = objeto◦ objeto + objeto + ... + objeto = programa Copyleft2010 – Prof: Rilmar Gomes<rilmargomes@hotmail.com>
  3. 3. Objetos são todas as coisas, reais ouabstratas, às quais nossos conceitos seaplicam.Na OO estaremos interessados noCOMPORTAMENTO do Objeto.Os objetos (computacionais) são compostosou representados por:◦ ATRIBUTOS - Uma coleção de tipos de dados que definem o ESTADO do Objeto.◦ MÉTODOS - Ações ou procedimentos que alteram o estado do objeto (Comportamento). Copyleft2010 – Prof: Rilmar Gomes<rilmargomes@hotmail.com>
  4. 4. Os atributos de um objeto definem asqualidades e características da entidade queele representaO estado de um objeto é o particularconjunto de valores de seus atributos em umdado momentoO comportamento de um objeto é definidopelas alterações do seu estado em resposta amensagens que ele recebe (interação comoutros objetos) Copyleft2010 – Prof: Rilmar Gomes<rilmargomes@hotmail.com>
  5. 5. Objetos servem a dois propósitos:◦ Facilitar a compreensão do mundo real,◦ Fornecer uma base real para a implementação em computador.Os objetos possuem identidade e sãodistinguíveis dentro de um Sistema Copyleft2010 – Prof: Rilmar Gomes<rilmargomes@hotmail.com>
  6. 6. Alguns exemplos deObjetos:◦ Um avião◦ Uma Nota Fiscal◦ Uma tela que o usuário interage◦ Um ícone numa tela para qual o usuário aponte e “abre”◦ Uma árvore
  7. 7. Objetos podem ser compostos por outros objetos.Isto permite que Objetos Complexos sejam definidos apartir de objetos mais simples.
  8. 8. Para construir o objeto “carro”, teremos deabstrair seus atributos e funções:◦ um carro pode ter os seguintes recursos ou atributos: cor, velocidade máxima, tipo de combustível, tamanho, modelo◦ um carro pode: andar, parar, virar à esquerda, virar à direita, Copyleft2010 – Prof: Rilmar Gomes<rilmargomes@hotmail.com>
  9. 9. Como descrever os objetos no mundo computacional?◦ temos de mapear os objetos reais em objetos computacionais e escrever programas que dão vida a estes objetos em um sistema computacional.◦ Para mapear os objetos (análise de um domínio) iremos utilizar o processo de ABSTRAÇÃO. Operação mental para observar um domínio e capturar Convenções sua estrutura ABSTRAÇÃO REPRESENTAÇÃO Entidade EntidadeObservada Representada Notação gráfica, Carro linguagem de programação
  10. 10. Diferentes abstrações a partir de um mesmo objeto do mundo real Cardinalidade I, II, do conjunto Maça Peso cor da casca format RECEITA ATRIBUTO 3CATEGORIA AÇÃO
  11. 11. Focalizar o essencial, ignorar as propriedadesacidentais AERONAVE
  12. 12. Surge a UML em 1996como a melhorcandidata para ser alinguagem unificadorade notações.Em 1997 a UML éaprovada como padrãopela OMG;Desde então tem tidogrande aceitação
  13. 13. É independente de linguagem deprogramaçãoÉ independente de processo dedesenvolvimentoNão é uma linguagem de programaçãoNão é uma metodologiaÉ uma linguagem visual
  14. 14. UML não guia um desenvolvedor em comofazer análise e projetoNão especifica o processo a ser seguidoOferece uma notação para ser utilizada comoo desenvolvedor julgar necessário
  15. 15. Disponibiliza:◦ Diagrama de Casos de Uso◦ Diagrama de Classes◦ Diagrama de Estados◦ Diagrama de Atividades◦ Diagrama de Seqüência◦ Diagrama de Colaboração◦ Diagrama de Componentes◦ Diagrama de Implantação
  16. 16. Um modelo pode ser visto como umarepresentação idealizada de um sistema a serconstruídoMaquetes de edifícios e de aviões e plantasde circuitos eletrônicos são apenas algunsexemplos de modelosUma simplificação da realidade que nos ajudaa entender um problema complexo
  17. 17. Ajuda no gerenciamento da complexidadeinerente ao desenvolvimento de softwareAjuda na comunicação entre as pessoasenvolvidasAjuda na predição do comportamento futurodo sistema
  18. 18. Representa o comportamento de um sistemaem termos de suas funcionalidadesDescrevem o que o sistema deve fazer, masnão como isso será feitoElementos◦ Atores◦ Casos de Uso◦ Relacionamentos
  19. 19. Atores◦ Representam qualquer entidade externa que interage com o sistema◦ Entidade externa: usuário, hardware, outro sistema, etc.◦ Formas de interação: Enviar dados para o sistema Receber dados do sistema Enviar/Receber dados do sistema
  20. 20. Atores◦ Implícitos Atores que podem ser omitidos do diagrama Inclusão não traz contribuição para a modelagem do sistema Ex.: Monitor, PC, Sistema Operacional, teclado, etc.
  21. 21. Relacionamentos◦ Representam a interação entre: Casos de uso e atores Casos de uso Atores
  22. 22. Casos de uso e atores◦ Associação Um ator pode interagir com mais de um caso de uso Um caso de uso pode interagir com mais de um ator
  23. 23. Casos de uso e atores◦ Associação Notação – Ativação do Caso de Uso
  24. 24. RelacionamentoEntre casos de uso◦ Inclusão (include)◦ Extensão (extend)◦ Generalização
  25. 25. ◦ Inclusão (include) Um caso de uso inclui um outro caso de uso (subcaso de uso) Caso de uso incluído não faz sentido sozinho, não é completo Obrigatoriedade (sempre será executado) Quando usar: Detalhamento de casos de uso por meio de decomposição Colocar em evidência partes comuns entre dois ou mais casos de uso
  26. 26. ◦ Extensão (extend) Caso de uso maior é estendido por um caso de uso menor Quando usar: Usada para modelar casos de uso especiais que ocorrem somente em determinadas circunstâncias (opcional)
  27. 27. ◦ Generalização Representa o relacionamento entre um caso de uso mais geral e um ou mais casos de uso específicos Quando usar: Representar a aplicação de um caso de uso geral em uma situação particular Situação particular: funcionalidades do caso de uso geral devem ser complementada
  28. 28. Generalização
  29. 29. Entre atores◦ Generalização Representa que um ator é um caso especial de outro ator
  30. 30. Tem como finalidade apresentar, de formadetalhada, como deve ser executada umafuncionalidade, ou seja, representa aexecução da funcionalidade passo-a-passo.Os diversos autores, que tratam, atualmente,deste assunto, apresentam diferentespadrões e notação para descrição de caso deuso. Adotaremos um modelo originado apartir da fusão do que de bom foi encontradonesses autores, e acrescentamos, é claro,nossa contribuição.
  31. 31. Nome do Caso de Uso – descrição do Nomedo caso de uso correspondente ao nome dodiagrama.Sigla – é uma forma de denominar o caso deuso, tornando mais fácil sua referência. Porexemplo: UC001Objetivo – é seção na qual deverá ser descritaqual o objetivo do caso de uso;Ator(es) – identifica qual ator(es) irão interagircom o caso de uso que está sendo descrito.
  32. 32. Pré condição – descreve as restrições quedevem ser obedecidas para a execução docaso de uso.Pós Condição – descreve o que deverá ocorrerno sistema após a execução do caso de uso.É importante tomar o cuidado para descreversomente aquilo que de fato irá impactar nosistema e, de preferência, aquilo que teminfluência direta nas regras de negócio.
  33. 33. Fluxo – é o principal componente de umadescrição de caso de caso de uso. Representaa seqüência de passos a serem seguidos eestá classificado em: Fluxo Principal (ouBásico), Sub Fluxo, Fluxo Alternativo e Fluxode Exceção (ou de erro);
  34. 34. Descreve o “caminho ótimo” do caso de uso,ou seja, descreve a principal ação do caso deuso sem se preocupar com exceções ouquaisquer outros detalhes que possaminterferir no resultado do mesmo.
  35. 35. Descreve uma parte do fluxo principal.Representa uma seqüência de passos queserão SEMPRE executados, porém sãotratados de forma separada para tornar adescrição do fluxo principal mais simples.
  36. 36. O Fluxo alternativo representa um caminhoopcional para o usuário que está interagindo,ou seja, caso ele não queira seguir o caminhoprincipal (básico) ele tem a alternativa deseguir outro caminho.
  37. 37. O Fluxo de Exceção ou Erro tem comofinalidade descrever como o sistema deverátratar erros que poderão ocorrer no fluxoprincipal ou em nos fluxos alternativos esub-fluxos, ou seja, o fluxo de exceçãodescreve algo que interferiu no caminhoótimo mas que foi tratado pelo sistema.
  38. 38. Um sub-fluxo pode ser comparado a umprocedimento/função (procedure/function),representando um desvio para se executar algo aparte e depois voltar para o programa principal(fluxo principal no nosso caso);Uma diferença entre um sub-fluxo e um fluxoalternativo é que o fluxo alternativo representa, namaioria das vezes uma opção de escolha do vezes,usuário, isto é, uma escolha manual, e um sub-fluxo representa uma escolha do sistema, ou seja,uma escolha automática.
  39. 39. DIAGRAMA DE CLASSES
  40. 40. É um dos diagramas estáticos da UML e tem por objetivoapresentar as classes do domínio do problema e osrelacionamentos entre as mesmas.Mas o que são classes?As classes agrupam um conjunto de entidades real ou abstratas quepossuem as mesmas características. Essas entidades são conhecidascomo objetos. Além disso, as classes servem como um molde para acriação de novos objetos do mesmo tipo
  41. 41. Assim como no banco de dados, os dados só têmsentido em uma base de dados quando estãointerligados, no um diagrama de classes deverepresentar além das classes do sistema, osrelacionamentos entre as mesmas.É importante ressaltar que este diagrama podeser elaborado em duas fases do desenvolvimentode um software: na fase de análise e na fase deprojeto.
  42. 42. Na fase de análise, este diagrama é usado pararepresentar as classes do domínio do problema,cujos dados devem ser armazenados na base dedados do sistema.Em relação à fase de projeto, pode-se dizer que omesmo é usado representar não apenas asclasses que contêm os dados a seremarmazenados, mas também outros tipos de classenecessários à implementação software.
  43. 43. Componentes.◦ Classes◦ Relacionamentos.
  44. 44. Classes.◦ De um modo geral, as classes são compostas por seus atributos e seus métodos, sendo representadas por uma “caixa” com três compartimentos
  45. 45. Visibilidade de atributos e métodos◦ Private: indica que um atributo ou método só pode ser visualizado e acessado dentro da própria classe. Na UML, a visibilidade private é representada pelo símbolo “-”.◦ Público (public): um atributo ou método definido como público é visível por qualquer por qualquer classe. A notação para representar essa visibilidade é o símbolo “+”.◦ • Protegido (protected): um atributo ou método com visibilidade protegido pode ser acessado pela própria classe ao qual o mesmo pertence e por suas subclasses. A visibilidade protected é representada na UML pelo símbolo “#”.
  46. 46. Classes de entidade (Entity) – são entidades domundo real relevantes para o domínio doproblema, sendo seu principal papel representaros dados a serem armazenados pelo sistema. Porexemplo: Livro, Exemplar, Autor, etc.b) Classes de controle (Control) – sua principalfunção é controlar a execução de processos.Normalmente, os métodos de uma classe dessanatureza controlam transações que envolvemvárias classes de entidade.
  47. 47. Classes de fronteira (Boundary) – responsáveispela comunicação entre o mundo externo (atores)e as classes de controle. Normalmente, sãoimplementadas na forma de interfaces gráficas(telas). Exemplo: Tela de Cadastro de Livros, Telade Empréstimo de Exemplares.
  48. 48. Os relacionamentos representam a forma comoas classes de um sistema interagem entre si.Duas ou mais classes podem se associar pormeio de quatro tipos de relacionamentos, os quaissão: associações, todo-parte, herança edependência.
  49. 49. Associações descrevem um vínculo existente entre duas classes,sendo conhecidas como associações binárias. Para exemplificareste tipo de relacionamento, considere as classes Aluno e Curso.De acordo com o domínio de problema, um aluno deve estarmatriculado em um curso, ou seja, existe um vínculo entre essasclasses.
  50. 50. Todo-parte: indica que os objetos da classe A (todo) são compostospor objetos da classe B (parte). Para exemplificar este conceito,suponha um carro, o qual é formado por diversas peças. O carrorepresenta o todo e suas peças representam as partes que ocompõe.Existem dois tipos de relacionamento todo-parte: agregação ecomposição.AgregaçãoComposição
  51. 51. Herança: Antes de iniciar a explicação do conceito deherança empregada no diagrama de classes, vamosentender o conceito de herança proposto pela genética.Multiplicidade e Participação:
  52. 52. DIAGRAMA DE ESTADOS
  53. 53. Descreve os possíveis estados dos objetos deuma classeElementos◦ Estado inicial◦ Estado final◦ Estados◦ Transição de estados
  54. 54. Notação◦ Estado inicial◦ Estado final◦ Estado◦ Transição
  55. 55. Classe Caixa
  56. 56. Eventos: é uma ação que exige a mudança deestado do objeto como reação.Ex: Ferver a água faz com que ela mude doestado liquido para o gasoso.A mudança de um estado é chamado de transiçãode estadoOs estados e as transições de um objeto formamum cliclo de vida do objeto.
  57. 57. Mostrar o fluxo de atividade de um processo.Pode ser usado para detalhar um caso de usoFortemente empregado para representar fluxo denegócioElementos◦ Início do fluxo◦ Final do fluxo◦ Atividade◦ Transição◦ Junção/Bifurcação◦ Seleção◦ Condição de guarda◦ Raias de navegação
  58. 58. Notação◦ Início◦ Final◦ Atividade◦ Transição◦ Junção/Bifurcação◦ Seleção◦ Condição de guarda [condição]◦ Raias de navegação
  59. 59. ◦ Atividade: é um passo simples num processo ou na descrição do caso de uso.◦ Estados de atividades: são as atividades realizadas pelo sistema ou pelo ator.◦ Transição: é a mudança que permite a passagem de controle de uma atividade para outra.◦ Desvios: são decisões que precisam ser tomadas para permitir a continuação do fluxo de atividades.
  60. 60. ◦ Bifurcação e junção de fluxo de controle: o primeiro indica o início de atividades paralelas e o segundo representar a união de fluxos independentes.◦ Intercalação: é utilizado após um desvio para indicar que o fluxo seguirá o mesmo caminho independente da condição de guarda satisfeita.◦ Raias: são compartimentos que permitem a separação das responsabilidades dos participantes do diagrama de atividades.◦ Estados inicial e final: indicam o início e o fim de um fluxo, respectivamente.
  61. 61. Descrever os passos de um caso de uso.Mostrar o fluxo completo do sistema,representando a ordem de execução doscasos de uso.Modelar um algoritmo complexo.
  62. 62. É um diagrama usado para demonstrar interações entre objetos pormeio de troca de mensagens. (A bíblia)Mostra a troca de mensagens entre os objetos.
  63. 63. Modelo de caso de uso descreve as tarefas que o sistema deverealizar.Descreve quais são os requisitos funcionais do sistema e quais sãoas entidades do ambiente (atores) que interagem com o sistema.Não descreve o comportamento interno do sistema.Não responde às questões: Quais são as operações que devem serexecutadas internamente ao sistema? Quais objetos participam darealização do caso de uso?
  64. 64. Modelo de classes do domínio descreve as classes que realizarãoas tarefas do sistema e o relacionamento entre as mesmas.Fornece uma visão estrutural estática inicial do sistema.Não responde às questões: De que forma os objetos colaborampara que um determinado caso de uso seja realizado? Em queordem as mensagens são enviadas durante a realização de umcaso de uso?
  65. 65. O modelo de casos de uso e o modelo de classes do domínio têm oobjetivo de fornecer um entendimento do problema correspondenteao sistema de software a ser desenvolvido.O modelo de interações representa as mensagens trocadas entreos objetos para a execução de cenários dos casos de uso dosistema.O modelo de interações responde às questões anteriores.
  66. 66. Permite armazenar em detalhes COMO os objetos interagem pararealizar uma tarefa.Mostra como o sistema realiza casos de uso, ou cenáriosparticulares dos casos de uso.Permite validar classes, responsabilidades e colaboradoresidentificados anteriormente.Permite refinar o modelo de classes do domínio.Durante a construção do modelo de interações operações dasclasses são identificadas.
  67. 67. Componentes Ator Objetos Mensagens Foco de controle
  68. 68. AtorRealiza a interação com o caso de usoTem a mesma notação do diagrama de caso de uso.Só interagem com a classe de fronteira.
  69. 69. Objetos Representam as instâncias das classes. São responsáveis por enviar ou receber mensagens. São representados por uma caixa de retangular ou por um círculo, acompanhados por uma linha tracejada, conhecida como linha de vida do objeto.
  70. 70. MensagensNas mensagens existe o objeto que envia a mensagem e outro querecebe a mensagem.As mensagens tem ser clara, ou seja, deve haver umacomunicacão entendível entre ambos.A seta das mensagens deve partir do objeto emissor para oreceptor.As mensagens podem ser:◦ Sícrona◦ Assícrona◦ Criacão de Objetos◦ Retorno◦ Reflexiva◦ Destruicão
  71. 71. FOCO DE CONTROLEO Foco de controle indica o momento ou período detempo em que um determinada mensagem de um objetoestá no comando da execução do sistema.A notação do foco de controle é uma barra vertical finasobre a linha de vida do objeto.Para as mensagens reflexivas, o foco de controle érepresentado por uma barra vertical sobreposta à barrada linha.
  72. 72. Sícrona Indica que o objeto remetente espera que o objeto receptor processe a mensagem enviada antes de recomeçar o seu processamento.
  73. 73. AssícronaObjeto remetente não espera a resposta da mensagem enviadapara prosseguir com o seu processamento.
  74. 74. Retorno Indica o término de uma operação. Mostra a resposta do objeto receptor referente à uma mensagem síncrona recebida.
  75. 75. Criação de objetosÉ uma mensagem que cria um objeto, ou seja, a partirdaquele momento o objeto passa a existir no sistema.
  76. 76. ReflexivaO mesmo objeto é emissor e receptor ao mesmo tempo.Um objeto envia uma mensagem para ativar um métodona sua própria classe.

×