Projeto de Software

Projeto de Software

1. Padrões GRASP

   • Básicos
     • Especialista
       • Atribuir responsabilidade para o especialista na informação
     • Criador
       • Atribuir à classe B a responsabilidade de criar uma instância da classe A se:
         • B agrega ou contém instâncias de A
         • B registra instância de A
         • B usa instância A de maneira muito próxima
         • B é um especialista na criação de A
     • Coesão Alta
       • Atribuir a responsabilidade de modo que a coesão (força do relacionamento entre as responsabilidades de uma classe) permaneça alta
     • Baixo Acoplamento
       • Atribuir a responsabilidade de modo que o acoplamento (dependência de classes) fique baixo
     • Controlador
       • Atribuir a responsabilidade de tratar um evento do sistema para a classe "controladora" representando:
         • O sistema como um todo
         • O negócio ou organização com um todo
         • Uma coisa ou papel de uma pessoa de mundo real envolvida diretamente com a tarefa
         • Um "tratador" artificial para todos os eventos de um caso de uso
   • Avançados
     • Polimorfismo
       • Problema
         • Como tratar alternativas baseadas no tipo ?
         • Como criar componentes interligáveis ?
         • Como evitar variação condicional (if-then-else) ?
       • Solução
         • Atribuir a responsabilidade pelo comportamento aos tipos para os quais o comportamento varia
     • Indireção
       • Problema
         • Onde colocar responsabilidade de modo a evitar acoplamento direto entre as classes ?
       • Solução
         • Atribua responsabilidade a um objeto intermediário que faça a mediação entre os componentes
     • Variação protegidas
       • Problema
         • Como projetar objetos, componentes de modo que as variações ou instabilidade nesses elementos não tenham um impacto indesejável sobre outros elementos ?
       • Solução
         • Identificar os pontos de instabilidades e atribuir responsabilidades para criar uma interface estável em torno deles
     • Invenção pura
       • Problema
         • Como atribuir responsabilidade que não se encaixam a nenhuma classe de domínio ?
         • Atribuir responsabilidade só a classes de domínio leva a situações de alto acoplamento e baixa coesão ?
       • Solução
         • Criar uma classe artificial que não representa nenhuma classe do domínio

2. Objetivo

   • Produzir um modelo que satisfaça ao requisitos

3. Diagrama de Interação

   • Diagrama de Sequência
     • Identifica quais mensagem devem ser disparadas entre os objetos e envolvidos e em que ordem
     • Apresentar as interações entre objetos na ordem temporal em que elas ocorrem
     • Elementos gráficos básicos
       • Atores
       • Objetos e classes
       • Mensagens
       • Linhas de vida e focos de controle
       • Criação e destruição de objetos
       • Iterações
   • Diagrama de Comunicação
   • Diagrama de visão geral de interação

4. Conceitos

   • Abstração
     • Permite que nos concentremos no problema em algum nível de generalização sem considerar detalhes
   • Arquitetura
     • Refere-se à “organização geral do software aos modos pelos quais disponibiliza integridade conceitual para um sistema”
   • Padrões
     • parte de um conhecimento consolidado já existente que transmite a essência de uma solução comprovada para um problema recorrente em certo contexto
   • Separação por interesses
     • Sugere que qualquer problema complexo pode ser tratado mais facilmente se for subdividido em partes para serem desenvolvidos independentemente
   • Modularidade
     • Permite que um sistema complexo seja compreendido a mente humana não consegue lidar com toda a complexidade dos sistemas de uma só vez
   • Encapsulamento de Informação
     • Sugere que cada módulo deve conter decisões de projeto que ele oculta dos outros módulos
   • Independência funcional
     • É alcançada através do desenvolvimento de módulos simples e uma "aversão" à interação excessiva com outros módulos
   • Refinamento
     • Uma elaboração maior no nível de detalhes
   • Refatoração
     • É o processo de mudança de um sistema de software de tal maneira que não altere o comportamento externo do código [design] e ainda melhora a sua estrutura interna

5. Caso de Uso

   • Elementos
     • Ator
     • Caso de Uso
   • Relaciomentos
     • Comunicação
       • Demonstra que o ator utiliza, de alguma maneira, a funcionalidade do sistema representada pelo caso de uso em questão, seja requisitando a execução daquela função, ou recebendo o resultado produzido por ela
     • Inclusão
       • Significa que o caso de uso base incorpora explicitamente o comportamento de um outro caso de uso
     • Extensão
       • É utilizado para descrever cenários opcionais de um caso de uso e esse cenário é o comportamento de outro caso de uso
     • Generalização
       • Significa que o Caso de Uso ou ator herda o comportamento e o significado do uso do pai
   • Documentação
     • Pré-condições
       • Descreve o que é necessário para o caso de uso ser executado
     • Pós-condições
       • Uma pós-condição é o estado que o sistema pode apresentar após o término do caso de uso
     • Fluxo de Eventos
       • Fluxo Principal
       • Fluxo Alternativo
       • Fluxo de Exceção
     • Regras do Negócio
       • São políticas, condições ou restrições que devem ser consideradas na execução dos processos de uma organização

6. Contrato

   • É um documento que descreve os compromissos de uma operação
   • Pré-condições (opcional)
     • Definem o que deve ser verdadeiro na estrutura da informação armazenada para que a operação ou consulta possa ser executada
     • Garantia de parâmetros
       • Pré-condições que garantem que os parâmetros da operação ou consulta correspondem a elementos válidos do sistema de informação
     • Restrição complementar
       • Pré-condições que garantem que a informação se encontra em uma determinada situação desejada
       • Tipos
         • Existe (ou não existe) uma instância (ou um conjunto de instâncias) com determinadas propriedades
         • Todas as instâncias (ou nenhuma das instâncias) de uma determinada classe (ou um conjunto definido por uma associação) têm determinadas propriedades
         • Uma associação não obrigatória (com multiplicidade de papel 0..1 ou *) existe (ou não existe) entre determinadas instâncias
         • Um determinado atributo de uma instância tem um certo valor
   • Pós-condições (obrigatório)
     • Devem ser expressas no passado, enfatizando mudanças de estado já ocorridas
     • Devem Ser declarativa
     • Expressa no contexto de objetos do modelo de domínio
     • Orientada por mudança de estados
     • Instância
       • Criação e destruição
     • Associação
       • Criação e destruição
     • Atributo
       • Modificação de valor
   • Exceções (opcional)