Design de software

Da Wikipédia, a enciclopédia livre
Ir para navegação Pular para pesquisar

Projeto de software é o processo pelo qual um agente cria uma especificação de um artefato de software com o objetivo de cumprir objetivos , usando um conjunto de componentes primitivos e sujeito a restrições . [1] O projeto de software pode se referir a "todas as atividades envolvidas na conceituação, enquadramento, implementação, comissionamento e, em última instância, modificação de sistemas complexos" ou "a atividade após a especificação de requisitos e antes da programação , como ... [em] um software estilizado processo de engenharia. " [2]

O projeto de software geralmente envolve a resolução de problemas e o planejamento de uma solução de software . Isso inclui um componente de baixo nível e projeto de algoritmo e um projeto de arquitetura de alto nível .

Visão geral [ editar ]

O design de software é o processo de prever e definir soluções de software para um ou mais conjuntos de problemas. Um dos principais componentes do projeto de software é a análise de requisitos de software (SRA). SRA é uma parte do processo de desenvolvimento de software que lista as especificações usadas na engenharia de software . Se o software for "semiautomático" ou centrado no usuário , o design do software pode envolver o design da experiência do usuário, gerando um storyboard para ajudar a determinar essas especificações. Se o software for totalmente automatizado (ou seja, sem usuário ou interface de usuário), um projeto de software pode ser tão simples quanto um fluxograma ou texto que descreve uma sequência planejada de eventos. Existem também métodos semipadrão, como Linguagem de Modelagem Unificada e conceitos de modelagem Fundamentais . Em ambos os casos, alguma documentação do plano é geralmente o produto do design. Além disso, um projeto de software pode ser independente da plataforma ou específico da plataforma , dependendo da disponibilidade da tecnologia usada para o projeto.

A principal diferença entre a análise e o projeto de software é que a saída de uma análise de software consiste em problemas menores a serem resolvidos. Além disso, a análise não deve ser projetada de maneira muito diferente entre os diferentes membros da equipe ou grupos. Em contraste, o projeto se concentra nos recursos e, portanto, podem existir vários projetos para o mesmo problema. Dependendo do ambiente, o design geralmente varia, seja ele criado a partir de estruturas confiáveis ou implementado com padrões de design adequados . Exemplos de design incluem sistemas operacionais, páginas da web, dispositivos móveis ou até mesmo o novo paradigma de computação em nuvem.

