Engenharia de
Software
Graduação em Engenharia de
Sistemas e Computação
Faculdade de Engenharia
Universidade do Estado do Rio
de Janeiro
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
1
Engenharia de Software [1]
• Def1.: é a parte da Ciência da
Computação que lida com a construção de
Sistemas de Software que são grandes e
complexos, de modo que são
desenvolvidos por equipes de engenheiros
(analistas e programadores). Estes
Sistemas de Software existem em
múltiplas versões e são usados por vários
anos.
• Def2. [Parnas – 1987]: compreende a
construção de software com múltiplas
versões, envolvendo vários indivíduos.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
2
Engenharia de Software [2]
• A atividade de programação é individual,
enquanto a Engenharia de Software é uma
atividade de equipe.
• Mesmo para especificar o que um sistema
de software deve fazer, não existem
métodos de aceitação generalizada.
• Abordagem: apresentar alguns princípios
gerais que são essenciais para o
desenvolvimento de software.
• Princípios são mais importantes que
metodologias ou notações particulares
usadas para o desenvolvimento de
software.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
3
Engenharia de Software [3]
Siste
ma
Sistema de software
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
4
Engenharia de Software [4]
• A Engenharia de Software requer
uma visão geral da área de
Engenharia de Sistemas;
• É preciso que o engenheiro de
software tenha envolvimento com
os requisitos inicialmente
formulados para o sistema (do qual
o software é parte) como um todo;
• Requer um conhecimento da área de
aplicação;
• Lembrar que em qualquer área da
engenharia deve-se observar
compromissos.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
5
Visão histórica da ES [1]
• Inicialmente implementação de alguns
algoritmos (via seqüência de instruções) bem
definidos (ainda que eventualmente complexos).
• Gradativamente foram surgindo projetos de
software de grandes dimensões (Ex. Sistema
SABRE na década de 60, IBM OS 360, etc.)
• Constatou-se dificuldades na aplicação das
técnicas utilizadas no desenvolvimento de
projetos de pequeno porte em projetos de grande
porte (scalability).
• De uma forma geral, os projetos de grande porte
ultrapassavam os custos e o tempo inicialmente
previstos para a sua conclusão.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
6
Visão histórica da ES [2]
• Profundas alterações no custo de
hardware X custo de software
Custo Total do Sistema (US$)
HW (US$)
SW (US$)
t
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
7
Visão histórica da ES [3]
•
Mudanças nos requisitos iniciais do
sistema pareciam afetar diversas partes
do projeto (efeito cascata).
Diversas soluções foram aventadas:
•
–
–
–
–
•
Aprimorar as técnicas gerenciais;
Novas formas de se organizar equipes;
Melhores linguagens e ferramentas;
Adoção de padrões (ex.: convenções para
codificação dos programas, documentação,
etc.);
Consenso final: A construção de
software deveria ser abordada de forma
similar à de outros sistemas complexos
de grande porte, tais como: pontes,
refinarias, fábricas, navios e aviões.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
8
Visão histórica da ES [3]
•
A abordagem de engenharia no
desenvolvimento de software
requer:
–
–
–
–
–
–
UERJ Setembro 2001
Gerência
Organização
Ferramentas
Teorias
Metodologias
Técnicas
© Oscar Luiz Monteiro de Farias
9
O Engenheiro de
Software
• Precisa dominar:
Programming in the small
Programming in the large
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
10
Conhecimentos do ES [1]
Programming in the small
• Conhecimento de LPs
• Estrutura de Informação
• Algoritmos
• Inteligência
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
11
Conhecimentos do ES [2]
Programming in the large
• Familiar com diversas abordagens de
projetos
• Traduzir requisitos vagos em
especificações precisas
• Ter conhecimento (ou capacidade de
rapidamente adquirir conhecimento) do
domínio de aplicação
• Capacidade de transitar entre os
diferentes níveis de abstração exigido nas
várias fases do projeto
• Técnicas de Modelagem
• Facilidade de Comunicação e de lidar
com pessoas
• Capacidade de planejar o trabalho
(scheduling)
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
12
Ciclo de Vida do SW
• Def.: Conjunto de fases associadas
ao desenvolvimento e manutenção
do software.
• Em cada fase desenvolve-se alguma
parte do sistema ou algo associado
ao sistema (ex.: plano de teste,
manual do usuário, etc.)
• No modelo waterfall cada fase
possui pontos de início e fim e
outputs bem definidos.
• Existem outros modelos de ciclo de
vida
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
13
Ciclo de Vida do SW Modelo Waterfall
Análise de Requisitos
e Especificação
Projeto (arquitetura
e detalhado)
Codificação e
Teste de Módulos
Integração e
Teste do Sistema
Entrega do SW
e Manutenção
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
14
ES x Ciência da
Computação
•
•
•
•
•
Linguagens de Programação
Sistemas Operacionais
Banco de Dados
Inteligência Artificial
Modelos Teóricos
ES x Outras Disciplinas:
• Gerenciamento
• Engenharia de Sistemas
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
15
Engenharia de Software
Princípios de Engenharia
Aplicados a
Diferentes produtos de software
10 passo: Discernir um conjunto de qualidades que caracteriza
20 passo: Descobrir que princípios devem ser aplicados para s
sw com as qualidades desejadas.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
16
Natureza e Qualidades do
SW
• Maleabilidade
(Contudo uma alteração no software
deve ser encarada como uma
mudança que afeta desde o projeto
até o código gerado)
• Atividade mão-de-obra intensiva
(todavia requer mais “engenheiros”
do que pessoal tradicionalmente
dedicado à manufatura)
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
17
Qualidades do SW Perspectivas
Gerente do Projeto
(produtividade e facilidade
de controle)
Software
Usuário
(confiabilidade,
facilidade de uso
eficiência)
Desenvolvedor (verificabilidade, manutenabilidade, portabilidad
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
18
Qualidades Externas x
Internas
• Qualidades externas: são aquelas
visíveis aos usuários.
• Qualidades internas: são as que
dizem respeito aos desenvolvedores
do sistema.
• As qualidades internas lidam, em
grande parte, com a estrutura do
software e ajudam os
desenvolvedores a atingir as
qualidades externas.
• As qualidades internas são
necessarias para se atingir a
confiabilidade (reliability) do sw.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
19
Processo x Produto de
Software
• Processo de Software: o conjunto de
atividades desenvolvidas durante a
produção de sw.
• Gerenciamento de Configuração: é a parte
do processo de produção de sw que é
voltado para a manutenção e controle das
relações entre as várias versões de um
produto de sw aí incluídos os seus
diversos módulos.
• Ferramentas de gerenciamento de
configuração possibilitam a manutenção
de famílias de produtos e seus respectivos
componentes.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
20
Qualidades Principais:
• [1] Def.: Correctness: Um programa é dito
funcionalmente correto se ele se comporta de
acordo com as especificações das funções que
ele deve prover (functional requirements
specifications).
• Conseqüências da definição de correctness:
 Assume que a especificação do sistema está
disponível.
 Que é possível determinar de forma não
ambígua se um programa está conforme ou não
às especificações.
• Correctness é uma propriedade matemática que
estabelece uma equivalência entre o sw e a sua
especificação.
• Correctness
especificação formal e
testes.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
21
Qualidades do Software
[2]
• [2] Def.: Reliability
(Confiabilidade): Informalmente,
um sw é reliable se o usuário pode
depender dele.
• Def.: Reliability: a probabilidade
de que o sw irá operar de acordo
com o esperado dentro de um
intervalo de tempo especificado.
• Espera-se que os produtos de
engenharia sejam confiáveis (sw
ainda não atingiu este estágio – ex.:
Produtos são liberados para o
mercado com lista de bugs).
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
22
Qualidades do Software
[2]...
Reliability
Correctness
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
23
Qualidades do Software
[3]
• [3] Def.: Robustness (Robustez): Um
sistema é dito robusto se ele comporta-se
“razoavelmente”, ainda que em
circunstâncias que não foram
antecipadas na especificação dos
requisitos do sistema.
• Atenção! Se pudéssemos estabelecer
precisamente o que deveríamos fazer para
tornar uma aplicação robusta, seríamos
capazes de especificar o seu
comportamento “razoável”
completamente. Neste caso robustness
seria equivalente a correctness ou ainda a
reliability (no sentido do slide anterior).
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
24
Qualidades do Software
[4]
• [4] Def.: Performance: qualidade
intimamente associada com eficiência.
Um sistema de software é eficiente se ele
usa os recursos computacionais
economicamente.
• Performance afeta:
– a utilização do software
– a escalabilidade do software
• Abordagens para se avaliar a performance
de um sistema: 1) análise da
complexidade dos algoritmos; 2) medidas
(via monitores); 3) simulação.
• Aplicada a processo, performance =
produtividade
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
25
Qualidades do Software
[5]
• [5] Def.: User Friendliness: um sistema de
software é dito “user friendly” (amigável
ao usuário), quando os seus usuários
humanos acham-no de fácil utilização.
• A interface com o usuário é um dos
importantes componentes da user
friendliness.
• Importância do desenho industrial e
psicologia.
• Em diversas áreas da engenharia alcançase a facilidade de uso através da
padronização da interface humana.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
26
Qualidades do Software
[6]
• [6] Def.: Verificabilidade: qualidade
de um sistema de software em que as
suas propriedades são facilmente
verificáveis.
• Pode-se verificar as propriedades
de um sistema através de:
– métodos de análise formais
– testes (uso de monitores de software)
• Projeto modular, disciplina na
codificação e uso de LP´s
apropriadas contribuem para a
verificabilidade.
• É uma qualidade interna.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
27
Qualidades do Software
[7]
• [7] Def.: Maintainability
(mantenubilidade): O termo manutenção
de software é normalmente utilizado para
se referir a modificações que são feitas a
um sistema de software após o seu release
inicial (i.e., após ter sido disponibilizado
para o seu público alvo).
• A manutenção pode ser: corretiva,
adaptativa e perfectiva.
• Manutenção corretiva: trata da remoção
dos erros residuais presentes no software
após a sua entrega, ou dos erros
introduzidos durante a própria
manutenção.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
28
Qualidades do Software
[7]...
• Manutenção adaptativa:compreende o
ajuste da aplicação a alterações no seu
ambiente (ex. adaptaçõ a um novo
sistema operacional, a novos dispositivos
legais, etc.)
• Manutenção perfectiva:compreende a
alteração do software, de modo a
melhorar a sua qualidade (ex.: acrescentar
novas funções ao software de modo a
facilitar o seu uso).
• Existem evidências de que os custos de
manutenção excedem a 60% do custo
total do software.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
29
Qualidades do Software
[8]
• [8] Def.: Repairability: um sistema de
software é dito reparável quando ele
permite a correção de seus defeitos com
uma quantidade limitada de trabalho.
• Na engenharia tradicional uma técnica
para se tornar os produtos reparáveis é o
uso de partes e peças padrão que possam
ser facilmente substituíveis.
• Repairability é afetada pelo número de
componentes do produto.
• Em software aumenta-se a reparabilidade
através de técnicas adequadas de
modularização e do uso de ferramentas
adequadas (ex.: LPs de alto nível)
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
30
Qualidades do Software
[9]
• [9] Def.: Evolvability: trata-se da
capacidade de um sistema de software de
incorporar alterações ao seu projeto
original, de modo a incorporar novas
funções ou alterar funções já existentes.
• Estudos demonstram que a evolvability
decresce a cada novo release de um
produto de software.
• Desde a concepção inicial do produto
deve-se levar em consideração a
capacidade de evolução do produto.
• É uma das mais impportantes qualidades
do sw.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
31
Qualidades do Software
[10]
• [10] Def.: Reusability: trata-se de uma qualidade
mais aplicável aos componentes de um sistema
de software que ao sistema como um todo. É a
capacidade de se usar módulos/componentes de
software já existentes, a fim de se construir
novos produtos.
• Exs.: bibliotecas científicas, classes do JDK, etc.
• É uma qualidade difícil de se conseguir a
posteriori. Deve-se procurar alcançá-la à medida
que os próprios componentes vão sendo
construídos.
• A reusabilidade pode se dar em vários níveis: i)
pessoas – conhecimento do domínio da
aplicação; ii) requisitos do sistema; iii) módulos;
iv) código.
• Aplica-se ao produto (sw) e ao processo
(metodologias de software, ciclo de vida).
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
32
Qualidades do Software
[11]
• [11] Def.: Portability: é a capacidade de
um sistema de software ser executado em
diferentes ambientes.
• Mesmo que restrita a uma mesma família
de processadores, a portabilidade é
importante, em virtude de variações no
conjunto de instruções e na capacidade de
memória.
• Há necessidade de técnicas que permitam
ao sw determinar as capacidades do hw e
se adaptar às mesmas.
• Ex. Java, padrões do tipo SQL.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
33
Qualidades do Software
[12]
• [12] Def.: Understandability: é a
facilidade com que um sistema de
software é compreendido, levando-se em
conta, naturalmente, que alguns tipos de
sistemas são mais complexos que outros.
• Understandability é uma qualidade com
aspectos internos e externos. Do ponto de
vista interno ajuda a alcançar outras
qualidades, tais como evolvability e
verifiability. Do ponto de vista externo, o
usuário considerará um sistema
compreensível se ele possuir um
comportamento previsível e for user
friendly.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
34
Qualidades do Software
[13]
• [13] Def.: Interoperability: diz respeito à
habilidade de um sistema coexistir e cooperar
com outros sistemas.
• O ambiente UNIX, encoraja as aplicações a
possuir uma interface simples e padrão, o que
permite que a saída de uma aplicação seja usada
como entrada para outra aplicação.
• Interoperability pode ser atingida através da
padronização de interfaces.
• Open System: é uma coleção extensível de
aplicações independentes que cooperam entre si
para formar um sistema integrado. Permite que
organizações independentes adicionem novas
funcionalidades após a entrega do sistema ao
mercado.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
35
Qualidades do Software
[14]
• [14] Def.: Produtividade: é uma
qualidade do processo de produção de
software. É a qualidade de performance
aplicada ao processo de software.
• Trade-offs – Ex.: a programação de
módulos reusáveis é mais difícil e implica
em menor produtividade no
desenvolvimento de software.
• Necessidade de métricas para se medir a
produtividade do software ou qualquer
outra qualidade.
• Ferramentas especiais têm um impacto
positivo sobre a produtividade (ex,:
ferramentas CASE, LPs de alto nível,
emprego de determinadas metodologias,
etc.)
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
36
Qualidades do Software
[15]
• [15] Def.: Timeliness: trata-se da
habilidade de se entregar um produto no
tempo aprazado para tal.
• Timeliness requer um planejamento
cuidadoso, uma estimativa apropriada do
trabalho a ser realizado e marcos
(milestones) especificados e verificáveis
(do trabalho já desenvolvido).
• Problemas: dificuldade de se mensurar a
produtividade dos desenvolvedores de sw;
falta de métricas adequadas; uso de
marcos imprecisos e não verificáveis;
alteração contínua dos requisitos do
sistema.
• Incremental delivery
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
37
Qualidades do Software
[15]...
função
Requisitos do usuário
Sistema real
tempo
t0 t1
t4
UERJ Setembro 2001
t2
t3
© Oscar Luiz Monteiro de Farias
38
Qualidades do Software
[16]
• [16] Def.: Visibilidade: Um processo de
desenvolvimento de sw é visível se todas
as suas etapas e o seu estado corrente
estão claramente documentados, i. e.,
estão facilmente disponíveis para um
exame (análise) externo.
• a especificação dos requisitos do sistema
e dos requisitos do projeto também devem
estar bem documentados.
• Tensão entre membros da equipe de
desenvolvimento: estabilização x
desestabilização do estabilização x
desestabilização do software
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
39
Qualidades do Software
[16]...
• Um produto é visível se ele é
estruturado como uma coleção de
módulos, com funções claramente
compreensíveis e se há fácil acesso à
sua documentação.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
40
Princípios da Engenharia de
Software...
• Serão abordados princípios gerais que são
centrais para um desenvolvimento de
software bem sucedido.
• Estes princípios dizem respeito ao
processo de software e ao produto final.
• Os princípios são colocações gerais e
abstratas que descrevem propriedades
desejáveis do processo de software e do
produto final.
• Para aplicar os princípios precisamos de
técnicas e metódos.
• Os métodos e técnicas ajudam a
incorporar aos processos e aos produtos
as propriedades (qualidades) desejadas.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
41
Princípios da Engenharia de
Software...
• Métodos são orientações gerais que
governam a execução de alguma
atividade. São abordagens rigorosas,
sistemáticas e disciplinadas
• Técnicas, em geral, possuem uma
aplicabilidade mais restrita.
• Metodologia = métodos + técnicas
• O objetivo da metodologia é promover
uma certa abordagem para resolver um
problema, através de uma escolha prévia
dos métodos e técnicas a serem usados.
• Ferramentas suportam a aplicação de
metodologias, métodos e técnicas.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
42
Princípios da Engenharia de
Software...
Ferramentas
Métododologias
Métodos e técnicas
Princípios
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
43
Princípios da Engenharia de
Software...
• [1] Rigor e Formalismo
Existem vários níveis de rigor. O maior
deles seria o formalismo.
Ex.: A descrição de um programa pode
ser feita através de uma linguagem natural
ou por meio de uma descrição formal em
uma linguagem com comandos lógicos.
• A vantagem do formalismo é que é a base
do processo de automação.
• Tradicionalmente, a única fase do
processo de desenvolvimento de software
que possui uma abordagem formal é a de
programação.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
44
Princípios da Engenharia de
Software...
• Deve-se aplicar rigor e formalismo
em todas as fases do processo de
desenvolvimento de software.
• Uma documentação rigorosa do
processo de software ajuda no reuso
do processo em outros projetos
similares e também na manutenção
do sistema.
• Além disso facilita a monitoração do
processo (timeliness e
produtividade)
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
45
Princípios da Engenharia de
Software...
• [2] Separation of Concerns (separação das
preocupações): permite que se lide com os
diferentes aspectos individuais de um problema.
• Várias decisões devem ser tomadas no
desenvolvimento de um produto de software
relativas:
–
i) às características desejáveis do produto, tais como:
funções ofertadas, plataformas em que será executado
o sw, eficiência em termos de tempo e espaço, tipos de
interfaces com o usuário, etc.
– ii) ao processo de desenvolvimento: ambiente de
desenvolvimemto, organização e estrutura das equipes,
planejamento, procedimentos de controle, estratégias
de projeto;
– iii) a aspectos econômicos e financeiros.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
46
Princípios da Engenharia de
Software...
• A Separation of Concerns pode se dar de várias
formas:
i) no tempo – é a motivação subjacente ao ciclo
de vida do software;
ii) em termos das qualidades desejadas para o sw
(ex.: primeiro assegura a correctness e então
reestrutura o programa para garantir a
eficiência);
iii) diferentes visões do sistema (fluxo de dados
entre as diferentes atividades X fluxo de controle
que governa a sincronização das atividades);
iv) diferentes partes do sistema 
Modularidade;
v) divisão de responsabilidades e tarefas;
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
47
Princípios da Engenharia de
Software...
•
•
[3] Modularidade: este princípio
procura subdividir um sistema em
vários módulos.
Benefícios da modularidade: permite
que a separation of concerns seja
aplicada em duas fases:
1.
Ao se lidar com cada módulo isoladamente
(ignorando os detalhes dos outros
módulos);
2. Ao se lidar com as características gerais de
cada módulo e suas relações com os outros
módulos, de forma a integrá-los e a
construir um sistema coerente.
•
Bottom up x Top down design
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
48
Princípios da Engenharia de
Software...
• Modularidade é um princípio importante
na engenharia, estando presente na
maioria dos processos e produtos.
• O princípio da modularidade não apenas é
um princípio desejável na fase de projeto;
ele permeia toda a atividade de produção
de software.
• As três metas da modularidade:
– A decomposição de sistemas
complexos
– A composição de sistemas a partir de
módulos
– A compreensão do sistema em partes
(módulos)
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
49
Princípios da Engenharia de
Software...
• Idealmente na produção de software seria
desejável a montagem de novas
aplicações a partir de módulos já
disponíveis em bibliotecas.
• Para se alcançar as três metas da
modularidade os módulos devem ter alta
coesão e um baixo acoplamento.
• Um módulo possui alta coesão, quando os
seus elementos estão fortemente
relacionados.
• Acoplamento caracteriza a relação de um
módulo com os outros módulos que
compõem um sistema.
• Dinâmica de alta freqüência x Dinâmica
de baixa freqüência
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
50
Princípios da Engenharia de
Software...
• [4] Abstração: é um processo em
que identificamos os aspectos
importantes de um fenômeno e
ignoramos os detalhes.
• Uma abstração denota as
características essenciais de um
objeto, que o distingüe de todos os
outros tipos de objetos e, assim,
fornece fronteiras conceituais bem
definidas, relativas à perspectiva do
observador (Booch).
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
51
Princípios da Engenharia de
Software...
• [5] Antecipação a mudanças: é a
habilidade de se projetar um sistema, já
tendo em vista possíveis alterações
futuras a serem incorporadas ao mesmo,
de forma que estas alterações possam ser
facilmente absovidas e implementadas.
• Basicamente, as alterações prováveis
devem ser isoladas em partes (regiões)
específicas do software, de modo que as
alterações fiquem restritas a pequenas
partes.
• É um princípio utilizado para se atingir a
evolvability.
• Reusability pode ser vista como
evolvability em baixa granuralidade, i.e.
evolvability a nível de componente.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
52
Princípios da Engenharia de
Software...
• Antecipação a mudanças requer o uso de
ferramentas adequadas para se gerenciar
as diferentes configurações do sistema
que co-existirão em um dado instante.
• Configuration management
• Capacidade para armazenar e recuperar
documentação, módulos-fonte, módulosobjeto, etc.
• Antecipação a mudanças também afeta o
processo de desenvolvimento de software
(ex.: personnel turnover).
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
53
Princípios da Engenharia de
Software...
• [6] Generalidade: sempre que colocados
frente a um problema específico devemos
procurar descobrir a solução para um
problema mais geral, do qual o problema
que se procura solucionar é uma instância
particular.
• A solução mais geral poderá ser
reutilizada em outros contextos;
• Eventualmente poder-se-á encontrar um
software off-the-shelf que seja a solução
para o problema dado;
• A solução mais geral pode ser mais cara;
• Avaliar o trade-off: generalidade x (custo
+ eficiência)
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
54
Princípios da Engenharia de
Software...
• [7] Incrementabilidade: caracteriza um
processo que progride passo a passo, em
incrementos. A meta desejada é alcançada
por aproximações sucessivas cada vez
mais próximas. Cada aproximação é
alcançada através de um incremento à
aproximação anterior.
• Significa que o software deve ser o
produto final de um processo evolutivo.
• Uma forma de se aplicar este princípio
consiste em se identificar, ainda no início,
subsets da aplicação, que possam ser
desenvolvidas e entregues aos usuários,
de modo a se ter um feedback
antecipado...
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
55
Princípios da Engenharia de
Software...
• A motivação para a incrementabilidade é
que, na maior parte dos casos práticos,
não há como se obter todos os requisitos
de um sistema antes que a aplicação seja
desenvolvida.
• Incrementabilidade e antecipação a
mudanças estão interligadas e são as
bases da evolvability.
• Estágios intermediários da aplicação
podem ser vistos como protótipos.
• O desenvolvimento evolutivo de software
requer cuidados especiais com a gerência
da documentação, dos programas, dos
dados de teste, etc.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
56
Software Design
(Projeto)...
• O projeto de software é uma atividade
fundamental no processo que
progressivamente transforma os requisitos
do sistema, através de vários estágios
intermediários, em um produto final.
• Software Design é uma decomposição de
um sistema em módulos, a descrição do
que cada módulo deverá fazer e a
descrição do tipo de relações existentes
entre os módulos.
• O produto final do design é a arquitetura
do software.
• Aplicam-se os vários princípios da
Engenharia de Software
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
57
Software Design
(Projeto)...
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
58
Software Design
(Projeto)...
• Para se ter projetos de qualidade:
– Cuidadosa definição da estrutura
modular e das relações existentes entre
os módulos
– Escolha de critérios apropriados para
se decompor um sistema em módulos.
• Um dos critérios é information hiding
• O Design é mapeado em programas, que
correspondem à sua implementação.
• Não há receitas gerais que possam ser
aplicadas em todas as circunstâncias.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
59
Objetivos do Software
Design...
• A decomposição de um sistema em
módulos pode se dar de diversas formas.
• Quando um módulo M é decomposto em
outros módulos, diz-se que estes módulos
implementam M.
• Top down design: A implementação é
realizada através de uma decomposição
recursiva em módulos, até que a
implementação possa ser diretamente
realizada em termos de uma linguagem de
programação.
• Botton-up design: o processo de design
consiste na definição de módulos que
possam ser interativamente combinados
para juntos formar um subsistema.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
60
Metas importantes do
Software Design
1. Antecipação a mudanças – a idéia é
produzir um projeto de software que
possa facilmente acomodar alterações
futuras.
A experiência prévia do engenheiro de
software e um profundo entendimento
do domínio do problema pelo usuário
final são fundamentais na identificação
de áreas em potencial sujeitas a
mudanças e na futura evolução do
sistema.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
61
Antecipação a mudanças...
a) Mudanças de algoritmos – para
aumentar a performance do sistema, ou
lidar com um caso mais geral, etc.
Ex.: algoritmo de sort – o melhor
algoritmo a ser aplicado dependerá do
tamanho da lista a ser classificada, da
distribuição dos dados na lista, etc.
Conseqüentemente a escolha do melhor
algoritmo dependerá de dados
experimentais a serem adquiridos após
o sistema estar operacional.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
62
Antecipação a mudanças...
b) Mudança na representação de dados:
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
63
Antecipação a mudanças...
c) Mudança da máquina virtual (abstrata):
Máquina virtual: conjunto de serviços
oferecidos em um determinado nível i
de programação e que são utilizados por
módulos de um nível mais elevado –
i+1.
Ex.: uso de novas versões de
linguagens, sistemas gerenciadores de
banco de dados, sistemas operacionais,
etc.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
64
Antecipação a mudanças...
d) Mudança de dispositivos periféricos:
caso especial de alterações efetuadas em
embedded systems em que existem
diversos tipos de “dispositivos
periféricos”.
e) Mudanças no ambiente social:
ex.: alterações em legislações
específicas, na moeda, etc.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
65
Famílias de Programas...
2. Famílias de Programas – ao invés de se
considerar as diferentes versões de um
software produto como diferentes
produtos, consideram-se estas versões
como membros de uma mesma família
de produtos com muito em comum e
que são apenas parcialmente diferentes.
Exs.:
a) um software com versões em
diferentes línguas.
b) um sistema gerenciador de banco de
dados distribuído para diferentes
sistemas operacionais.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
66
Famílias de Programas...
1
1
1
2
2
2
3
3
3
4
5
UERJ Setembro 2001
4
5
© Oscar Luiz Monteiro de Farias
6
7
67
Técnicas de
Modularização...
• Módulo: fragmento de software que
corresponde a mais que simplesmente
uma rotina. Pode ser um conjunto de
rotinas, de dados, de definição de tipos,
ou uma combinação destes elementos.
• Um módulo pode ser visto como um
fornecedor de recursos e/ou serviços
computacionais.
• Existem relações de diversos tipos entre
módulos: ordem de desenvolvimento,
importância relativa, parte de, uso de
facilidades providas por outros módulos,
etc.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
68
Técnicas de
Modularização...
• Seja S um sistema de software
composto dos módulos M1, M2, ...,
Mn. Uma relação r em S é um
subconjunto de S x S. Se dois
módulos Mi e Mj estão em S,
representamos o fato de que o par
< Mi, Mj > está em r, usando a
notação infixa Mi r Mj.
• A relação r é irreflexiva, i.e., Mi r Mi
não pode valer para qualquer
módulo Mi em S.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
69
Técnicas de
Modularização...
• O fechamento transitivo (transitive
closure) de uma relação r em S é uma
relação em S, denotada por r+. Sejam Mi e
Mj dois elementos de S. Então r+ pode ser
recursivamente definida como se segue:
Mi r+ Mj se e somente se (sss) Mi r Mj ou
existe um elemento Mk em S, tal que Mi r
Mk e Mk r+ Mj.
• O fechamento transitivo captura a noção
intuitiva de relações diretas e indiretas.
• Para dois módulos A e B, A CALL+ B,
implica que A CALL B diretamente ou
através de uma cadeia de CALLs.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
70
Técnicas de
Modularização...
• Uma relação pode ser representada
como um grafo dirigido cujos nodos
são elementos de S e em que um
arco dirigido existe de um nodo Mi
para um nodo Mj sss Mi r Mj.
• Uma relação é uma hierarquia sss
não existem ciclos no grafo da
relação (grafo dirigido acíclico –
directed acyclic graph – dag).
• USES, IS_COMPONENT_OF,
INHERITS_FROM
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
71
Grafo Geral e dag
M1
M1
M1,1
M2
M1,2
M1,3
M3
M1,2,1 M1,2,2
M4
M5
M1,2,1,1
M3
M3
M6
M4
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
72
A Relação USES...
• Dados dois módulos distintos Mi e Mj,
diz-se que Mi USES Mj sss a correta
execução de Mj é necessária para que Mi
complete a tarefa descrita em sua
especificação.
• Se Mi USES Mj, diz-se que Mi é um
cliente de Mj, visto que Mi requer os
serviços que Mj provê.
• A relação USES não é equivalente a
conter chamadas a procedimentos
• Exs.: tasks que cooperam através troca de
mensagens; módulos que compartilham
uma mesma estrutura de dados;
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
73
A Relação USES...
• Uma boa restrição à relação USES é a de
que seja uma hierarquia.
• Separation of concerns poderia ser
aplicada ao “percorrer-se” a relação
USES.
• Além disso, se a estrutura de USES não
for hierárquica ter-se-á um ciclo e uma
sitema em que “nada funciona, até que
tudo funcione”.
• A restrição da estrutura de USES ser
hierárquica define um sistema através de
sucessivos níveis de abstração.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
74
A Relação USES...
• Def.: Nível de um módulo: O nível de um
módulo que não é usado por nenhum
outro módulo é zero, e o nível de qualquer
outro módulo M é i, onde i é o
comprimento do maior caminho no dag
que conecta um módulo de nível zero ao
nodo M.
• Conceito de Máquinas Virtuais
(Abstratas)
• A relação entre módulos é definida
estaticamente, i.e. é independente da
execução do software.
Ex.: M USES M1 e M USES M2
if cond then proc_1 else proc_2
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
75
A Relação USES...
• fan-in: número de arestas que incidem
(entram) em um nodo
• fan-out: número de arestas que saem de
um nodo
• Um alto fan-in seria um indicativo de um
bom design, pois indicaria um alto grau
de reuso de um módulo.
• O fan-out deve ser mantido baixo.
• A relação USES não é suficiente para
avaliar a qualidade de um projeto
(design).
• É preciso analisar-se a natureza da
interação entre os módulos.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
76
A Relação
IS_COMPONENT_OF...
• Seja S um conjunto de módulos. Para
quaisquer Mi e Mj em S, Mi
IS_COMPONENT_OF Mj significa que
Mj é realizado através da agregação de
vários módulos, um deles sendo Mi.
• COMPRISES é definido como a relação
inversa de IS_COMPONENT_OF.
• Para quaisquer dois elementos Mi e Mj em
S, diz-se que Mi COMPRISES Mj sss Mj
IS_COMPONENT_OF Mi.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
77
A Relação
IS_COMPONENT_OF...
• Seja MS,i um subconjunto de S definido
como se segue:
MS,i = {Mk | Mk está em S e Mk
IS_COMPONENT_OF M}
Então pode-se dizer que Mi
IS_COMPOSED_OF MS,i e,
alternativamente, que MS,i IMPLEMENTS
Mi.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
78
IS_COMPONENT_OF X COMPRISES
IS_COMPONENT_OF
M7 M8 M9 M5
M2
M3
M1
UERJ Setembro 2001
M4
COMPRISES
M6
M1
M2
M3
M4
M7 M8 M9 M5
M6
© Oscar Luiz Monteiro de Farias
79
Information Hiding...
• As relações USES e
IS_COMPONENT_OF fornecem apenas
uma descrição grosseira da arquitetura de
um software.
• Quando um módulo Mi que usa o módulo
Mj é refinado em seus módulos
constituintes Mi, 1, Mi, 2, ..., Mi, n é
necessário esclarecer o que a relação
USES entre o conjunto {Mi1, Mi,2, ..., Mi,n}
e Mi significa.
• O ideal seria subdividir-se um sistema em
componentes tal que cada componente
pudesse ser projetado independentemente
dos outros componentes.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
80
Information Hiding...
Interface
Implementation
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
81
Information Hiding...
• Interface: conjunto de serviços que um
módulo disponibiliza aos seus clientes.
• Estes serviços são exportados pelo
módulo e importados pelos clientes.
• Implementation: a forma pela qual estes
serviços são realizados pelo módulo.
• A interface é uma abstração do módulo
do ponto de vista de seus clientes.
• A implementação de um módulo é a
decomposição do módulo em seus
componentes pela relação
IS_COMPONENT_OF, ou a sua codificação
em uma LP.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
82
Information Hiding...
• Information Hiding: o cliente conhece os
serviços oferecidos apenas pela interface.
A implementação é totalmente oculta.
• Um aspecto crucial da atividade de design
é a decisão sobre o que deve ser visível
em um módulo (interface) e o que deve
permanecer oculto (implementation).
• Se a interface não se altera, pode-se
realizar alterações na implementation sem
afetar os clientes.
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
83
Information Hiding...
UERJ Setembro 2001
© Oscar Luiz Monteiro de Farias
84