Machine Translated by Google
CAPÍTULO 2
DESIGN DE SOFTWARE
ACRÔNIMOS
Descrição da Arquitetura
AVD
Linguagem
Projeto Baseado em Componentes CBD
CRC Colaborador de Responsabilidade de Classe
Diagrama de fluxo de dados DFD
Diagrama de Relacionamento de Entidade ERD
IDL Linguagem de descrição da interface
Controlador de exibição de modelo MVC
OO Orientado a Objeto
PDL Linguagem de design do programa
INTRODUÇÃO
Design é definido como “o processo de definir a arquitetura,
componentes, interfaces e outras características de um sistema
ou componente” e “o resultado desse processo” [1]. Visto como
um processo, o projeto de software é a atividade do ciclo de
vida da engenharia de software na qual os requisitos de
software são analisados para produzir uma descrição da
estrutura interna do software que servirá de base para sua
construção. Um projeto de software (o resultado) descreve a
arquitetura de software – isto é, como o software é decomposto
e organizado em componentes – e as interfaces entre esses
componentes. Deve também descrever os componentes com
um nível de detalhe que permita a sua construção.
O design de software desempenha um papel importante no
desenvolvimento de software: durante o design de software,
os engenheiros de software produzem vários modelos que
formam uma espécie de blueprint da solução a ser
implementada. Podemos analisar e avaliar esses modelos
para determinar se eles nos permitirão ou não cumprir os
vários requisitos.
2-1
Também podemos examinar e avaliar soluções alternativas e
compensações. Finalmente, podemos usar os modelos
resultantes para planejar atividades de desenvolvimento
subsequentes, como verificação e validação do sistema, além
de usá-los como entradas e como ponto de partida para
construção e teste.
Em uma lista padrão de processos de ciclo de vida de
software, como a ISO/IEC/IEEE Std. 12207, Processos de
Ciclo de Vida de Software [2], o projeto de software consiste
em duas atividades que se encaixam entre a análise de
requisitos de software e a construção de software:
• Projeto de arquitetura de software (às vezes chamado de
projeto de alto nível): desenvolve a estrutura e a
organização de nível superior do software e identifica os
vários componentes.
• Projeto detalhado de software: especifica cada componente
com detalhes suficientes para facilitar sua construção.
Esta área de conhecimento de Design de Software (KA)
não discute todos os tópicos que incluem a palavra “design”.
Na terminologia de Tom DeMarco [3], os tópicos discutidos
neste KA tratam principalmente de D-design (decomposition
design), cujo objetivo é mapear software em partes
componentes. No entanto, devido à sua importância no campo
da arquitetura de software, também abordaremos o FP-design
(family pattern design), cujo objetivo é estabelecer semelhanças
exploráveis em uma família de produtos de software. Este KA
não aborda o I-design (design de invenção), que geralmente é
realizado durante o processo de requisitos de software com o
objetivo de conceituar e especificar o software para satisfazer
as necessidades e requisitos descobertos, uma vez que este
tópico é considerado parte dos requisitos processo (consulte
os Requisitos de Software KA).
Esta KA de Design de Software está relacionada
especificamente aos Requisitos de Software, Software
Machine Translated by Google
2-2 Guia SWEBOK® V3.0
Figura 2.1. Detalhamento de tópicos para o KA de Design de Software
Construção, Gerenciamento de Engenharia de Software,
Modelos e Métodos de Engenharia de Software, Qualidade de
Software e Fundamentos de Computação KAs.
DESCRIÇÃO DOS TÓPICOS PARA
DESIGN DE SOFTWARE
A divisão dos tópicos para o Software Design KA é mostrada
na Figura 2.1.
1. Fundamentos de Design de Software
Os conceitos, noções e terminologia aqui apresentados
formam uma base subjacente para a compreensão do papel
e do escopo do projeto de software.
1.1. Conceitos Gerais de Design
[4*, c1]
No sentido geral, o design pode ser visto como uma forma de
resolução de problemas. Por exemplo, o conceito de um
problema perverso – um problema sem solução definitiva – é
interessante em termos de
compreender os limites do design. Várias outras noções e
conceitos também são de interesse para entender o design em
seu sentido geral: objetivos, restrições, alternativas,
representações e soluções (consulte Técnicas de resolução de
problemas no Computing Foundations KA).
1.2. Contexto do Design de Software
[4*, c3]
O design de software é uma parte importante do processo de
desenvolvimento de software. Para entender o papel do design
de software, devemos ver como ele se encaixa no ciclo de vida
do desenvolvimento de software. Assim, é importante entender
as principais características da análise de requisitos de
software, projeto de software, construção de software, teste de
software e manutenção de software.
1.3. Processo de Design de Software
[4*, c2]
O projeto de software é geralmente considerado um processo
de duas etapas:
Machine Translated by Google
• Projeto de arquitetura (também conhecido como projeto
de alto nível e projeto de alto nível) descreve como o
software é organizado em componentes.
• O projeto detalhado descreve o comportamento desejado
ior desses componentes.
A saída desses dois processos é um conjunto de modelos e
artefatos que registram as principais decisões tomadas,
juntamente com uma explicação da justificativa para cada
decisão não trivial.
Ao registrar a lógica, a capacidade de manutenção de longo
prazo do produto de software é aprimorada.
1.4. Princípios de Design de Software
[4*] [5*, c6, c7, c21] [6*, c1, c8, c9]
Um princípio é “uma lei, doutrina ou suposição abrangente e
fundamental” [7]. Os princípios de design de software são
noções-chave que fornecem a base para muitas abordagens e
conceitos diferentes de design de software. Os princípios de
design de software incluem abstração; acoplamento e coesão;
decomposição e modularização; encapsulamento/ocultação de
informações; separação de interface e implementação;
suficiência, completude e primitivismo; e separação de
preocupações.
• Abstração é “uma visão de um objeto que se concentra na
informação relevante para um propósito particular e
ignora o restante da informação” [1] (veja Abstração no
Computing Foundations KA). No contexto do projeto de
software, dois mecanismos-chave de abstração são a
parametrização e a especificação. A abstração por
parametrização abstrai os detalhes das representações
de dados representando os dados como parâmetros
nomeados. A abstração por especificação leva a três
tipos principais de abstração: abstração procedural,
abstração de dados e abstração de controle (iteração). •
Acoplamento e Coesão. O acoplamento é definido como
“uma medida da interdependência entre os módulos em
um programa de computador”, enquanto a coesão é
definida como “uma medida da força de associação dos
elementos dentro de um módulo” [1].
• Decomposição e modularização. A decomposição e a
modularização significam que grandes
Projeto de Software 2-3
o software é dividido em vários componentes menores
nomeados com interfaces bem definidas que descrevem
as interações dos componentes. Normalmente, o objetivo
é colocar diferentes funcionalidades e responsabilidades
em diferentes componentes. • Encapsulamento e
ocultação de informações significa agrupar e empacotar
os detalhes internos de uma abstração e tornar esses
detalhes inacessíveis a entidades externas.
• Separação de interface e implementação.
Separar interface e implementação envolve definir um
componente especificando uma interface pública
(conhecida pelos clientes) que é separada dos detalhes
de como o componente é realizado (veja encapsulamento
e ocultação de informações acima). • Suficiência,
completude e primitivismo.
Alcançar suficiência e completude
significa garantir que um componente de software capture
todas as características importantes de uma abstração e
nada mais. Primitividade significa que o design deve ser
baseado em padrões que são fáceis de implementar.
• Separação de interesses. Uma preocupação é uma “área
de interesse em relação a um projeto de software” [8].
Uma preocupação de design é uma área de design que
é relevante para um ou mais de seus stakeholders. Cada
visão de arquitetura enquadra uma ou mais preocupações.
Separar as preocupações por pontos de vista permite
que as partes interessadas se concentrem em algumas
coisas de cada vez e oferece um meio de gerenciar a
complexidade [9].
2. Questões-chave no design de software
Uma série de questões-chave devem ser tratadas ao projetar
software. Algumas são preocupações de qualidade que todo
software deve abordar – por exemplo, desempenho, segurança,
confiabilidade, usabilidade, etc.
Outra questão importante é como decompor, organizar e
empacotar componentes de software.
Isso é tão fundamental que todas as abordagens de design
abordam isso de uma forma ou de outra (consulte a seção 1.4,
Princípios de design de software e o tópico 7, Estratégias e
métodos de design de software). Em contraste, outras questões
“tratam de algum aspecto do comportamento do software que
não está no domínio da aplicação, mas que aborda alguns dos
Machine Translated by Google
2-4 Guia SWEBOK® V3.0
domínios” [10]. Tais questões, que muitas vezes atravessam
a funcionalidade do sistema, têm sido chamadas de aspectos,
que “tendem a não ser unidades de decomposição funcional
do software, mas propriedades que afetam o desempenho ou
a semântica dos componentes de maneira sistêmica” [ 11].
Várias dessas questões-chave e transversais são discutidas
nas seções a seguir (apresentadas em ordem alfabética).
2.1. Simultaneidade
[5*, c18]
O design para simultaneidade está preocupado em decompor
o software em processos, tarefas e threads e lidar com
questões relacionadas de eficiência, atomicidade, sincronização O design para segurança está preocupado em como evitar
e agendamento.
2.2. Controle e Tratamento de Eventos
[5*, c21]
Esse problema de design está relacionado a como organizar
dados e fluxo de controle, bem como lidar com eventos
reativos e temporais por meio de vários mecanismos, como
invocação implícita e retornos de chamada.
2.3. Persistência de dados
[12*, c9]
Esse problema de design está relacionado a como lidar com
dados de longa duração.
2.4. Distribuição de Componentes
[5*, c18]
Essa questão de design está relacionada a como distribuir o
software pelo hardware (incluindo hardware de computador
e hardware de rede), como os componentes se comunicam e
como o middleware pode ser usado para lidar com software
heterogêneo.
2.5. Tratamento de Erros e Exceções e Falhas
Tolerância
[5*, c18]
Esta questão de projeto está relacionada a como prevenir,
tolerar e processar erros e lidar com condições excepcionais.
2.6. Interação e Apresentação
[5*, c16]
Esta questão de design está preocupada com como estruturar
e organizar interações com usuários, bem como a apresentação
de informações (por exemplo, separação de apresentação e
lógica de negócios usando a abordagem Model-View-
Controller).
Observe que este tópico não especifica os detalhes da interface
do usuário, que é a tarefa do design da interface do usuário
(consulte o tópico 4, Design da interface do usuário).
2.7. Segurança
[5*, c12, c18] [13*, c4]
divulgação não autorizada, criação, alteração, exclusão ou
negação de acesso a informações e outros recursos. Também
se preocupa em como tolerar ataques ou violações
relacionados à segurança, limitando danos, serviço contínuo,
acelerando o reparo e a recuperação e falhando e recuperando
com segurança. O controle de acesso é um conceito
fundamental de segurança, devendo também garantir o uso
adequado da criptologia.
3. Estrutura e Arquitetura de Software
Em seu sentido estrito, uma arquitetura de software é “o
conjunto de estruturas necessárias para raciocinar sobre o
sistema, que compreende elementos de software, relações
entre eles e propriedades de ambos”
[14*]. Em meados da década de 1990, no entanto, a
arquitetura de software começou a emergir como uma
disciplina mais ampla que envolvia o estudo de estruturas e
arquiteturas de software de maneira mais genérica. Isso deu
origem a vários conceitos interessantes sobre design de
software em diferentes níveis de abstração. Alguns desses
conceitos podem ser úteis durante o projeto arquitetônico (por
exemplo, estilos arquitetônicos), bem como durante o projeto
detalhado (por exemplo, padrões de projeto). Esses conceitos
de design também podem ser usados para projetar famílias
de programas (também conhecidas como linhas de produtos).
Curiosamente, a maioria desses conceitos pode ser vista
como tentativas de descrever e, assim, reutilizar o
conhecimento de design.
Machine Translated by Google
3.1. Estruturas arquitetônicas e pontos de vista
[14*, c1]
Diferentes facetas de alto nível de um projeto de software podem
ser descritas e documentadas. Essas facetas são frequentemente
chamadas de visualizações: “Uma visualização representa um
aspecto parcial de uma arquitetura de software que mostra
propriedades específicas de um sistema de software” [14*]. As
visões pertencem a questões distintas associadas ao design de
software - por exemplo, a visão lógica (satisfação dos requisitos
funcionais) versus a visão do processo (problemas de
simultaneidade) versus a visão física (problemas de distribuição)
versus a visão de desenvolvimento (como o projeto é dividido
em unidades de implementação com representação explícita
das dependências entre as unidades). Vários autores usam
terminologias diferentes, como visões comportamentais vs.
funcionais vs. estruturais vs. modelagem de dados. Em resumo,
um projeto de software é um artefato multifacetado produzido
pelo processo de projeto e geralmente composto por visões
relativamente independentes e ortogonais.
3.2. Estilos arquitetônicos
[14*, c1, c2, c3, c4, c5]
Um estilo arquitetônico é “uma especialização de tipos de
elementos e relações, juntamente com um conjunto de restrições
sobre como eles podem ser usados” [14*]. Um estilo de
arquitetura pode ser visto como fornecendo a organização de
alto nível do software. Vários autores identificaram uma série de
estilos arquitetônicos principais:
• Estruturas gerais (por exemplo, camadas, tubos
e filtros, quadro-negro)
• Sistemas distribuídos (por exemplo, servidor cliente, três
camadas, corretor)
• Sistemas interativos (por exemplo, Model-View
Controlador, Apresentação-Abstração-Controle)
• Sistemas adaptáveis (por exemplo, microker nel, reflexão)
• Outros (por exemplo, lote, intérpretes, profissionais
controle de acesso, baseado em regras).
3.3. Padrões de design
[15*, c3, c4, c5]
Descrita sucintamente, um padrão é “uma solução comum para
um problema comum em um determinado contexto”
[16]. Embora os estilos arquitetônicos possam ser vistos como
Projeto de Software 2-5
padrões que descrevem a organização de alto nível do software,
outros padrões de projeto podem ser usados para descrever
detalhes em um nível inferior. Esses padrões de design de nível
inferior incluem o seguinte:
• Padrões de criação (por exemplo, construtor, fábrica,
protótipo, singleton)
• Padrões estruturais (por exemplo, adaptador, ponte,
composto, decorador, fachada, peso de mosca, proxy)
• Padrões comportamentais (por exemplo, comando,
intérprete, iterador, mediador, memento, observador,
estado, estratégia, modelo, visitante).
3.4. Decisões de Design de Arquitetura
[5*, c6]
O projeto arquitetônico é um processo criativo. Durante o
processo de projeto, os projetistas de software precisam tomar
uma série de decisões fundamentais que afetam profundamente
o software e o processo de desenvolvimento. É útil pensar no
processo de projeto arquitetônico a partir de uma perspectiva de
tomada de decisão e não de uma perspectiva de atividade.
Muitas vezes, o impacto nos atributos de qualidade e as
compensações entre os atributos de qualidade concorrentes são
a base para as decisões de projeto.
3.5. Famílias de Programas e Estruturas
[5*, c6, c7, c16]
Uma abordagem para fornecer a reutilização de projetos e
componentes de software é projetar famílias de programas,
também conhecidas como linhas de produtos de software.
Isso pode ser feito identificando as semelhanças entre os
membros dessas famílias e projetando componentes reutilizáveis
e personalizáveis para levar em conta a variabilidade entre os
membros da família.
Na programação orientada a objetos (OO), uma noção chave
relacionada é a de um framework: um sistema de software
parcialmente completo que pode ser estendido instanciando
apropriadamente extensões específicas (como plug-ins).
4. Design da Interface do Usuário
O design da interface do usuário é uma parte essencial do
processo de design de software. O design da interface do
usuário deve garantir que a interação entre o humano e a
máquina proporcione uma operação eficaz
Machine Translated by Google
2-6 Guia SWEBOK® V3.0
e controle da máquina. Para que o software atinja todo o
seu potencial, a interface do usuário deve ser projetada
para corresponder às habilidades, experiência e expectativas
de seus usuários previstos.
4.1. Princípios gerais de design da interface do usuário
[5*, c29-web] [17*, c2]1
• Aprendizagem. O software deve ser fácil de aprender
para que o usuário possa começar a trabalhar
rapidamente com o software.
• Familiaridade do usuário. A interface deve usar termos
e conceitos extraídos das experiências das pessoas
que usarão o software.
• Consistência. A interface deve ser consistente para
que operações comparáveis sejam ativadas da
mesma maneira.
• Surpresa mínima. O comportamento do software
não deve surpreender os usuários.
• Recuperabilidade. A interface deve fornecer mecanismos
que permitam aos usuários recuperar
erros.
• Orientação do usuário. A interface deve fornecer
feedback significativo quando ocorrerem erros e
fornecer ajuda relacionada ao contexto aos usuários.
• Diversidade de usuários. A interface deve fornecer
mecanismos de interação apropriados para diversos
tipos de usuários e para usuários com diferentes
capacidades (cegos, deficientes visuais, surdos,
daltônicos, etc.).
4.2. Problemas de design da interface do usuário
[5*, c29-web] [17*, c2]
O design da interface do usuário deve resolver dois problemas principais:
• Como o usuário deve interagir com o software?
• Como as informações do software devem
ser apresentado ao usuário?
O design da interface do usuário deve integrar a interação
do usuário e a apresentação de informações. O design da
interface do usuário deve considerar um compromisso entre
os estilos de interação mais apropriados
1 Capítulo 29 é um capítulo baseado na web
disponível em http://ifs.host.cs.st-andrews.ac.uk/Books/SE9/
WebChapters/.
e apresentação do software, o histórico e a experiência dos
usuários do software e os dispositivos disponíveis.
4.3. O Design de Modalidades de Interação do Usuário
[5*, c29-web] [17*, c2]
A interação do usuário envolve a emissão de comandos e
o fornecimento de dados associados ao software. Os estilos
de interação do usuário podem ser classificados nos
seguintes estilos primários:
• Pergunta-resposta. A interação é essencialmente
restrita a uma única troca de perguntas e respostas
entre o usuário e o software.
O usuário emite uma pergunta para o software e o
software retorna a resposta para a pergunta. •
Manipulação direta. Os usuários interagem com
objetos na tela do computador. A manipulação direta
geralmente inclui um dispositivo apontador (como um
mouse, trackball ou um dedo em telas sensíveis ao
toque) que manipula um objeto e invoca ações que
especificam o que deve ser feito com esse objeto.
• Seleção de menus. O usuário seleciona um comando
a partir de uma lista de comandos do menu.
• Preenchimento de formulário. O usuário preenche os
campos de um formulário. Às vezes, os campos
incluem menus, nesse caso o formulário possui botões
de ação para o usuário iniciar a ação.
• Linguagem de comando. O usuário emite um comando
e fornece parâmetros relacionados para orientar o
software sobre o que fazer.
• Linguagem natural. O usuário emite um comando em
linguagem natural. Ou seja, a linguagem natural é um
front-end para uma linguagem de comando e é
analisada e traduzida em comandos de software.
4.4. O Design da Apresentação da Informação
[5*, c29-web] [17*, c2]
A apresentação da informação pode ser de natureza
textual ou gráfica. Um bom design mantém a apresentação
da informação separada da própria informação.
A abordagem MVC (Model-View-Controller) é uma maneira
eficaz de manter a apresentação da informação separada
da informação que está sendo apresentada.
Machine Translated by Google
Os engenheiros de software também consideram o tempo de
resposta do software e o feedback no design da apresentação das
informações. O tempo de resposta geralmente é medido a partir do
ponto em que um usuário executa uma determinada ação de controle
até que o software responda com uma resposta. Uma indicação de
progresso é desejável enquanto o software está preparando a
resposta.
O feedback pode ser fornecido reafirmando a entrada do usuário
enquanto o processamento está sendo concluído.
Visualizações abstratas podem ser usadas quando grandes
quantidades de informações devem ser apresentadas.
De acordo com o estilo de apresentação das informações, os
designers também podem usar cores para aprimorar a interface.
Existem várias orientações importantes:
• Limite o número de cores usadas.
• Use a mudança de cor para mostrar a mudança de
estado dos utensílios.
• Use codificação de cores para dar suporte à tarefa do usuário.
• Use a codificação por cores de forma ponderada e consistente.
• Use cores para facilitar o acesso de pessoas com daltonismo
ou deficiência de cor (por exemplo, use a mudança de
saturação de cor e brilho de cor, tente evitar combinações de
azul e vermelho).
• Não dependa apenas da cor para transmitir informações
importantes a usuários com diferentes capacidades (cegueira,
deficiência visual, daltonismo, etc.).
4.5. Processo de design da interface do usuário
[5*, c29-web] [17*, c2]
O design da interface do usuário é um processo iterativo; protótipos
de interface são frequentemente usados para determinar os recursos,
organização e aparência da interface do usuário do software. Este
processo inclui três atividades principais:
• Análise do usuário. Nesta fase, o designer analisa as tarefas
dos usuários, o ambiente de trabalho, outros softwares e
como os usuários interagem com outras pessoas. •
Prototipagem de software. O desenvolvimento de software
protótipo ajuda os usuários a orientar a evolução da interface.
• Avaliação de interfaces. Os designers podem observar as
experiências dos usuários com a interface em evolução.
Projeto de Software 2-7
4.6. Localização e Internacionalização
[17*, c8, c9]
O design da interface do usuário geralmente precisa considerar a
internacionalização e a localização, que são meios de adaptar o
software aos diferentes idiomas, diferenças regionais e requisitos
técnicos de um mercado-alvo. A internacionalização é o processo de
projetar um aplicativo de software para que possa ser adaptado a
vários idiomas e regiões sem grandes alterações de engenharia.
Localização é o processo de adaptação de software internacionalizado
para uma região ou idioma específico, adicionando componentes
específicos de localidade e traduzindo o texto. A localização e a
internacionalização devem considerar fatores como símbolos,
números, moeda, hora e unidades de medida.
4.7. Metáforas e Modelos Conceituais
[17*, c5]
Os designers de interface do usuário podem usar metáforas e
modelos conceituais para estabelecer mapeamentos entre o software
e algum sistema de referência conhecido pelos usuários no mundo
real, o que pode ajudar os usuários a aprender e usar a interface
com mais facilidade. Por exemplo, a operação “excluir arquivo” pode
ser transformada em metáfora usando o ícone de uma lixeira.
Ao projetar uma interface de usuário, os engenheiros de software
devem ter cuidado para não usar mais de uma metáfora para cada
conceito. As metáforas também apresentam problemas potenciais
com respeito à internacionalização, uma vez que nem todas as
metáforas são significativas ou são aplicadas da mesma forma em
todas as culturas.
5. Análise e Avaliação da Qualidade do Projeto de
Software
Esta seção inclui vários tópicos de análise e avaliação de qualidade
especificamente relacionados ao design de software. (Veja também
o Software Quality KA.)
5.1. Atributos de qualidade
[4*, c4]
Vários atributos contribuem para a qualidade de um projeto de
software, incluindo várias “-ilities” (manutenção, portabilidade,
testabilidade, usabilidade)
Machine Translated by Google
2-8 Guia SWEBOK® V3.0
e “-nesses” (correção, robustez). Há uma distinção
interessante entre atributos de qualidade discerníveis em
tempo de execução (por exemplo, desempenho,
segurança, disponibilidade, funcionalidade, usabilidade),
aqueles não discerníveis em tempo de execução (por
exemplo, modificabilidade, portabilidade, reusabilidade,
testabilidade) e aqueles relacionados a as qualidades
intrínsecas da arquitetura (por exemplo, integridade
conceitual, correção, completude). (Veja também o
Software Quality KA.)
5.2. Técnicas de Análise e Avaliação da Qualidade
[4*, c4] [5*, c24]
Várias ferramentas e técnicas podem ajudar na análise
e avaliação da qualidade do projeto de software.
• Revisões de design de software: técnicas informais
e formalizadas para determinar a qualidade de
artefatos de design (por exemplo, revisões de
arquitetura, revisões de design e inspeções; técnicas
baseadas em cenários; rastreamento de requisitos).
As revisões de design de software também podem
avaliar a segurança. Auxílios para instalação,
operação e uso (por exemplo, manuais e arquivos
de ajuda) podem ser revisados.
• Análise estática: análise estática formal ou semiformal
(não executável) que pode ser usada para avaliar
um projeto (por exemplo, análise de árvore de falhas
ou verificação cruzada automatizada).
A análise de vulnerabilidades de design (por
exemplo, análise estática para pontos fracos de
segurança) pode ser realizada se a segurança for
uma preocupação. A análise formal de projeto usa
modelos matemáticos que permitem aos projetistas
prever o comportamento e validar o desempenho do
software em vez de depender inteiramente de testes.
A análise formal de projeto pode ser usada para
detectar erros residuais de especificação e projeto
(talvez causados por imprecisão, ambiguidade e, às
vezes, outros tipos de erros). (Consulte também os
Modelos e Métodos de Engenharia de Software KA.)
• Simulação e prototipagem: técnicas dinâmicas para
avaliar um projeto (por exemplo, simulação de
desempenho ou protótipos de viabilidade).
5.3. Medidas
[4*, c4] [5*, c24]
As medidas podem ser usadas para avaliar ou estimar
quantitativamente vários aspectos de um projeto de
software; por exemplo, tamanho, estrutura ou qualidade.
A maioria das medidas propostas depende da abordagem
utilizada para a produção do projeto.
Essas medidas são classificadas em duas grandes
categorias:
• Medidas de projeto baseadas em funções
(estruturadas): medidas obtidas pela análise da
decomposição funcional; geralmente representado
usando um gráfico de estrutura (às vezes chamado
de diagrama hierárquico) no qual várias medidas
podem ser calculadas.
• Medidas de projeto orientadas a objetos: a estrutura
de projeto é normalmente representada como um
diagrama de classes, no qual várias medidas podem
ser calculadas. Medidas sobre as propriedades do
conteúdo interno de cada classe também podem ser
calculadas.
6. Notações de Design de Software
Existem muitas notações para representar artefatos de
design de software. Alguns são usados para descrever a
organização estrutural de um projeto, outros para
representar o comportamento do software. Certas
notações são usadas principalmente durante o projeto
arquitetônico e outras principalmente durante o projeto
detalhado, embora algumas notações possam ser usadas
para ambos os propósitos. Além disso, algumas notações
são usadas principalmente no contexto de métodos de
projeto específicos (consulte o tópico 7, Estratégias e
métodos de projeto de software). Observe que o design
de software geralmente é realizado usando várias
notações. Aqui, eles são categorizados em notações para
descrever a visão estrutural (estática) versus a visão comportamental (dinâm
6.1. Descrições Estruturais (Vista Estática)
[4*, c7] [5*, c6, c7] [6*, c4, c5, c6, c7] [12*,
c7] [14*, c7]
As seguintes notações, em sua maioria, mas nem sempre
gráficas, descrevem e representam os aspectos estruturais
de um projeto de software - ou seja, são
Machine Translated by Google
usado para descrever os principais componentes e como eles
estão interconectados (visão estática):
• Linguagens de descrição de arquitetura (ADLs): linguagens
textuais, muitas vezes formais, usadas para descrever a
arquitetura de software em termos de componentes e
conectores.
• Diagramas de classes e objetos: usados para representar
um conjunto de classes (e objetos) e suas inter-relações.
• Diagramas de componentes: usados para representar um
conjunto de componentes (“partes físicas e substituíveis
de um sistema que [se conformam] e [fornecem] a
realização de um conjunto de interfaces” [18]) e suas inter-
relações.
• Cartões de colaborador de responsabilidade de classe
(CRCs): usados para denotar os nomes dos componentes
(classe), suas responsabilidades e os nomes dos
componentes colaboradores.
• Diagramas de implantação: usados para representar um
conjunto de nós (físicos) e suas inter-relações e, assim,
modelar os aspectos físicos do software.
• Diagramas entidade-relacionamento (ERDs): utilizados
para representar modelos conceituais de dados
armazenados em repositórios de informações.
• Linguagens de descrição de interface (IDLs): linguagens
do tipo programação usadas para definir as interfaces
(nomes e tipos de operações exportadas) de componentes
de software.
• Gráficos de estrutura: usados para descrever a estrutura
de chamada dos programas (quais módulos chamam e
são chamados por quais outros módulos).
6.2. Descrições Comportamentais (Visão Dinâmica)
[4*, c7, c13] [5*, c6, c7] [6*, c4, c5, c6, c7] [14*, c8]
As seguintes notações e linguagens, algumas gráficas e outras
textuais, são usadas para descrever o comportamento dinâmico
de sistemas e componentes de software. Muitas dessas
notações são úteis principalmente, mas não exclusivamente,
durante o projeto detalhado. Além disso, as descrições
comportamentais podem incluir uma justificativa para a decisão
de design, como como um design atenderá aos requisitos de
segurança.
Projeto de Software 2-9
• Diagramas de atividades: usados para mostrar o fluxo de
controle de atividade para atividade. Pode ser usado para
representar atividades simultâneas.
• Diagramas de comunicação: usados para mostrar as
interações que ocorrem entre um grupo de objetos; a
ênfase está nos objetos, seus links e nas mensagens que
eles trocam nesses links.
• Diagramas de fluxo de dados (DFDs): usados para mostrar
o fluxo de dados entre os elementos. Um diagrama de
fluxo de dados fornece “uma descrição baseada na
modelagem do fluxo de informações em torno de uma
rede de elementos operacionais, com cada elemento
fazendo uso ou modificando a informação que flui para
aquele elemento” [4*]. Os fluxos de dados (e, portanto, os
diagramas de fluxo de dados) podem ser usados para
análise de segurança, pois oferecem a identificação de
possíveis caminhos para ataques e divulgação de
informações confidenciais.
• Tabelas e diagramas de decisão: usados para representar
combinações complexas de condições e ações.
• Fluxogramas: utilizados para representar o fluxo de controle
e as ações associadas a serem realizadas.
• Diagramas de sequência: usados para mostrar as
interações entre um grupo de objetos, com ênfase na
ordenação temporal das mensagens passadas entre os
objetos.
• Diagramas de transição de estado e gráfico de estado:
usados para mostrar o fluxo de controle de estado para
estado e como o comportamento de um componente
muda com base em seu estado atual em uma máquina
de estado.
• Linguagens de especificação formal: linguagens textuais
que usam noções básicas da matemática matemática
(por exemplo, lógica, conjunto, sequência) para definir de
forma rigorosa e abstrata as interfaces e o comportamento
dos componentes de software, geralmente em termos de
pré e pós-condições. (Consulte também os Modelos e
Métodos de Engenharia de Software KA.)
• Pseudocódigo e linguagens de projeto de programa (PDLs):
linguagens estruturadas do tipo programação usadas
para descrever, geralmente na fase de projeto detalhado,
o comportamento de um procedimento ou método.
Machine Translated by Google
2-10 Guia SWEBOK® V3.0
7. Estratégias e Métodos de Design de Software
Existem várias estratégias gerais para ajudar a orientar o
processo de design. Em contraste com as estratégias gerais,
os métodos são mais específicos, pois geralmente fornecem
um conjunto de notações a serem usadas com o método,
uma descrição do processo a ser usado ao seguir o método
e um conjunto de diretrizes para usar o método. Esses
métodos são úteis como uma estrutura comum para equipes
de engenheiros de software. (Consulte também os Modelos
e Métodos de Engenharia de Software KA).
7.1. Estratégias Gerais
[4*, c8, c9, c10] [12*, c7]
Alguns exemplos frequentemente citados de estratégias
gerais úteis no processo de design incluem as estratégias
de divisão e conquista e refinamento passo a passo,
estratégias de cima para baixo vs. de baixo para cima e
estratégias que fazem uso de heurísticas, uso de padrões e
linguagens de padrões e uso de uma abordagem iterativa e
incremental.
7.2. Design Orientado à Função (Estruturado)
[4*, c13]
Este é um dos métodos clássicos de projeto de software,
onde a decomposição se concentra na identificação das
principais funções do software e, em seguida, elaborá-las e
refiná-las de forma hierárquica de cima para baixo. O design
estruturado geralmente é usado após a análise estruturada,
produzindo assim (entre outras coisas) diagramas de fluxo
de dados e descrições de processos associados. Os
pesquisadores propuseram várias estratégias (por exemplo,
análise de transformação, análise de transação) e heurísticas
(por exemplo, fan-in/fan-out, escopo de efeito vs. escopo de
controle) para transformar um DFD em uma arquitetura de
software geralmente representada como um gráfico de
estrutura.
7.3. Design Orientado a Objetos
[4*, c16]
Vários métodos de projeto de software baseados em objetos
têm sido propostos. O campo evoluiu desde o início da
orientação a objetos (OO)
design de meados da década de 1980 (substantivo = objeto;
verbo = método; adjetivo = atributo), onde herança e
polimorfismo desempenham um papel fundamental, para o
campo do design baseado em componentes, onde a
formação de metain pode ser definida e acessada (através
da reflexão , por exemplo). Embora as raízes do design OO
tenham origem no conceito de abstração de dados, o design
orientado por responsabilidade foi proposto como uma
abordagem alternativa ao design OO.
7.4. Design centrado na estrutura de dados
[4*, c14, c15]
O design centrado na estrutura de dados começa a partir
das estruturas de dados que um programa manipula, e não
da função que ele executa. O engenheiro de software
primeiro descreve as estruturas de dados de entrada e saída
e, em seguida, desenvolve a estrutura de controle do
programa com base nesses diagramas de estrutura de
dados. Várias heurísticas foram propostas para lidar com
casos especiais - por exemplo, quando há uma
incompatibilidade entre as estruturas de entrada e saída.
7.5. Projeto Baseado em Componentes (CBD)
[4*, c17]
Um componente de software é uma unidade independente,
com interfaces e dependências bem definidas que podem
ser compostas e implantadas independentemente. O design
baseado em componentes aborda questões relacionadas ao
fornecimento, desenvolvimento e integração de tais
componentes para melhorar a reutilização. Os componentes
de software reutilizados e prontos para uso devem atender
aos mesmos requisitos de segurança que o novo software.
O gerenciamento de confiança é uma preocupação de
design; componentes tratados como tendo um certo grau de
confiabilidade não devem depender de componentes ou
serviços menos confiáveis.
7.6. Outros métodos
[5*, c19, c21]
Outras abordagens interessantes também existem (veja a
KA Modelos e Métodos de Engenharia de Software).
Métodos iterativos e adaptativos implementam incrementos
de software e reduzem a ênfase em requisitos e projetos de
software rigorosos.
Machine Translated by Google
O projeto orientado a aspectos é um método pelo qual o
software é construído usando aspectos para implementar as
preocupações e extensões transversais que são identificadas
durante o processo de requisitos de software. A arquitetura
orientada a serviços é uma maneira de construir software
distribuído usando serviços da Web executados em
computadores distribuídos. Os sistemas de software
geralmente são construídos usando serviços de diferentes
provedores porque protocolos padrão (como HTTP, HTTPS,
SOAP) foram projetados para oferecer suporte à comunicação
de serviço e troca de informações de serviço.
Projeto de Software 2-11
8. Ferramentas de Design de Software
[14*, c10, Apêndice A]
As ferramentas de design de software podem ser usadas
para dar suporte à criação dos artefatos de design de software
durante o processo de desenvolvimento de software. Eles
podem apoiar parte ou a totalidade das seguintes atividades:
• traduzir o modelo de requisitos em uma representação
de projeto; • fornecer suporte para a representação de
componentes funcionais e sua(s) interface(s); • implementar
refinamento e particionamento de heurísticas; • fornecer
diretrizes para avaliação de qualidade.
Machine Translated by Google

2-12 Guia SWEBOK® V3.0

MATRIZ DE TÓPICOS VS. MATERIAL DE REFERÊNCIA

[4*] [5*] [6*] [12*] [13*] [14*] [15*] [17*]

Allen
2008

Nielsen
1993
Orçamento
2003

Jones
Page
1999
Brookshear
2008
Sommerville
2011

Gama
1994
ai.
et
Clementes
2010
ai.
et

1. Fundamentos de
Design de Software

1.1. Conceitos Gerais

c1
de Design
1.2. O Contexto do
c3
Design de Software
1.3. O Processo de
c2
Design de Software

1.4. Princípios de design c6, c7, c1, c8,

c1
de software 2. Questões- c21 c9

chave no design de
software

2.1. Simultaneidade c18

2.2. Controle e
c21
Tratamento de Eventos
2.3. Persistência de dados c9

2.4. Distribuição de
c18
Componentes
2.5. Tratamento
de Erros e Exceções e c18
Tolerância a Falhas

2.6. Interação e
c16
Apresentação

c12,
2.7. Segurança c4
c18

3. Estrutura e Arquitetura
de Software

3.1. Estruturas
arquitetônicas e c1
pontos de vista

c1, c2,
3.2. Estilos
c3, c4,
arquitetônicos
c5

c3, c4,
3.3. Padrões de design
c5
Machine Translated by Google

Projeto de Software 2-13

[4*] [5*] [6*] [12*] [13*] [14*] [15*] [17*]

Allen
2008

Nielsen
1993
Orçamento
2003

Jones
Page
1999
Brookshear
2008
Sommerville
2011

Gama
1994
ai.
et
Clementes
2010
ai.
et

3.4. Decisões de
c6
Design de Arquitetura
3.5. Famílias de
c6, c7,
Programas e
c16
Estruturas

4. Interface do usuário

Projeto
4.1. Princípio geral
c29-
de design da interface c2
rede
do usuário
4.2. Problemas de design c29-

da interface do usuário rede

4.3. O Design de
c29-
Modalidades de
rede
Interação do Usuário

4.4. O Design da
c29-
Apresentação da
rede
Informação

4.5. Processo de design c29-

da interface do usuário rede

4.6. Localização e
c8, c9
Internacionalização

4.7. Metáforas e
c5
Modelos Conceituais

5. Análise e Avaliação
da Qualidade do Projeto
de Software

5.1. Atributos
c4
de qualidade

5.2. Técnicas
de Análise e
c4 c24
Avaliação da

Qualidade
5.3. Medidas c4 c24
Machine Translated by Google

2-14 Guia SWEBOK® V3.0

[4*] [5*] [6*] [12*] [13*] [14*] [15*] [17*]

Allen
2008

Nielsen
1993
Orçamento
2003

Jones
Page
1999
Brookshear
2008
Sommerville
2011

Gama
1994
ai.
et
Clementes
2010
ai.
et

6. Notações de Design
de Software

6.1. Descrições
c4, c5,
Estruturais (Vista Estática) c7 c6, c7 c7 c7
c6, c7

6.2. Descrições
c7, c13, c4, c5,
Comportamentais c6, c7 c8
c18 c6, c7
(Visão Dinâmica)

7. Estratégias e
Métodos de Design de
Software

7.1. Estratégias c8, c9,

c7
Gerais c10

7.2. Design
Orientado à c13

Função (Estruturado)

7.3. Design Orientado a

c16
Objetos
7.4. Design centrado c14,
na estrutura de dados c15

7.5. Design Baseado

c17
em Componentes (CBD)

c19,
7.6. Outros métodos
c21

8. Ferramentas de Design c10,

de Software Ap. UMA
Machine Translated by Google
LEITURAS ADICIONAIS
Roger Pressman, Engenharia de Software: A
Abordagem do Praticante (Sétima Edição)
[19].
Por cerca de três décadas, Roger Pressman's Software
Engineering: A Practitioner's Approach
tem sido um dos principais livros didáticos do mundo em
engenharia de software. Notavelmente, este livro
complementar a [5*] apresenta de forma abrangente o
design de software — incluindo conceitos de design,
design arquitetônico, design em nível de componente,
design de interface do usuário, design baseado em
padrões e design de aplicativos da web.
“O Modelo de Arquitetura 4+1 Vista” [20].
O artigo seminal “The 4+1 View Model” organiza uma
descrição de uma arquitetura de software usando cinco
visualizações simultâneas. As quatro visões do modelo
são a visão lógica, a visão de desenvolvimento, a visão de
processo e a visão física.
Além disso, casos de uso ou cenários selecionados são
utilizados para ilustrar a arquitetura. Portanto, o modelo
contém 4+1 visualizações. As visualizações são usadas
para descrever o software conforme imaginado por
diferentes partes interessadas, como usuários finais,
desenvolvedores e gerentes de projeto.
Len Bass, Paul Clements e Rick Kazman, Arquitetura
de Software na Prática [21].
Este livro apresenta os conceitos e as melhores práticas
de arquitetura de software, ou seja, como o software é
estruturado e como os componentes do software
interagem. Com base em sua própria experiência, os
autores cobrem os tópicos técnicos essenciais para
projetar, especificar e validar arquiteturas de software.
Eles também enfatizam a importância do contexto de
negócios no qual o software de grande porte é projetado.
Seu objetivo é apresentar a arquitetura de software em
um cenário do mundo real, refletindo tanto as oportunidades [11] G. Kiczales et al., “Orientação a Aspectos
quanto as restrições que as organizações encontram. Este
é um dos melhores livros atualmente disponíveis sobre
arquitetura de software.
Projeto de Software 2-15
REFERÊNCIAS
[1] Sistemas ISO/ IEC/ IEEE 24765:2010 e
Engenharia de Software—Vocabulário, ISO/
IEC/IEEE, 2010.
[2] Padrão IEEE 12207-2008 (também conhecido como ISO/ IEC
12207:2008) Norma para Sistemas e
Engenharia de Software—Ciclo de Vida de Software
Processos, IEEE, 2008.
[3] T. DeMarco, “O Paradoxo do Software
Arquitetura e Design”, Palestra do Prêmio
Stevens, 1999.
[4*] D. Budgen, Design de Software, 2ª ed.,
Addison-Wesley, 2003.
[5*] I. Sommerville, Engenharia de Software, 9ª ed.,
Addison-Wesley, 2011.
[6*] M. Page-Jones, Fundamentos do Objeto
Design Orientado em UML, 1ª ed., Addison Wesley,
1999.
[7] Dicionário Collegiate de Merriam-Webster, 11ª ed.,
2003.
[8] Padrão IEEE. 1069-2009 Norma para
Tecnologia da Informação—Sistemas
Design—Descrições de Design de Software,
IEEE, 2009.
[9] Sistemas e Software ISO/ IEC 42010:2011
Engenharia—Prática Recomendada para
Descrição Arquitetural de Sistemas Intensivos
de Software, ISO/IEC, 2011.
[10] J. Bosch, Design e Uso de Software
Arquiteturas: Adotando e evoluindo uma
Abordagem da linha de produtos, ACM Press, 2000.
Programação”, Proc. 11º Congresso Europeu
Programação Orientada a Objetos (ECOOP 97),
Springer, 1997.
Machine Translated by Google
2-16 Guia SWEBOK® V3.0
[12*] JG Brookshear, Ciência da Computação: Um
Visão geral, 10ª ed., Addison-Wesley, 2008.
[13*] JH Allen et al., Software Security
Engenharia: um guia para o projeto
Gerentes, Addison-Wesley, 2008.
[14*] P. Clements et al., Software de Documentação
Architectures: Views and Beyond, 2ª ed., Pearson
Education, 2010.
[15*] E. Gamma et al., Padrões de Projeto:
Elementos de Orientação a Objetos Reutilizáveis
Software, 1ª ed., Addison-Wesley
Professional, 1994.
[16] I. Jacobson, G. Booch e J. Rumbaugh, O
Desenvolvimento Unificado de Software
Processo, Addison-Wesley Professional, 1999.
[17*] J. Nielsen, Engenharia de Usabilidade, Morgan
Kaufmann, 1993.
[18] G. Booch, J. Rumbaugh e I. Jacobson, The Unified
Modeling Language User Guide, Addison-Wesley,
1999.
[19] RS Pressman, Engenharia de Software: A
Abordagem do Praticante, 7ª ed., McGraw Hill, 2010.
[20] PB Kruchten, “The 4+1 View Model of Architecture,”
IEEE Software, vol. 12, não. 6, 1995, pp. 42-55.
[21] L. Bass, P. Clements e R. Kazman,
Arquitetura de software na prática, 3ª ed., Addison-
Wesley Professional, 2013.