O design de software é um processo e um modelo. O processo de design é uma sequência de etapas que permite ao designer descrever todos os aspectos do software para construção. Habilidade criativa, experiência anterior, senso do que torna um software "bom" e um compromisso geral com a qualidade são exemplos de fatores críticos de sucesso para um design competente. É importante observar, entretanto, que o processo de design nem sempre é um procedimento direto; o modelo de design pode ser comparado aos planos de um arquiteto para uma casa. Ele começa representando a totalidade do que está para ser construído (por exemplo, uma representação tridimensional da casa); lentamente, a coisa é refinada para fornecer orientação para a construção de cada detalhe (por exemplo, a configuração do encanamento). De forma similar,o modelo de design criado para o software fornece uma variedade de visões diferentes do software de computador. Os princípios básicos de design permitem que o engenheiro de software navegue no processo de design. Davis[3] sugere um conjunto de princípios para o design de software, que foram adaptados e estendidos na seguinte lista:

  • O processo de design não deve sofrer de "visão de túnel". Um bom projetista deve considerar abordagens alternativas, julgando cada uma com base nos requisitos do problema e nos recursos disponíveis para realizar o trabalho.
  • O design deve ser rastreável ao modelo de análise. Como um único elemento do modelo de design muitas vezes pode ser rastreado até vários requisitos, é necessário ter um meio de rastrear como os requisitos foram atendidos pelo modelo de design.
  • O design não deve reinventar a roda. Os sistemas são construídos usando um conjunto de padrões de projeto, muitos dos quais provavelmente já foram encontrados. Esses padrões sempre devem ser escolhidos como uma alternativa à reinvenção. O tempo é curto e os recursos são limitados; o tempo de design deve ser investido na representação de ideias (verdadeiramente novas) integrando padrões já existentes (quando aplicável).
  • O design deve "minimizar a distância intelectual" entre o software e o problema como ele existe no mundo real. Ou seja, a estrutura do projeto do software deve, sempre que possível, imitar a estrutura do domínio do problema.
  • O projeto deve exibir uniformidade e integração. Um design é uniforme se parecer totalmente coerente. Para atingir este resultado, regras de estilo e formato devem ser definidas para uma equipe de design antes do trabalho de design começar. Um design é integrado se for tomado cuidado ao definir as interfaces entre os componentes do design.
  • O design deve ser estruturado para acomodar mudanças. Os conceitos de design discutidos na próxima seção permitem que um design atinja esse princípio.
  • O projeto deve ser estruturado para degradar suavemente, mesmo quando dados, eventos ou condições operacionais aberrantes forem encontrados. Um software bem projetado nunca deve "bombar"; ele deve ser projetado para acomodar circunstâncias incomuns e, se precisar encerrar o processamento, deve fazê-lo de maneira elegante.
  • Design não é codificação, codificação não é design. Mesmo quando designs de procedimentos detalhados são criados para componentes de programa, o nível de abstração do modelo de design é maior do que o código-fonte. As únicas decisões de design feitas no nível de codificação devem abordar os pequenos detalhes de implementação que permitem que o design procedural seja codificado.
  • O design deve ser avaliado quanto à qualidade à medida que está sendo criado, não após o fato. Uma variedade de conceitos e medidas de design estão disponíveis para auxiliar o designer na avaliação da qualidade em todo o processo de desenvolvimento.
  • O design deve ser revisado para minimizar erros conceituais (semânticos). Às vezes, há uma tendência de focar em minúcias quando o projeto é revisado, deixando de lado a floresta para as árvores. Uma equipe de design deve garantir que os principais elementos conceituais do design (omissões, ambigüidade, inconsistência) foram tratados antes de se preocupar com a sintaxe do modelo de design.

Conceitos de design [ editar ]

Os conceitos de design fornecem ao designer de software uma base a partir da qual métodos mais sofisticados podem ser aplicados. Um conjunto de conceitos fundamentais de design evoluiu. Eles são os seguintes:

  1. Abstração - Abstração é o processo ou resultado da generalização, reduzindo o conteúdo de informação de um conceito ou fenômeno observável, normalmente a fim de reter apenas a informação que é relevante para um propósito particular. É um ato de representar características essenciais sem incluir os detalhes ou explicações do plano de fundo.
  2. Refinamento - é o processo de elaboração. Uma hierarquia é desenvolvida pela decomposição de uma instrução macroscópica de função em etapas até que as instruções da linguagem de programação sejam alcançadas. Em cada etapa, uma ou várias instruções de um determinado programa são decompostas em instruções mais detalhadas. Abstração e refinamento são conceitos complementares.
  3. Modularidade - A arquitetura do software é dividida em componentes chamados módulos.
  4. Arquitetura de software - refere-se à estrutura geral do software e às maneiras pelas quais essa estrutura fornece integridade conceitual para um sistema. Uma boa arquitetura de software produzirá um bom retorno sobre o investimento em relação ao resultado desejado do projeto, por exemplo, em termos de desempenho, qualidade, cronograma e custo.
  5. Hierarquia de controle - uma estrutura de programa que representa a organização de um componente do programa e implica em uma hierarquia de controle.
  6. Particionamento Estrutural - A estrutura do programa pode ser dividida tanto horizontal quanto verticalmente. As partições horizontais definem ramos separados da hierarquia modular para cada função principal do programa. O particionamento vertical sugere que o controle e o trabalho devem ser distribuídos de cima para baixo na estrutura do programa.
  7. Estrutura de dados - é uma representação da relação lógica entre os elementos individuais dos dados.
  8. Procedimento de software - concentra-se no processamento de cada módulo individualmente.
  9. Ocultação de informações - os módulos devem ser especificados e projetados de forma que as informações contidas em um módulo fiquem inacessíveis a outros módulos que não precisam dessas informações.

