Software

Software

Modelagem
1. Uml
  1. Diagrama caso de uso
    1. Identificação de atores e serviços
  2. Diagrama de Classes
    1. Definição da estrutura e das classes
  3. Diagrama de objeto
    1. Mostrar valores armazenados pelo objeto
  4. Diagrama de Estrutura Composta
    1. Visões de um conjunto de entidades
  5. Diagrama de Sequência
    1. Desenrolar dos eventos
  6. Diagrama de Comunicação
    1. mostrar como objetos estão interligados e mensagens trocadas sem preocupação de tempo
  7. Diagrama Máquina de Estado
    1. Informar mudança de Estado a partir de uma instancia
  8. Diagrama de Atividades
    1. Comportamento de objetos entre vários casos de uso
  9. Diagrama de Interação
    1. Comportamentos de objetos entr eum uníco caso de uso
  10. Diagrama de Componentes
    1. Demonstrar componentes que fazer parte do sistema e seus relacionamentos
  11. Diagrama de Implantação
    1. Necessidades físicas do sistema
  12. Diagrama de Pacotes
    1. Decompõe o sistema geral em subsistemas que o compõe
  13. Diagrama de Tempo
    1. Indica mudança de estado do objeto e o tempo de resposta da mudança
Remodelagem
1. Reengenharia
  1. Recriar um sistema já projetado
Engenharia Reversa
1. Entender um código já construido e decompor o mesmo
Linguagens
1. C++
2. Java
3. Problemas no desenvolvimento
  1. 7 Pecados capitais
    1. Pressa
      1. Qualidade em segundo plano
    2. Apatia
      1. não se importar em resolver problemas conhecidos
    3. Mente estreita
      1. recusa em usar soluções reconhecidamente efetivas
    4. Preguiça
      1. caminho mais "facil" em vez de refletir sobre a decisão
    5. Avareza
      1. Detalhes excessivos, maior complexidade
    6. Ignorância
      1. falha em buscar compreensão
    7. Orgulho
      1. investimento em desenvolver soluções que poderiam ser aproveitadas de outras fontes
Coesão
1. Alta coesão
  1. Classes se relacionam, sistema unico
2. Baixa coesão
  1. Classes se relacionam, mas há divisões em subsistemas
Acoplamento
1. Alto acoplamento
  1. Relacionamentos demais entre as classes
2. Baixo acoplamento
  1. Muito pouco relacionamento entre as classes
Problema durante o desenvolvimento
1. Contexto e forças
  1. Solução Padrão
    1. Padrões de Projeto
      1. Interface
        Adapter
        Ajustar a interface de uma classe à interface que o cliente espera
        Façade
        Oferecer uma interface única para uma coleção de classes
        Composite
        Definir uma interface que se aplica a objetos individuais ou a grupos de objetos
        Bridge
        Desacoplar uma abstração de sua implementação de forma que as duas possam variar independentemente
      2. Responsabilidade
        Singleton
        Centralizar responsabilidade em uma única instância da classe
        Observer
        Desacoplar um objeto do conhecimento de quais outros objetos dependem dele
        Mediator
        Centralizar responsabilidade em uma classe que supervisiona como um conjunto de outros objetos interagem
        Proxy
        Deixar um objeto atuar em nome de outro objeto
        Chain of responsibility
        Permitir que uma requisição passe por uma sequência de objetos até encontrar um que possa atendê-la
        Flyweight
        Centralizar responsabilidade em pequenos objetos compartilhados
      3. Construção
        Builder
        Obter gradualmente a informação necessária para construir um objeto
        Factory Method
        Adiar a decisão sobre qual classe instanciar
        Abstract Factory
        Construir uma família de objetos
        Prototype
        Construir um objeto a partir de exemplo existente
        Memento
        Reconstruir um objeto a partir de informação de estado anteriormente salva
      4. Comportamento
        Command
        Ecapsular a invocação de um método em um objeto
        Template Method
        Implementar um algoritmo em um método, deixando a definição de alguns passos do algoritmo para subclasses que podem refiná-lo
        State
        Distribuir uma operação de modo que cada classe represente um estado diferente
        Interpreter
        Distribuir uma operação de modo que cada implementação seja aplicável a um tipo diferente de composição
        Strategy
        Encapsular uma operação, tornando as implementações intercabiáveis
      5. Extensão
        Decorator
        Acrescentar responsabilidades adicionais a um objeto dinamicamente
        Iterator
        Oferecer um modo de acessar uma coleção de instâncias de uma classe
        Visitor
        Acrescentar novas operações a uma classe sem alterar a classe
  2. Solução anti padrão
    1. Anti padrões de Projeto
      1. Arquitetura
        Stovepipe Enterprise
        Sistemas múltiplos em uma empresa são desenvolvidos independentemente em cada nível
        Jumble
        Elementos de design horizontal (comum em todas aplicações) e vertical (dependen de implementações específicas são misturados
        Vendor Lock-In
        custo de mudar de fornecedor do produto ao qual o usuário é dependente para outro é muito alto
        Architecture By Implication
        falta de especificação (documentação) na arquitetura de um software em desenvolvimento, devido a experiências anteriores em construçãod e sistemas parecidos
        Design by Committee
        Swiss army knife
        tentativa de prover uma classe para diversas necessidades, o designer adiciona um grande numero de assinaturas de interface e, a classe de interface acaba ficando extremamente complexa
        Reinventing the wheel
        necessidade de contornar restrições técnicas, incompatibilidades e licenciamento de softwares presentes em partes ou módulos de terceiros. ao invés de pegar uma solução existente e adequada, adota-se uma solução customizada com desempenho pior que a existente
      2. Desenvolvimento
        Functional Decomposition
        Possui uma classe que funciona como uma rotina Main, a partir dela várias outras sub-rotinas são chamadas e, para cada sub-rotina, uma classe é implementada, cuja classe serve apenas para efetuar a ação
        Poltergeist
        Boat Anchor
        parte do código de um sistema ou uma peça de hardware que não tem nenhuma utilidade no projeto atual
        Golden Hammer
        Ferramenta específica que é dominada pela equipe e é utilizada de forma generalista (bom pra tudo)
        Dead End
        Quando tenta incorporar um módulo já pronto porém com incompatibilidade de suporte
        Spaghetti Code
        programa ou sistema que contém muito pouca estrutura de software. Codificação compromete a estrutura de suporte lógico (resultado do código antigo que está sendo modificado ao longo dos anos)
        Walking through a minefield
        prática de lançar um sistema sem que seus erros sejam avaliados corretamente para ganhar tempo
        Copy and Paste Programming
        É a cópia e modificação de um código existente ao invés de criar solução genéricas (identificado pela presença de vários segmentos de código semelhantes intercalados ao longo do projeto)
      3. Gerencial
        Analysis Paralysis
        Caracterizado por revisões constantes e construção de modelos excessivamente detalhados. Torna o sistema difícil de desenvolver, documentar e testar
        Death By Planning
        Falta de uma abordagem pragmática (objetiva) para o planejamento, cronogramas e captura do processo
        Corncob
        pessoa difícil que causa problemas através de um comportamento destrutivo em relação a equipe ou projeto (alguém discorda dos objetivos ou processos-chave)

Next up

Description

Resource summary

Similar

	Created by Ivan Filho over 9 years ago