Your SlideShare is downloading. ×
Análise de sistemas oo   1
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Análise de sistemas oo 1

727

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
727
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
17
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. Análise deSistemas OO - 1Maurício Linhares
  • 2. Material de referência›  Head First Object Oriented Design and Analysis – Brett D. McLaughlin e outros›  Domain Driven Design – Tackling Complexity in the Heart of Software – Eric Evans›  Refactoring: Improving the design of existing code – Martin Fowler e outros
  • 3. O que é análiseOrientada a Objetos?Definição dos objetos, suas atividades,propriedades e funções dentro do sistema ondeeles estão inseridos
  • 4. Modelando um simuladorde rotas de redePense nos atores e nas atividades
  • 5. Modelagem eficiente›  Manter modelos e implementação fortemente ligados;›  Cultivar uma linguagem baseada no modelo;›  Desenvolver um modelo que represente conhecimento sobre o assunto tratado;
  • 6. Modelagem Eficiente›  Destilar o modelo, removendo conceitos desnecessários ou não essenciais;›  Brainstorms e experimentação para garantir que a solução que está sendo desenvolvida é realmente a melhor possível;
  • 7. “É a criatividade dos brainstorms eexperimentações, junto com umalinguagem baseada no modelo edisciplinada pelo feedback daimplementação, que torna possívelencontrar um modelo rico e destilá-lo para o software funcional.”Eric Evans, Domain DrivenDesign, página 13
  • 8. Knowlege Crunching –Triturando conhecimento›  A equipe trabalha junto com os especialistas do domínio para criar o modelo;›  O conhecimento deve ser refinado e construído de acordo com as funcionalidades desejadas;
  • 9. Knowledge crunching›  Ilhas de informação devem ser evitadas, é importante que todos os membros tenham conhecimento sobre o modelo para que possam escrever o software;›  Abstrações do modelo devem surgir através das abstrações do próprio domínio, o modelo sempre reflete o mundo real;
  • 10. Aprendizado contínuo›  Programar é definir uma teoria, em código, que representa elementos no mundo real;›  Conhecimentose fragmenta, se torna obsoleto ou representa entidades de pouca importância, é necessário continuar aprendendo;
  • 11. Implementando cargas,viagens e overbookingConstruindo um modelo rico em conhecimento
  • 12. Modelos profundos›  Não perca tempo demais tentando ir o mais fundo possível nos seus modelos;›  Conhecimento e refinamento vem com tempo, prática e experimentação;›  O modelo final dificilmente é o mesmo do modelo inicial;
  • 13. Momentos da análise OO –Conceitualmente ›  Deduzir os requisitos do cliente para o sistema; ›  Identificar cenários de casos de uso; ›  Selecionar classes e objetos usando os requisitos; ›  Identificar atributos e operações para cada objeto do sistema; ›  Definir estruturas e hierarquias que organizem as classes; ›  Construir um modelo objeto-relacionamento; ›  Construir um modelo de comportamento de objeto; ›  Revisar o modelo de análise OO com base nos casos de uso ou cenários.
  • 14. Caminho do sucesso -simplificado›  Descubra as funcionalidades que o cliente necessita;›  Primeiro escreva código que atende a necessidade do cliente (e com testes);›  Depois atente para os problemas de design OO que o seu código possa ter e adicione flexibilidade onde necessário;›  Mantenha o seu código bem organizado, legível e passível de ser reutilizado;›  Lucro! $$$!
  • 15. Escreva a funcionalidadeque você deve implementarComo começar?
  • 16. Tudo começa com osrequisitos›  Ouça o que o cliente deseja que o sistema faça;›  Tenteusar mockups ou desenhos se ele tiver dificuldade explicando o que ele deseja (http://balsamiq.com/ );›  Não se preocupe demais com a solução tecnológica que você vai ter que implementar;
  • 17. Atenção aos verbos esubstantivos!›  O seu cliente entende do negócio, ele normalmente sabe do que ele está falando então ENTENDA os conceitos básicos;›  Use dentro do seu sistema os mesmos nomes e atividades que o seu cliente está explicando nas funcionalidades;›  Substantivos normalmente simbolizam objetos e verbos seus métodos;
  • 18. A linguagem Ubíqua›  Desenvolvedorese usuários devem falar a mesma língua quando estiverem falando sobre o sistema;›  Traduções entre conceitos são ruins e geram perda de informação;›  Desenvolvedores devem procurar entender ao menos os conceitos básicos do sistema onde eles estão inseridos;
  • 19. Um diálogo de exemploComo desenvolvedores e clientes se comunicam
  • 20. Conhecimento sendopassado pela fala›  Oseu cérebro é especializado em entender a língua falada;›  A forma mais eficiente de aprender uma outra língua é através da imersão, não se fala nada além da nova língua;›  Equipe e especialistas do domínio devem expandir e adicionar novos significados a linguagem comum;
  • 21. Ah, mas o cliente nãoentende de objetos!›  Nemvocê entende de direito tributário, contabilidade, engenharia civil ou gestão de órgãos públicos. E aí?›  A linguagem criada é uma interseção entre o jargão técnico da informática e o jargão técnico do domínio pro qual o seu software vai ser produzido;
  • 22. Documentos, diagramas,modelos visuais›  Nãose prenda demais a papéis somente pelo fato deles serem documentos;›  Documentação deve “pagar” pra existir;›  Não tenha pena de jogar fora documentação que sirva somente de peso;
  • 23. Documentos, diagramas,modelos visuais›  Não se prenda demais a detalhes técnicos da UML ou da representação que você está utilizando;›  Simplifique qualquer coisa que não atenda as suas necessidades;›  DiagramasNÃO SÃO O SEU PRODUTO (na maior parte das vezes);
  • 24. Passo a passo›  Reúnaos caminhos básicos do sistema, crie uma lista, passo a passo, de o que precisa ser implementado (o que é isso?);›  Bonus se você estiver utilizando uma ferramenta de testes que seja capaz de receber texto puro;
  • 25. Exemplo hardcoreCenário: Remover itens do carrinho "!Dado que estou na listagem de produtos"E adiciono "5" itens do produto "Lean SoftwareDevelopment" ao carrinho"E adiciono "5" itens do produto "Agile Estimating andPlanning" ao carrinho"!Quando vou pra página do carrinho "E removo o produto "Agile Estimating and Planning" docarrinho"!Entao devo ver "Lean Software Development“ "!Mas não devo ver "Agile Estimating and Planning"
  • 26. Como implementarSettlers of Catan?Crie uma lista de requisitos que defina o jogo.Trivial, claro.
  • 27. O que é uma classe?Reencontrando a orientação a objetos
  • 28. O que é uma classe?›  Define a estrutura de um objeto, com seus atributos e operações;›  Atributos são os dados guardados no objeto;›  Operaçõessão as atividades que um objeto é capaz de executar ou as mensagens que ele recebe;
  • 29. O que é herança?Reencontrando a orientação a objetos
  • 30. O que é herança?Reutilizar código de uma outra classe herdandosuas propriedades e seus comportamentos
  • 31. O que é polimorfismo?Reencontrando a orientação a objetos
  • 32. O que é polimorfismo?É a capacidade de se utilizar uma subclasse de umobjeto onde o objeto pai (ou interface) é utilizadosem que o código perceba a diferença
  • 33. O que éencapsulamento?Reencontrando a orientação a objetos
  • 34. O que éencapsulamento?É o ato de esconder as informações deimplementação de um objeto dos seus clientesexternos com o objetivo de facilitar as mudançasno futuro.
  • 35. O que são composição eagregação?Revisando orientação a objetos
  • 36. O que são composição eagregação?Composição é o fato de que vários objetosinterligados compõem um objeto maior e nãofazem sentido em separado.Agregação é quando vários objetos podem existirdentro de um objeto maior ou isolados, não sendonecessário que estejam reunidos.
  • 37. Objetos devem fazer ourepresentar uma coisa esomente isso. Se o Bolo écomida, vai ser semprecomida.Responsabilidade
  • 38. Como identificar objetos quefazem demais?›  É difícil definir um nome pra eles;›  Uma mudança nesse objeto afeta vários outros objetos dentro do sistema;›  O objeto tem várias propriedades nulas e isso é comum;
  • 39. Modelo de classes?›  É o diagrama de classes acompanhado de uma descrição textual definindo o que cada classe faz no sistema;›  Existe em três diferentes tipos, domínio, especificação e implementação;
  • 40. Exemplo de classes numdiagrama de classes
  • 41. Modelo de classes - Domínio›  Éo diagrama de classes puro, sem dependência ou associação com a tecnologia que vai ser utilizada;›  Normalmente só existe nos momentos iniciais ou em rascunhos do sistema;›  Usa fortemente a linguagem ubíqua;
  • 42. Modelo de classes -Especificação›  Adicionadetalhes da implementação que foi escolhida ao modelo (interfaces de infraestrutura, classes base de frameworks, funcionalidades da linguagem);›  Normalmentedefinido antes de se entrar em detalhes de implementação;
  • 43. Modelo de classes -Implementação›  Classes implementadas na tecnologia escolhida;›  Códigoreal e executável, normalmente gerado inicialmente através dos modelos definidos anteriormente;
  • 44. Implementando um inventário›  Imagine uma livraria;›  Crie modelos que representem o inventário e que sejam capazes de fazer uma busca dado o título, autor e/ou categoria onde o livro se encontra;›  O sistema deve ser capaz de encontrar vários livros com uma única busca;
  • 45. Associações no modelo›  Objetos estão sempre se relacionando entre si, esses relacionamentos são chamados de associações;›  Apesardo modelo ser um modelo de classes, as associações são para os objetos dessas classes;
  • 46. Notação para associaçõesentre objetos Hóspede QuartoContaCorrente HistóricoTransações Cliente Produto
  • 47. Cardinalidade›  Definem os limites inferiores e superiores na associação entre dois objetos;›  Associações normalmente tem limites em “0..1”, “0..N” ou “0..*”;
  • 48. Exemplos de cardinalidadeNome SimbologiaApenas Um 1..1 (ou 1)Zero ou Muitos 0..* (ou *)Um ou Muitos 1..*Zero ou Um 0..1Intervalo Específico li..ls
  • 49. Notação para associaçõescom cardinalidade Cliente Pedido 1 0..*
  • 50. Cardinalidade na fórmula 1›  Corridastem pelo menos 20 carros;›  Uma corrida só pode ter no máximo 24 carros;›  Um carro pode estar em várias corridas; Carro Corrida 20..24 0..N
  • 51. Participação›  Define se uma associação é obrigatória ou não entre os objetos relacionados;›  Se a cardinalidade for 1, então ela é obrigatória, se for 0 em algum momento ela não é obrigatória;
  • 52. Detalhes das associações emUML›  Associações tem nomes, que definem o seu significado dentro do sistema;›  Direção,definindo como você faz a leitura da mesma;›  Papel, para definir um papel específico onde essa associação existe;
  • 53. Exemplo de associação Nome da DireçãoPapel associação de leitura Papel contratante Contrata contratado Organização Indivíduo * *
  • 54. Casos especiais: Agregação ›  Losangos definem a classe todo no diagrama; Afiliada membroAssociaçãoEsportiva Equipe Jogador * * * *
  • 55. Classes associativas›  Classes que existem para dar valores especiais a uma associação entre objetos;›  Utilizadas quando não há sentido em colocar os atributos em nenhuma das classes relacionadas;
  • 56. Exemplo de modelo com classe associativa Emprego salário dataContratação Pessoa * * Empresanome razãoSocialtelefone empregado empregador endereçoendereço
  • 57. Outros exemplos declasses associativas?Pense.
  • 58. Associações n-árias›  Utilizadas para demonstrar associações entre objetos de N classes;›  Associações ternárias são o caso mais comum;›  Um losango é a forma representada em UML para essa associação;
  • 59. Associação ternária Projeto Técnico 1 1 Uso nomenome verba * Computador modelo
  • 60. Associações reflexivas›  Associações onde um objeto se associa a outros objetos da mesma classe;›  Cadaobjeto tem um papel diferente na associação, de forma que eles sejam diferenciáveis;
  • 61. Exemplo de associaçãoreflexiva Supervisão supervisor 1 * Empregado supervisionado
  • 62. Crie os diagramas deassociação entre os objetosda lojaLembre-se de adicionar as cardinalidades e osnomes das associações.
  • 63. Responsabilidades ecolaboradores›  Em sistemas OO, objetos encapsulam tanto dados quanto comportamento.›  O comportamento de um objeto é definido de tal forma que ele possa cumprir com suas responsabilidades.›  Uma responsabilidade é uma obrigação que um objeto tem para com o sistema no qual ele está inserido. ›  Através delas, um objeto colabora (ajuda) com outros para que os objetivos do sistema sejam alcançados.
  • 64. Responsabilidades ecolaboradores›  Naprática, uma responsabilidade é alguma coisa que um objeto conhece ou faz. (sozinho ou não). ›  Um objeto Cliente conhece seu nome, seu endereço, seu telefone, etc. ›  Um objeto Pedido conhece sua data de realização e sabe fazer o cálculo do seu total.›  Se um objeto tem uma responsabilidade a qual não pode cumprir sozinho, ele deve requisitar colaborações de outros objetos.
  • 65. Responsabilidades ecolaboradores›  Umexemplo: quando a impressão de uma fatura é requisitada em um sistema de vendas, vários objetos precisam colaborar: ›  um objeto Pedido pode ter a responsabilidade de fornecer o seu valor total ›  um objeto Cliente fornece seu nome ›  cada ItemPedido informa a quantidade correspondente e o valor de seu subtotal ›  os objetos Produto também colaboraram fornecendo seu nome e preço unitário.
  • 66. Responsabilidades ecolaboradoresObjetos possuem realizadas por Responsabilidades Colaboradores O que o objeto conhece O padrão de cooperação + (comunicação) entre objetos O que o objeto faz precisam de
  • 67. Tipos comuns de objetosencontrados nos sistemas›  Entidades;›  Value objects;›  Serviços;›  Repositórios;›  Controllers;
  • 68. Camadas de um softwarePresentation Layer Application Layer Domain Layer Infrastructure Layer
  • 69. Camadas de um software›  Cada camada só deve ter acesso direto a objetos de si mesma ou de objetos em uma camada inferior;›  Em alguns casos, a camada de aplicação pode estar diretamente ligada a camada de interface com o usuário;›  A camada do domínio deve ser sempre a mais independente de todas dentro da aplicação;
  • 70. Entidades›  Objetos que não são definíveis apenas através dos seus atributos;›  Eles representam uma linha de identidade que existe de forma temporal, mas que deve ser capaz de se comparar com o mesmo objeto, ainda que hajam atributos diferentes;
  • 71. Modelando entidadesComparando os cheques com os pagamentos numextrato
  • 72. Entidades e identidade›  Em entidades, a identificação única não deve depender somente de seus atributos, deve haver um mecanismo de se identificar se dois objetos são os mesmos independente de o que eles aparentam ser;›  Um campo identificador (como o número do cheque) pode ser adicionado ao objeto para que ele possa ser comparado no futuro;›  Essa numeração deve ser garantidamente única e imutável (como em colunas de auto- incremento no banco de dados);
  • 73. Value objetcs›  Nem tudo no domínio são entidades;›  Value objects são objetos que representam valores e são comparados apenas pelos seus atributos, eles não tem identidade própria;›  Eles não são necessariamente simples, mas o fato de não existir identidade faz com que seja possível reutilizar, montar caches ou pre-carregar value objects sem maiores preocupações;
  • 74. Modelando value objectsO Endereço é um value object?
  • 75. Ao implementar value objects›  Elesnormalmente são imutáveis, depois de criados, não se alteram;›  É comum que sejam usados como no padrão de projeto “Flyweight”;›  Podem ser criados de forma indireta através de fábricas (que podem implementar caching);
  • 76. Services›  As vezes existem conceitos dentro do seu modelo que não são coisas, mas atividades;›  Serviços servem para implementar “verbos” que não estão cobertos por entidades ou value objects dentro do seu modelo;›  Eles são stateless, executam a sua operação mas não contém nenhum estado;
  • 77. Services e layers›  Serviços não existem somente na camada do domínio, eles podem estar também na camada de aplicação e infra estrutura;›  Serviços de aplicação podem ser responsáveis por organizar os dados antes deles chegarem no domínio;›  Serviços de infra estrutura podem ser responsáveis por falar com agentes externos a aplicação, como companhias de cartão de crédito;
  • 78. Modelagem de serviçosImplementando as interações com vários serviçosde cartão de crédito
  • 79. Serviços como fronteiras›  Para alguns autores, como Jacobson, existem também os objetos de “fronteira”;›  Taisobjetos são definidos por serem serviços que lidam com entidades externas ao sistema e enviam os dados para clientes;›  Essesserviços são vistos como serviços de infra estrutura;
  • 80. Serviços como Fronteiras - 2›  Fronteiras seriam qualquer entidade externa, como: ›  Usuáriosatravés de uma interface gráfica; ›  Web services; ›  Servidores de dados externos, como email e bancos de dados; ›  Arquivos;
  • 81. Módulos e Pacotes›  Num mundo ideal, deve existir baixo acoplamento entre pacotes diferentes e alta coesão dentro deles;›  Pacotes devem criar interfaces ou meios de acesso indiretos para as suas classes;›  Se você não faz parte de um pacote, não deve ficar olhando para todas as classes dele, deve haver uma fachada que faça com que você faça a sua tarefa;
  • 82. Integridade referencial nodomínio›  É difícil garantir a integridade referencial de um modelo quando todo mundo pode apontar pra todo mundo;›  Se uma Pessoa tem um Endereço e uma Conta aponta diretamente para o Endereço da pessoa, ao remover a Pessoa, o Endereço é removido e Conta fica apontando para o Nada;›  O uso de referências deve ser controlado de forma que as dependências sejam minimizadas;
  • 83. Aggregates›  É normal existir interdependências entre os objetos do modelo, mas também é normal que alguns objetos tornem-se mais importantes do que outros;›  Se uma Conta precisa saber o Endereço de uma Pessoa, ela deve antes chegar a Pessoa e depois acessar o Endereço;›  Aggregates definem os objetos que funcionam como raízes dos relacionamentos, protegendo os objetos que são internos a eles;
  • 84. Aggregates›  O objeto tido como raiz é o único objeto que pode ser referenciado por objetos que estejam “fora” do aggregate;›  Os objetos internos a raiz tem identidade própria, mas essa identidade normalmente também depende do objeto raiz, eles não existem se o objeto raiz não existir;
  • 85. Modelando um carroUm Cliente tem um Carro, ou tem Pneus, Direção,Caixa de Marcha?
  • 86. Repositories›  Fontes de objetos raiz carregados do mecanismo de persistência para o modelo;›  Devem ser responsáveis por apenas um único tipo de objeto, cada objeto deve ser o seu (ou seus) repositórios;›  Idealmente devem se comportar como se o cliente estivesse acessando dados em memória (não deve deixar vazar detalhes de sua implementação);
  • 87. Controllers›  Servempara orquestrar as chamadas que vem de serviços de infra-estrutura até os objetos de domínio (value-objects e entidades);›  Normalmente não contém lógica de aplicação e funcionam muito mais traduzindo dados externos para os objetos do domínio;
  • 88. Dúvidas?

×