Em seu modelo de objeto, Grady Booch menciona Abstração, Encapsulação, Modularização e Hierarquia como princípios fundamentais de design de software. [4] O acrônimo PHAME (Princípios de Hierarquia, Abstração, Modularização e Encapsulamento) às vezes é usado para se referir a esses quatro princípios fundamentais. [5]

Considerações de design [ editar ]

Há muitos aspectos a serem considerados no projeto de um software. A importância de cada consideração deve refletir as metas e expectativas para as quais o software está sendo criado. Alguns desses aspectos são:

  • Compatibilidade - O software é capaz de operar com outros produtos projetados para interoperabilidade com outro produto. Por exemplo, um pedaço de software pode ser compatível com uma versão anterior de si mesmo.
  • Extensibilidade - novos recursos podem ser adicionados ao software sem grandes mudanças na arquitetura subjacente.
  • Modularidade - o software resultante compreende componentes independentes e bem definidos que levam a uma melhor manutenção. Os componentes podem ser implementados e testados isoladamente antes de serem integrados para formar um sistema de software desejado. Isso permite a divisão do trabalho em um projeto de desenvolvimento de software.
  • Tolerância a falhas - O software é resistente e capaz de se recuperar de falhas de componentes.
  • Manutenibilidade - Uma medida de quão facilmente correções de bugs ou modificações funcionais podem ser realizadas. A alta capacidade de manutenção pode ser o produto da modularidade e extensibilidade.
  • Confiabilidade ( durabilidade do software ) - O software é capaz de executar uma função exigida sob as condições estabelecidas por um período de tempo especificado.
  • Reutilização - A capacidade de usar alguns ou todos os aspectos do software preexistente em outros projetos com pouca ou nenhuma modificação.
  • Robustez - O software é capaz de operar sob estresse ou tolerar entradas imprevisíveis ou inválidas. Por exemplo, ele pode ser projetado com resiliência a condições de pouca memória.
  • Segurança - O software é capaz de suportar e resistir a atos e influências hostis.
  • Usabilidade - A interface de usuário do softwaredeve ser utilizável para seu usuário / público-alvo. Os valores padrão dos parâmetros devem ser escolhidos de forma que sejam uma boa escolha para a maioria dos usuários. [6]
  • Desempenho - O software executa suas tarefas em um período de tempo aceitável para o usuário e não requer muita memória.
  • Portabilidade - o software deve ser utilizável em várias condições e ambientes diferentes.
  • Escalabilidade - O software se adapta bem a dados crescentes ou recursos adicionais ou número de usuários.

Modeling Language [ editar ]

Uma linguagem de modelagem é qualquer linguagem artificial que pode ser usada para expressar informações, conhecimento ou sistemas em uma estrutura definida por um conjunto consistente de regras. Essas regras são usadas para interpretação dos componentes dentro da estrutura. Uma linguagem de modelagem pode ser gráfica ou textual. Exemplos de linguagens de modelagem gráfica para design de software são:

Padrões de projeto [ editar ]

Um designer ou arquiteto de software pode identificar um problema de design que já foi visitado e talvez até mesmo resolvido por outros no passado. Um modelo ou padrão que descreve uma solução para um problema comum é conhecido como padrão de design . A reutilização de tais padrões pode ajudar a acelerar o processo de desenvolvimento de software. [8]

Técnica [ editar ]

