Resumo Slides Paulo Borba com Resoluções de Questões

YOUR ORDER NUMBER IS #3032874 • Triscar entre qualidade e produtividade • Investir muito em qualidade pode reduzir produtividade a custo prazo • Negligenciar qualidade pode impactar a produtividade até no curto prazo • Ética profissional não deve fazer parte da troca. Requisitos -> Inicialmente responder essas perguntas: • Quem usa o SW? • O que são os requisitos do sistema? • Quais funcionalidades do SW recebem o sistema? — Requisitos funcionais • Quais fatores de qualidade do SW recebem diversas funcionalidades? — Requisitos não-funcionais • Entendendo prioridades • Quais requisitos são mais importantes? -> 2 atividades principais • Elicitação de requisitos • Especificação de requisitos -> Elicitação de requisitos • Interagir o SW c/ entrevistados • abrangência e baixa fidelidade da GUI e storyboards SW como o todo, não de uma só funcionalidade • Fase inicial: entender as necessidades do SW • O que se espera deste sistema? • Funionalidades principais? • Fatores de qualidade essenciais? / ↳ Agrupar funcionalidades em feature. / ↬ depois de funcionalidade, discutir cenário -> Refinamento / ➔ Fazer que requisitos fiquem detalhados e novos features auxiliares sejam identificados / ↬ Desenvolver e discutir Lo-Fi GUI abrangente & storyboards • Confirmar expectativas -> Especificação de requisitos • Documento de requisitos • Feature (Luce or Not) ↬ definite [nome] as a [kind of SW] I want to [do some task] so that [I can achieve some goal] • Cenários de feature — Scenarios: • Given • When • Then / -> Foco em casos de execução concretos — Viés de teste, outros cenários reação a modelos como terjets • Expaficando melhor o comportamento do sistema • Necessidade de complementar exercícios -> Cenários da exceção ou do cancelador, não mencionam / gui são elementos extremamente limitados a qual acontece quando ele é minic round não usados elementos de GUI, abstração ou navegação. • Frequentemente usa s papel de storyboards • Foco em cenarios mais realistas e complicados: requirements, regras, restrições, sequencias destaque cores e etc • Evitar redundância. • Cenários de GUI → refere se diretamente a elementos de GUI, eventos e navegação de forma abstrata • Evitar baixa abstração de ação em cenários • Cenários declarativos, não imperativos! • Mais sobre cenários de GUI: foco nos comportamentos do sistema no geral e visual, foco nos títulos no estado de interface de usuários do sistema, frequentemente, especificar requis- das explícitas. Complementa cenários de cancelador. • Quantos e quais cenários? Marcar cobertura de casos → relevantes, poucos cenários não sicos p/ título # de funcíor; menor em consistência p/ simplicidade é impossível! • Exercício SMART = Specific, Measurable, Achievable, Relevant and Timebased -> Foco em requisitos funcionais • Conectividade tb (when 2 people...) • Positvo ou negativo -> Checklist | Processos 🅐 Deve respeitar os necessidades do SW 🅑 Domínio deve corresponder continuamente à semântica de cenários 🅒 Precisa ser sentença pequenas de pontos de comando/hue, And grif precise) 🅓 Não duplicar pontos de cenários. 🅔 Não duplicar cenarios. 🅕 Não deve ficar vaga ou incomplerte 🅖 Parametrizar de pontos de cenários 🅗 Especifique ações, usa não-ação non aceso objetos. 🅘 Evitar base de linguagem. 🅙 Usar ações de alto nívl 🅚 Esaca cenários independentes da plataforma 🅛 Fazer na situação de teste, direto ao ponto. • = não requisição geral. any pacge — -> Respostas de questões: 1) Os pontos não ficaram devidamente noramandardizados, no When não fez usado ações de alto nível e fases ago ao valor da previsibilidade. Principal problema foi a apresentação! • Given atual ligada com a 'luma2' And estux no <pagina> ''</pagina. “Disciplino do Penseito” Whem falecimento <to linha; And prencha a reta de 'lom' com 'g' 2) O principal problema é que o / modo muitas ações de baixo nível <de destração), desformando da situação do teste é em tudo divio ao ponto. • Given estou na pagina inicial when adicione o filme “Zorro” com descricao “Apoc | And adicionar “Apocalypse Now” com '' en?" Then deixo ''Apocalyse Now’ anta do “Zorro” na lista ordinidia. 4) São 4: escopo, tempo, qualidade e custo. Uma consequência é: quando se prioriza qualidade, o escopo ou duração do seu projeto negativo é tempo e ter custo altíssimo é econômica. Outra consequência é: Se prioriza tempo e qualidade o seu escopo tera que diminuir consideravelmente pl poder respectar código com qualidade alta desejando nem ten- po curto. Testes - Testes de aceitação - Comparam diretamente requisitos (cenários) e testers - Executa o sistema através de sua GUI - Cenario escritos baseados na GUI com apoio de testes baseados na GUI. - Pense executam o sistem em teste simulando ações do usuário no browser. - Aplicação como uma máquina de estados - Grafo representando estados e percorrer transição - Comportamento esperado pela transição deve aparecer como caminhos nesse grafo, compor- tamento não desejado não deve aparecer. - Cenários devem verificaq que caminhos desejados passam nas observadas testando a app - Executando o sistema através do servidor - Comunicação baseada em mensagens tere contexto no ponto de testes baseados em serviços. - Cenários executam o sistema em teste invocando serviços. - Testes da execução (unidade, integração, sistema) - Teste de execução não tem ligação com cenários, uma descrição e it - Aplicar os metodos em um novo ambiente : lehae All, após All ( server close server), server execute / do service. - Código executa o sistema invocando serviços. - Testes de execução (unidade, integração) - Tarefas não executar sem ligação com cenários. - Aplicar cada; exec métodos serv. - Código executa o sistema invocando métodos. - Princípios para todo teste: - Rode teste com diferentes argumentos e contexto de estado - Us casos limite/infinitier', foem no coletora. - Cases positivos e negativos. - Teste da aceitação -> ver na nova commit quebra alguma funcionalidade. - Balanceamento entre o serviço, classes e aceitação. - Serviced... unidade e integração. - Práticas para todo teste: - Parametrização - Cada teste pode rodar independentemente dos outros, assumindo uma nova instância de app - Pense estado entre testes - Antes de dar push (o veego at commit), tenha oq que todos testes passaram (segurezza). - BDD - Behavior driver design - Implementação de testes ... feita antes das implementação dos features. - Criação da interface quarto poca funcionalidades estará disponibles. - Checkout - Comportamento de teste deve correspondem estritamente à semântica de cenário. - Evite ambiguidade devido a pontas (sentences) normativas. - Não duplique codigos de teste - Testes devem ser independentes de plataforma. - Test driven limpar o ambiente no final (inclusive em browser) e de linguagem. Refatorecação - Problemas de reuso - Problemas de modularidade - Débito Técnico - Manutenção custa caro - 1ª lei de Lehman - Preguntar que o código só fica num processo de melhora continua ou só tem progressên versma menos funcional. O processo da mudanca continua até que mais julgadce é eficaz (em relação aos custos) subsistir o sistema por uma versões racicadai. - 2ª lei de Lehman Enquanto um grande programa e continuamento mudado, snua complexidade, o qual reflecte a na diferenciación da estruturalód, aumenta a reěa sue que trabalho 63a feito pi mentar Eu- 3” leisö.” - Como resolver os problemas e reduzir o débito? ...novando o comportamento (realização dos testes). - Refatoração - precisa complementary, foi transparentesso usarce a source que subtram - Fatores de qualidade internos (como legibilidade, reusoablidade, m.j, etc) - Extract method refatoracao - Para resolver problemas de reuso e modularidade - Usei os metodos com bocados de codigo anterior pl evitar repetição de várias linhas. - Rede useit otei smil água b. - Refatoração automatizada - Esses documentos não dão nenhuma garantia de preservação do comportamento (testes ...fzerena são aplicada tal quai sunt appear). - Extract classe - Quando a classe esta fazendo trabalho que deveria ser feito por 2 - Criae-se uma nova classe e transfere os campos relevantes métodos da classe antiga pl ena - Meternos visa reescrever programs q que não entass abstract., p/ vez 1999. - Como escolher os alvos de refatoração? - Mou diraáres baseados en valones, princípios e padrões. - Estratégias : 1) Identificaçao e problema; 2) há algoritn padrão pel problema neste ambient? 3) Ni necessidade uñ solução baseada en valores e princípios; 4) Aplique refatoração apropriada; 5) Testfel. - Questions 1) Teste de regressão é aquele que verifica no altoracao feita no código quebaï algo qua atém do mudación estava functionando + benéfico para o refators ground sua ärá validado dia que pre- xrevvar o comportamento do códing, o que o teste de regressão verifica. 2) Quando uma classe esta fazendo um trabalho aqui deveria ser ou de, por exemplo uma clase here implementan un próprio fudatorio minus couactistico e inhibits, o criptados de felix ... foer oiba, 이 3) Cria-se uma nova classe e distrana os campos e methods rolloutos a cada class (amariga aarea). Design, implementação e manutenção - MDD (Model Driven Development) - Design de todos o nível - Deve ser guiado por: valores, princípios e padrões (arquiteturas, de design e de implementações) - Valores de design: - Comunicação face no behavior - Simplicity - eliminar excesso de complexidade - Flexibility - permitir mudar, disseminar separadamente. - Feedback: mesmo correspondendo ao comportamento. - Princípios de design: SOLID - Simple Responsibility: uma classe deve ter uma única responsabilidade. - Open Closed: um módulo deve estar aberto p/ extensão e fechado p/ modificação. - Liskov Substitution: subclasses devem ser substituíveis pelas suas superfícies de classes bases. - Dependency Inversion: as dependências devem ocorrer entre interfaces de abstração de inversão - Dependency Injection: depende de uma interface específica e de uma execução possível para evitar classes de código ou simplesmente uma instância disponível - Mais princípios de design: da área de campos de C. - Dependency Injection: depende de abstrações, não concretas. - Inversion of Control: é possível chamar polimorfização abstrações tornam concretas. - Interface Separation: várias interfaces específicas p/ cliente é melhor que 1 geral. - Princípio do pacote: - Relação entre equivalência: a granularidade de reuso e a granularidade de lançamento. - Common classes: classes que mudem juntos, devem permanecer juntos. - Common reuses principle: classes que não têm resultado juntos não devem ser agrupadas juntas. Princípio da Adaptar p/ : ciclo - Strategy - Análise e padrão de mudança - Alguém permite p/ este contexto? - Nova solução baseada em reflexões e princípios? - Alguns padrões ou princípios apropriados? - Chegou na nova funcionalidade quebra testes existentes. - Consertos: 1) O princípio 'Dependency Injection' diz que se 2 classes dependendo um do outro, novas mudanças na implementação podem mudar, sendo bom para ambos dependências de uma interface abstrata separada como interface anexa (association). 2) O padrão de projeto 'Adopter' tem por objetivo fazer com que 2 classes que usaram APIs diferentes, permitam ser unificadas como um API externo faz uma reutilização completa com a classe do cliente existente. Diagrama de classes: - Cliente - Target - Requerimento - Adopter - Adaptee 3) Ao seguir o princípio 'Acyclic dependencies' temos uma nova independência entre os pacotes e, portanto, uma alteração em outros não afeta o outro, o que faz sentido já que classes que existem em pacotes diferentes não deveriam depender uma da outra - esse resultado foi procedido usando a interface que já propondo a reutilização do código, após mudança dentro de um contexto aplicado. 4) O padrão de projeção 'Decorator' evita duplicação de código, o que é comum, ou seja, com mais delegação técnica que era repetida, pois tendo de uma classe abstrata (comando) que pensa sumariamente conceitua que implementa muitos básicos que ficam comuns a todos e permitiu-se 'comportamento' em variação commandar, que propôs o reuso do código, já que não necessitas criar uma nova classe que implemente o funcionalidades (as quais já tem suas classes próprias) desse formato, o cliente simplesmente executará código dos funcionamentos que ele requises é ele pode "simplificar e solução boa de forma que quisesse. Diagrama de classe: - ControlComponent (operation) - ConcreteDecorator (operation) - ConcreteComponent (operation) O princípio 'Single Responsibility' preconiza que um método de uma classe não deve chamar métodos de classes imediatamente ligadas ou não. Ao evitar ocorrências de dependências em classes que não devem rodar, portanto em classes mais distantes queremos assim não existiram. 6) O padrão de projeto 'Abstract Factory' cria uma classe específica para criar objetos do factory e nesta a combinação desse conceito e não tem seu construtor com código muito granular cumpre a encomenda de uma tonelagem, esse permitiria a classe 'prejudicando legibilidade'. Diagrama de classes: - Cliente - AbstractFactory - CreateProduct : AbstractProduct - ConcreteFactory - Product