Engenharia de Software II - AULA 5

Prévia do material em texto

5ºAula
Especifi cação e desenvolvimento 
de sistemas críticos
Olá, pessoal, tudo bem?
Em nossa quinta aula, verificamos especificação e 
desenvolvimento de sistemas críticos. Vamos entender a 
importância da confiabilidade para a atuação dos engenheiros 
de software no momento de trabalhar com esses sistemas, por 
isso, destaca-se a importância desse conteúdo.
Espero que estejam animados para dar continuidade à 
nossa aula.
Vamos lá?
Boa aula!
Objetivos de aprendizagem
Esperamos que, ao término desta aula, vocês sejam capazes de:
• entender os sistemas críticos;
• ter claro o conceito de confiabilidade na atuação com sistemas críticos.
34Engenharia de software II
1 - Introdução a sistemas críticos
2 - A importância da especificação
3 - Desenvolvimento de sistemas críticos
4 - Confiança no sistema
Seções de estudo
1 - Introdução a sistemas críticos
2 - A importância da especifi cação
Ian Sommerville (2013) cita em sua obra a seguinte 
situação
Em setembro de 1993, um avião aterrissou no aeroporto de Varsóvia, 
na Polônia, durante uma tempestade. Por nove segundos após a 
aterrissagem, os freios do sistema, controlado por computador, não 
funcionaram. O sistema de frenagem não reconheceu que o avião 
havia aterrissado e assumiu que a aeronave ainda estava no ar. Um 
recurso de segurança da aeronave havia parado a entrada do sistema 
reverso de empuxo, que diminui a velocidade da aeronave, pois se o 
avião estiver no ar isso pode ser perigoso. O avião passou do limite 
fi nal da pista, atingiu um banco de terra e pegou fogo.
O inquérito sobre o acidente revelou que o software do sistema de 
frenagem tinha operado de acordo com sua especifi cação. Não 
houve erros no programa. No entanto, a especifi cação de software 
foi incompleta e não levou em consideração uma situação rara, que 
surgiu no caso apresentado. O software funcionou, mas o sistema 
falhou. Esse caso mostra que a confi ança de sistema não depende 
apenas da boa engenharia, mas também exige atenção aos detalhes 
quando os requisitos de sistema são derivados e ocorre a inclusão de 
requisitos especiais de software orientados a garantir a confi ança e a 
proteção de um sistema. (SOMMERVILLE, 2013, p. 216).
O relato de Sommerville (2013) ilustra a importância da 
especificação para sistemas críticos. Devido às possibilidades 
de falhas em um sistema, é necessário que as especificações, 
em sistemas críticos, corresponda as necessidades de usuários 
reais do sistema.
Falhas em software são comuns. As falhas podem causar 
desde pequenas inconveniências ou, em alguns casos, perdas 
econômicas significativas. Também é possível que se causem 
danos físicos ou ameaças à vida humana. Quando o sistema 
pode ocasionar falhas graves, é chamado de sistema crítico e 
podem ser classificados em três tipos:
• Sistemas críticos de segurança: a falha desse sistema 
pode resultar em prejuízo, perda de vida ou danos graves 
ao meio ambiente. Por exemplo, um sistema de controle em 
fábrica de produtos químicos;
• Sistemas críticos de missão: pode resultar em problema 
de alguma atividade dirigida a temas. Um exemplo de sistema 
crítico de missão é um sistema de navegação de uma nave 
espacial;
• Sistemas críticos de negócios: sua falha pode resultar 
em custos muito altos para o negócio que dispõe desse 
sistema. Por exemplo: sistemas de contabilidade de cientes 
em um banco.
Entre as propriedades de um sistema crítico, a mais 
importante é a confiança. Esse termo está relacionado aos 
atributos do sistema referente à confiabilidade, proteção e 
segurança. Entre as motivações que evidenciam a importância 
da confiabilidade em um sistema crítico, estão:
• Os sistemas não confiáveis são rejeitados pelos usuários. 
Assim, caso o sistema não apresente segurança e proteção 
adequadas não será utilizado. Isso faz com a empresa que 
comercialize um produto inseguro fique com sua imagem 
prejudicada, pois os usuários questionarão sempre sua 
confiabilidade.
• Os custos de falhas de sistemas podem ser extremamente 
elevados. Uma falha do sistema pode gerar, em alguns casos, 
um gasto excessivo. Em caso da queda de uma aeronave por 
falha no sistema, por exemplo, geram-se gastos não planejados.
• Sistemas não confiáveis podem causar perda de 
informação. Os dados geram custos para serem armazenados. 
Devido a isso, essas informações precisam estar seguramente 
guardadas. O contrário faria com que todo o investimento no 
armazenamento fosse em vão.
O custo elevado das falhas ocasionadas em sistemas críticos 
permite entender que os métodos e as técnicas confiáveis 
para seu desenvolvimento são essenciais. Do mesmo modo, 
os sistemas críticos são desenvolvidos por meio de técnicas 
consagradas ao invés de técnicas recentes, ainda não submetidas 
a experiências práticas de modo a validar sua confiabilidade. As 
técnicas mais antigas já têm suas potencialidades e fragilidades 
mapeadas. Isso contribui significativamente para a redução de 
riscos.
Certamente, os operadores de sistema podem ajudar 
a superar problemas, mas também podem também causar 
problemas, ao cometerem erros. Existem três componentes de 
sistema nos quais as falhas de sistemas críticos podem ocorrer. 
São eles:
• Hardware: pode falhar por causa de erros em seu projeto, 
de falha dos componentes, resultante de erros de fabricação, 
ou de componentes que atingiram o fim de sua vida útil;
• Software: pode falhar por causa de erros em sua 
especificação, projeto ou implementação;
• Operadores humanos podem falhar em operar o sistema 
corretamente. Como o hardware e o software tornaram-se mais 
confiáveis, falhas na operação são atualmente a maior causa de 
falhas no sistema.
É importante ressaltar que as falhas podem estar 
associadas, pois a falha de um componente de hardware pode 
fazer com que os operadores do sistema tenham que ligar com 
situações não previstas e altas cargas de trabalho. Essa situação 
é responsável por fazer com que as pessoas fiquem sob pressão 
e cometam erros, causando, assim, uma falha no software devido 
a questões relacionadas aos operadores humanos.
Devido à necessidade de grande confiabilidade nos 
sistemas críticos, geram-se dois tipos de requisitos: os funcionais 
e os não funcionais. Os primeiros são gerados para definir 
recursos de verificação e de recuperação de erros, bem como 
de características para fornecer proteção das falhas possíveis. 
Os segundos são gerados para definir a confiabilidade e a 
35
3 - Desenvolvimento de sistemas críticos
disponibilidade necessárias ao sistema.
Além dos requisitos descritos, as considerações de 
segurança e proteção podem gerar outro tipo de requisito 
difícil de ser classificado como um requisito funcional ou não 
funcional. Eles são requisitos de alto nível mais bem descritos, 
talvez, como requisitos do tipo “não deve”. Ao contrário dos 
requisitos funcionais normais que definem o que o sistema 
deve fazer, os requisitos do tipo “não deve” definem um 
comportamento inaceitável do sistema, ou seja, o que ele não 
deve fazer. Alguns exemplos desse tipo de requisitos são:
• O sistema não deve permitir que usuários modifiquem 
permissões de acesso de quaisquer arquivos que eles não 
tenham criado (proteção);
• O sistema não deve permitir a seleção de modo reverso 
de empuxo quando a aeronave estiver em voo (segurança);
• O sistema não deve permitir a ativação simultânea de 
mais de três sinais de alarme (segurança).
As especificações formais não são apenas uma base para a 
verificação do projeto e da implementação. Elas especificam a 
maneira mais precisa de especificação de sistemas e, portanto, 
reduzem as chances de mal-entendidos. Além disso, a criação 
de uma especificação formal força uma análise detalhada 
dos requisitos, o que é uma maneira eficiente de descobrir 
problemas na especificação.Sabemos que a confiabilidade na área de software só foi 
alcançada devido a muito trabalho e dedicação dos profissionais. 
Assim, pouco a pouco, as técnicas foram sendo desenvolvidas, 
as linguagens de programação foram sendo aprimoradas e 
passou a haver melhor gerenciamento de qualidade. Contudo, 
em sistemas críticos, os níveis de confiabilidade precisam ser 
muito mais avançados. Então, precisam ser desenvolvidas 
técnicas especiais de desenvolvimento para garantir segurança, 
proteção e confiança no software a ser desenvolvido.
De modo geral, há três abordagens complementares para 
que se desenvolva um software confiável:
• Prevenção de defeitos: devem ser desenvolvidas 
abordagens de desenvolvimento de software que tenham como 
propósito evitar erros de programação, minimizando o número 
de defeitos de um programa.
• Detecção de defeitos: devem ser desenvolvidas 
abordagens para verificar e validar o software, de modo que 
se descubra e reduza defeitos antes de o programa ser 
implementado.
• Tolerância de dados: a programação do sistema 
deve possibilitar que possíveis defeitos ou comportamento 
inesperado sejam reparados mesmo durante a execução, de 
modo que não provoquem falhas no sistema.
A engenharia de software tem se empenhado em 
desenvolver ferramentas, técnicas e métodos que conduzam a 
uma produção sem defeitos. Mas isso não significa que seja 
possível evitar completamente possíveis falhas, tendo em vista 
que erros na especificação terão reflexo no software ou usuários 
podem não entender e usar inapropriadamente o sistema. 
Contudo, o trabalho para eliminar defeitos gera uma qualidade 
significativa.
Em sistemas de pequeno e médio portes, as técnicas de 
engenharia de software tornam possível o desenvolvimento de 
software sem defeitos. É preciso, para tanto, utilizar uma gama 
de técnicas:
• Processos de software confiáveis: o uso de processos 
de software confiáveis é fundamental porque o número de 
defeitos será minimizado, e os detectados posteriormente 
serão detectados;
• Gerenciamento de qualidade: a qualidade deve ser 
o item fundamental dentro da organização. Por isso, os 
programadores devem ser estimulados a criarem programas 
livres de defeitos. Devem ser seguidos procedimentos de 
modo a verificar se os padrões de qualidade foram realmente 
seguidos;
• Especificação formal: deve haver uma especificação 
bem delimitada em relação ao sistema a ser implementado. 
Não se pode correr riscos de haver interpretação errada;
• Verificação estática: o uso de analisadores estáticos 
auxilia na busca de características semelhantes em programas 
que podem ter defeitos. Uma verificação formal com base na 
especificação do sistema;
• Tipagem forte: a linguagem de programação com tipos 
fortes de dados devem ser utilizadas, como, por exemplo, 
Java ou ADDA. Assim, o compilador pode detectar muitos 
defeitos antes de o programa ser entregue;
• Programação segura: algumas construções da 
linguagem de programação são mais complexas e propensas 
a erros do que outras, e pode, assim, conduzir a erros caso 
sejam utilizadas;
• Informações protegidas: deve ser usada uma abordagem 
para projeto e implementação de software com base em 
ocultamento e encapsulamento de informações. Linguagens 
orientadas a objetos, como Java, obviamente, satisfazem 
essa condição. Deve ser encorajado o desenvolvimento de 
programas projetados para facilidade de leitura e compreensão.
Raramente é econômico e prático implantar todas 
as técnicas necessárias para criar software livre de defeitos. 
O custo de encontrar e remover defeitos remanescentes 
aumenta exponencialmente à medida que são descobertos e 
removidos do programa. Na proporção em que o software se 
torna mais confiável, é necessário gastar cada vez mais tempo 
e esforço para encontrar defeitos cada vez em menor número. 
Em determinado estágio, os custos desse esforço tornam-se 
injustificáveis.
Consequentemente, as empresas de desenvolvimento de 
software assumem que seu software sempre terá alguns defeitos. 
O nível de defeitos dependerá do tipo de sistema. Produtos 
comerciais, por exemplo, podem ter nível relativamente alto 
de defeitos, embora tenham melhorado em relação há dez 
anos. Já sistemas críticos têm, normalmente, uma densidade 
de defeitos muito menor.
O ponto em questão é que quando o sistema falha, é 
mais vantajoso descobrir após as consequências do que gastar 
muito tempo e dinheiro antes da entrega. Lógica que não 
pode, certamente, ser aplicada a sistemas críticos. Deve-se 
avaliar cada consequência para que se pode decidir o que é 
menos traumatizante.
36Engenharia de software II
Retomando a aula
Parece que estamos indo bem. Então, para encerrar esta 
aula, vamos recordar:
4 - Confi ança no sistema
Nós já estamos habituados ao problema da falha de 
sistema nos computadores. Aparentemente sem motivo 
nenhum, o computador cai e falha, não fornecendo os 
serviços solicitados. Desse modo, os sistemas não podem 
operar conforme o esperado. Às vezes, podem corromper 
os dados então gerenciados. Nós convivemos com as falhas 
e aprendemos, com os erros, a não confiar plenamente nos 
computadores.
A confiança em um sistema de computador é uma 
propriedade do sistema cuja contrapartida é o merecimento 
a essa confiança. Essa propriedade diz respeito ao grau de 
confiança dos usuários em que o sistema irá operar conforme 
sua expectativa e que não irá “falhar” durante o uso normal. 
Ela não pode ser expressa numericamente, mas os termos 
tais como não confiável, muito confiável e ultraconfiável são 
utilizados para expressar o nível de confiança que podemos 
ter em um sistema.
Confiança e utilidade não tem o mesmo significado. 
Vamos pensar: não acho que o processador de texto que 
usei para este material seja confiável, mas é muito útil. 
Contudo, para refletir a falta de confiança no sistema, salvo 
frequentemente meu trabalho e mantenho diversas cópias de 
back-up. Compensamos, assim, a falta de confiança no sistema 
com ações que reduzem os danos que podem ser causados 
caso o sistema venha a falhar.
Vejamos as quatro dimensões da confiança:
Disponibilidade. Informalmente, a 
disponibilidade de um sistema é a 
probabilidade de que ele esteja pronto e em 
execução, capaz de fornecer serviços úteis a 
qualquer instante. É a capacidade do sistema 
de fornecer serviços quando solicitados;
Confi abilidade. Informalmente, a 
confi abilidade de um sistema é a probabilidade, 
em um dado período de tempo, de que o 
sistema forneça corretamente os serviços, 
conforme esperado pelo usuário. É a 
capacidade do sistema de fornecer os serviços 
conforme especifi cado;
Segurança. Informalmente, a segurança de um 
sistema um julgamento da probabilidade de 
que um sistema cause danos para pessoas ou 
para o ambiente. É a capacidade do sistema de 
operar sem falhas catastrófi cas;
Proteção. Informalmente, a proteção do sistema 
é um julgamento da probabilidade de que um 
sistema possa resistir a intrusões acidentais 
ou intencionais. É a capacidade do sistema 
de proteger-se contra intrusões acidentais 
ou intencionais. Adaptado de: <www.
posse.ueg.br/index.php/artigos.../204_
abb417eacc8f79430b9aa95638135a15>.
As propriedades de confiança são complexas, podendo 
se decompostas em outra série de propriedades mais simples. 
A proteção inclui a integridade e confidencialidade. Além 
disso, confiabilidade inclui correção, precisão e cumprimento 
do prazo.
1 - Introdução a sistemas críticos
Vimos o conceito de sistemas críticos. Falhas em 
software são comuns. As falhas podem causar desde pequenas 
inconveniências ou, em alguns casos, perdas econômicas 
significativas. Também é possível que se causem danos físicos 
ou ameaças à vida humana. Quando o sistema pode ocasionar 
falhas graves, é chamado de sistema crítico.
2 - A importância daespecificação
Devido à necessidade de grande confiabilidade nos 
sistemas críticos, geram-se dois tipos de requisitos: os 
funcionais e os não funcionais. Vimos, assim, a necessidade da 
especificação em sistemas críticos.
3 - Desenvolvimento de sistemas críticos
Sabemos que a confiabilidade na área de software só foi 
alcançada devido a muito trabalho e dedicação dos profissionais. 
Assim, pouco a pouco, as técnicas foram sendo desenvolvidas, 
as linguagens de programação foram sendo aprimoradas e 
passou a haver melhor gerenciamento de qualidade. Contudo, 
em sistemas críticos, os níveis de confiabilidade precisam ser 
muito mais avançados. Entendemos, na aula, como desenvolver 
um sistema crítico.
4 - Confiança no sistema
Vimos que confiança em um sistema de computador é uma 
propriedade do sistema cuja contrapartida é o merecimento 
a essa confiança. Essa propriedade diz respeito ao grau de 
confiança dos usuários em que o sistema irá operar conforme 
sua expectativa e que não irá “falhar” durante o uso normal. 
Vale a pena
Disponível em: <www.posse.ueg.br/index.php/
artigos.../204_abb417eacc8f79430b9aa95638135a15>.
Vale a pena acessar