Lista de Verificação: Design |  |
Esta lista de verificação contém questões que ajudam a avaliar se o design foi criado de forma consistente e completa.
Relacionamentos
Elementos Relacionados | Analisar o Design Desenvolvimento Design Design Evoluir o Design Re-fatoração
Descrição Principal
Os itens nesta lista de verificação representam boas práticas para criar e comunicar um design robusto. Tente trabalhar cada item com a maior extensão possível para criar o melhor design. Pode não ser possível utilizar todos os itens, e alguns itens podem ser utilizados com abrangência limitada. Nestes casos, tenha certeza que existem boas razões para utilizar um item parcialmente ou não utiliza-lo. O design pode ser feito diariamente. Use esta lista de verificação regularmente para assegurar um design robusto, consistente e compreensível. Faça com que o design seja bom o bastante para as metas específicas que estão sendo tratadas pelo uso desta lista de verificação para identificar as áreas que foram deixadas de lado, ignoradas ou insuficientemente direcionadas.
Itens de Verificação
O design está entendível?
O design está organizado de forma que os membros da equipe possam encontrar facilmente as informações que eles estão procurando? O design está simples o bastante ao mesmo tempo em que cumpre os objetivos do design e fornece direção suficiente para as pessoas que implementam? O design não está nem muito simples nem muito avançado? A sofisticação do design deve ser apropriada para o nível de experiência dos outros membros da equipe e dos Stakeholders técnicos. Isto se aplica ao conceito e à representação do design. O design expressa o que o projetista deseja expressar?
O design está consistente?
O design segue algum padrão de design? O design aplica outros idiomas consistentemente? Os nomes dos elementos de design estão consistentes e fáceis de interpretar? Alguma parte do design contradiz uma outra parte de forma que ponha o projeto em risco? Se o design estiver construído visualmente, a notação usada para descrever o design está sendo utilizada consistentemente de forma que ele possa ser entendido e inequívoco?
O design está manutenível?
O design está estruturado o bastante para ser mantido? O design está pronto para acomodar apropriadamente mudanças esperadas? O design não deve ser super-construído para tratar qualquer mudança possível, somente as mudanças razoavelmente esperadas. As áreas redundantes do design foram removidas de forma que a implementação não contenha código redundante?
É possível rastrear o design?
Está claro como os elementos de design se relacionam com os requisitos? Isto não precisa envolver uma estratégia de rastreamento complexa, mas existe alguma forma de descobrir qual parte do design suporta um requisito em particular? Quais partes da implementação suportam claramente cada elemento de design?
O design reflete os objetivos arquiteturais do sistema?
O design está em conformidade com a arquitetura conforme o especificado? Ele usa os padrões arquiteturais apropriadamente? Os Mecanismos Arquiteturais estão sendo usados apropriadamente? Estão sendo usados em todas as circunstâncias onde são aplicáveis?
Os elementos de design são modulares?
Os elementos de design têm alta coesão interna? O grau de interação da unidade demonstra que todas as partes internas estão juntas? Os elementos de design têm baixo acoplamento? Existe uma mínima independência entre os elementos de design? Quando os elementos de design dependem uns dos outros, eles são construídos o mais simples possível e de forma que o elemento cliente não será afetado pelas mudanças nas partes internas do elemento fornecedor? Os elementos de design estão definidos com interfaces abstratas de forma que mudanças possam ser feitas na implementação interna sem afetar os elementos de design clientes? Cada elemento de design representa uma abstração claramente definida?
O sistema pode ser implementado a partir das informações no design?
Existe suficiente detalhamento para direcionar a implementação? O design restringe a implementação somente o necessário? O design permite que a pessoa de implementação tenha liberdade de implementá-lo apropriadamente? O design é viável? É um design que pode ser razoavelmente implementado pela equipe, utilizando as tecnologias selecionadas durante o projeto?
O design fornece bastantes informações para os testes de desenvolvedor?
O design fornece bastantes informações para a criação dos testes de desenvolvedor? O ambiente esperado e as restrições nos métodos estão claros? As colaborações entre os elementos de design estão bastante claras de forma que os testes de integração possam ser criados?
O design descreve o sistema em um nível apropriado de abstração?
O design descreve o sistema em um nível apropriado de abstração, mostrando os objetivos? Isto normalmente significa que o sistema está descrito em níveis diferentes de abstração e em diferentes perspectivas.
O design suporta uma perspectiva genérica do sistema?
O design pode ser entendido como um conjunto de subsistemas altamente ordenados? As dependências de subsistema estão documentadas? As interfaces estão definidas claramente para cada subsistema? Cada subsistema está projetado de forma que seus serviços possam ser acessados através da interface sem a necessidade de acessar as partes internas? Cada subsistema está projetado de forma que qualquer um possa trabalhar em um elemento sem ter que entender as partes internas dos outros elementos?
Pacotes e Organização
A divisão em pacotes está lógica e consistente? Faz sentido para os membros da equipe e os Stakeholders? Os nomes dos pacotes descrevem exatamente seu conteúdo e o papel que executam na arquitetura? Eles seguem as convenções de criação de nomes? As interfaces e os pacotes públicos fornecem um conjunto de serviços logicamente coesivos? Todo o conteúdo de um pacote esta listado? As classes dentro de um pacote estão coesivas? As dependências entre pacotes correspondem às dependências das classes contidas neles? Existem pacotes ou classes dentro de um pacote que podem ser separadas em um pacote independente ou em um sub-pacote?
Visões
Cada diagrama ajuda o analista a raciocinar sobre o design, ou comunica as principais decisões de design à equipe? Os relacionamentos entre os diagramas estão claros quando diversos diagramas são usados para descrever um comportamento? É fácil navegar entre os diagramas relacionados? Cada diagrama foca uma perspectiva relevante? Por exemplo, um grupo de diagramas mostra uma única classe e seus relacionamentos diretos, ao invés de usar um ou dois diagramas para mostrar todas as classes? Cada diagrama está completo e mínimo? Mostra tudo que é relevante para a visão e nada mais? Os diagramas estão arrumados e fáceis de interpretar, com o mínimo de desordem?
UML
O modelo visual está em conformidade com os padrões da UML, de forma que todos os Stakeholders possam sempre compreender o modelo? (Veja a Página de recursos UML da OMG Para maiores informações). O modelo visual está em conformidade com os padrões de modelagem específicos do projeto ou da organização? O modelo visual está consistente internamente? Por exemplo, se um diagrama de objetos mostra um relacionamento entre objetos, existe um relacionamento corresponder entre as classes apropriadas? O nome de cada classe reflete claramente o seu papel? Cada classe fornece o comportamento desejado? Há pelo menos uma associação de realização definida para cada interface? A realização pode representar uma implementação do subsistema feita por terceiros. Existem associações de dependência de cada subsistema com as interfaces que eles usam? Cada operação, em uma interface de subsistema, está descrita em um diagrama de seqüência ou, pelo menos, mapeada diretamente para uma operação em uma classe? Cada classe representa uma única abstração bem definida? Os relacionamentos de generalização estão sendo usados somente para definições de herança e não de comportamento (implementação)? Ou seja, o comportamento é compartilhado através do uso de relacionamentos de associação, agregação e contenção ao invés de generalização? As classes pai são abstratas em relacionamentos de generalização? As classes "folha" são as únicas classes concretas em uma hierarquia de generalização? Os estereótipos são usados com consistência e significado? Existem gráficos de estado para classes com mudanças de estado complexas ou restritivas? Os relacionamentos têm nomes descritivos de papel ou de associação (um ou outro, mas não ambos), e multiplicidades corretas? Os relacionamentos entre as classes são, sempre que possível, unidirecionais?
Modelagem Visual Não-UML
A semântica da linguagem de modelagem visual está claramente definida, documentada e acessível aos membros da equipe? A semântica deve ser significativa para as pessoas que usam o modelo. A semântica da linguagem de modelagem pode ser sempre compreendida? A linguagem está documentada suficientemente de modo que os membros da equipe possam compreender o modelo, mesmo depois de bastante tempo das decisões de design terem ocorrido? Os membros da equipe e os stakeholders estão treinados na linguagem de modelagem que está sendo usada? O modelo visual está em conformidade com a semântica da linguagem de modelagem visual? Ou seja, o significado dos símbolos nos diagramas está consistente em todo o modelo e todos os diagramas?
Este programa e o material que o acompanha são disponibilizados sob a Eclipse Public License v1.0 que acompanha esta distribuição. Direitos Autorais do OpenUP.