A dificuldade de usar o termo "design" em relação ao software é que, em alguns sentidos, o código-fonte de um programa é o design do programa que ele produz. Na medida em que isso seja verdade, "design de software" se refere ao design do design. Edsger W. Dijkstra se referiu a essas camadas de níveis semânticos como a "novidade radical" da programação de computador, [9] e Donald Knuth usou sua experiência escrevendo TeX para descrever a futilidade de tentar projetar um programa antes de implementá-lo:

O T E X teria sido um fracasso total se eu simplesmente o tivesse especificado e não participado totalmente de sua implementação inicial. O processo de implementação constantemente me levou a perguntas inesperadas e a novos insights sobre como as especificações originais poderiam ser melhoradas. [10]

Uso [ editar ]

A documentação do projeto do software pode ser revisada ou apresentada para permitir que restrições, especificações e até mesmo requisitos sejam ajustados antes da programação do computador . O redesenho pode ocorrer após a revisão de uma simulação ou protótipo programado . É possível projetar software no processo de programação, sem um plano ou análise de requisitos, [11] mas para projetos mais complexos isso não seria considerado viável. Um design separado antes da programação permite que designers multidisciplinares e especialistas no assunto (PMEs) colaborem com programadores altamente qualificados para software que é útil e tecnicamente sólido.

Veja também [ editar ]

Referências [ editar ]

  1. ^ Ralph, P. e Wand, Y. (2009). Uma proposta de definição formal do conceito de design. Em Lyytinen, K., Loucopoulos, P., Mylopoulos, J. , e Robinson, W., editores, Design Requirements Workshop (LNBIP 14), pp. 103-136. Springer-Verlag, p. 109 doi : 10.1007 / 978-3-540-92966-6_6 .
  2. ^ Freeman, Peter; David Hart (2004). "Uma ciência de design para sistemas intensivos de software". Comunicações da ACM . 47 (8): 19–21 [20]. doi : 10.1145 / 1012037.10120547 . S2CID  14331332 .
  3. ^ Davis, A: "201 Principles of Software Development", McGraw Hill, 1995.
  4. ^ Booch, Grady; et al. (2004). Análise Orientada a Objetos e Projeto com Aplicações (3ª ed.). MA, EUA: Addison Wesley. ISBN 0-201-89551-X. Retirado em 30 de janeiro de 2015 .
  5. ^ Suryanarayana, Girish (novembro de 2014). Refatoração para cheiros de design de software . Morgan Kaufmann. p. 258. ISBN 978-0128013977.
  6. ^ Carroll, John, ed. (1995). Projeto baseado em cenário: prevendo o trabalho e a tecnologia no desenvolvimento de sistemas . Nova York: John Wiley & Sons. ISBN 0471076597.
  7. ^ Bell, Michael (2008). "Introdução à Modelagem Orientada a Serviços". Modelagem Orientada a Serviços: Análise, Design e Arquitetura de Serviços . Wiley & Sons. ISBN 978-0-470-14111-3.
  8. ^ Judith Bishop. "Padrões de projeto do C # 3.0: use o poder do C # 3.0 para resolver problemas do mundo real" . Livros C # da O'Reilly Media . Página visitada em 2012-05-15 . Se você deseja acelerar o desenvolvimento de seus aplicativos .NET, está pronto para os padrões de projeto C # - maneiras elegantes, aceitas e comprovadas de resolver problemas comuns de programação.
  9. ^ Dijkstra, EW (1988). “Sobre a crueldade de realmente ensinar ciência da computação” . Recuperado em 10/01/2014 .
  10. ^ Knuth, Donald E. (1989). "Notas sobre os erros do TeX" (PDF) .
  11. ^ Ralph, P., e Wand, Y. Uma proposta para uma definição formal do conceito de projeto. Em, Lyytinen, K., Loucopoulos, P., Mylopoulos, J., e Robinson, W., (eds.), Design Requirements Engineering: A Ten-Year Perspective: Springer-Verlag, 2009, pp. 103-136

^ Roger S. Pressman (2001). Engenharia de software: a abordagem de um profissional . McGraw-Hill. ISBN 0-07-365578-3.