Engenharia de Software

1) Conceitos Básicos

• Diferença entre programa e software:

1. programa  arquivo de instruções que executa alguma operação importante (código binário)

2. software  conjunto de arquivos, que inclui:

   • programas

   • banco de dados

   • documentação

• Engenharia de Software inclui áreas de estudo como:

  1. administração de projeto

  2. estrutura organizacional de empresas, etc

• Lida com ‘sistemas de software de grande porte’:

  1. cadastros empresariais e organizacionais

  2. sistemas de controle de chaveamento de telefones

  3. sistemas de segurança para edifícios comerciais

  4. sistemas de gestão de cursos numa universidade

  5. sistemas de controle de tráfego aéreo ou ferroviário

• Diferenças entre ‘Engenharia’ e ‘Engenharia de Software’

  1. Tolerância  menor tolerância com erros de software

  2. Desgaste  software não se desgata

  3. Escala  cliente em geral é único (preço caro!)

  4. N^o de empregados e a produtividade  tempo de aprendizagem é grande

2) Sub-áreas da Engenharia de Software

1. Ética e Engenharia Econômica

2. Requisitos de Software

3. Projeto de Software

4. Construção de Software

5. Gerenciamento de Projetos de Software

6. Evolução e Manutenção de Software

7. Processo de Engenharia de Software

8. Infraestrutura da Engenharia de Software

9. Qualidade de Software

10. Teste de Software

11. Gerência e Configuração de Software

3) Ciclo de Vida do Software

• Uma vez desenvolvido e em operação, um software inicia o seu ciclo de vida (Fig. 6.1):

criação  uso  modificação  uso  modificação  uso

• Problemas provocados pelas modificações

• Estudos mostram que é mais valioso gastar mais tempo desenvolvendo BEM um software, do que tentar modificar um software mal desenvolvido.

• As fases de desenvolvimento de software (Fig. 6.2):

  1. Análise

  2. Projeto

  3. Implementação

  4. Teste

• Análise: estudo acerca da potencialidade e adequação de um sistema como aplicação computacional

  1. decisão sobre software genérico ou personalizado

  2. necessidades do(s) usuário(s) do sistema proposto

• Produto da análise: lista de requisitos que o novo sistema deverá satisfazer

• Linguagem dos requisitos tem que ser a dos usuários

• Após a identificação e listagem dos requisitos do sistema, estes devem ser traduzidos para uma linguagem técnica

• Projeto: nesta fase são desenvolvidos os detalhes técnicos do sistema proposto

• O sistema é dividido em partes manipuláveis, chamadas módulos, onde cada um constitui uma parcela do sistema

• É a decomposição modular que permite a implementação de sistemas de grande porte

• Projeto modular  apenas os detalhes técnicos específicos de cada módulo são considerados de cada vez

• Modularização é estratégia-chave para a manutenção

• Importância da modularização explica a utilização crescente da programação orientada por objetos

• Implementação: nesta fase são elaborados:

  1. os programas propriamente ditos

  2. os arquivos de dados

  3. os bancos de dados

  4. as documentações dos módulos, bancos de dados, etc

• Com o projeto proposto, a equipe de desenvolvimento do sistema é dividida em grupos, onde cada grupo desenvolve o seu módulo

• Teste: fase fortemente ligada à anterior, pois cada módulo, à medida que vai sendo desenvolvido, ao mesmo tempo, já vai sendo testado

• Módulos são testados independentemente

• Dificuldade ENORME de se localizar e depurar erros; a experiência mostra que sistemas de grande porte podem conter, no início, uma quantidade grande de erros

• 1^os métodos eram baseados no ‘Modelo da Cachoeira’

• ‘Modelo da Cachoeira’ permitiria evitar o uso das técnicas de ‘Tentativa e Erro’

• Por outro lado, as técnicas de ‘Tentativa e Erro’ permitem ao programador tentar soluções criativas, não “enxergadas” na fase de projeto do sistema

• Técnicas recentes:

  1. tentam resolver a contradição acima

  2. uso de ferramentas CASE (Eng.de Soft.ajudada por Computador)

  3. uso de programas geradores automáticos de código

• Resultado: flexibilização do ‘Modelo da Cachoeira’

• Técnica da ‘Prototipação’: construção de versões menores e simplificadas, ou de partes do sistema, que possam ser analisadas e testadas antes de se seguir no desenvolvimento do sistema proposto

• Técnicas baseadas no paradigma da orientação por objetos

4) Modularidade

• Para se modificar um sistema é necessário se compreender bem o sistema como um todo

• Tal compreensão já é difícil para programas não muito grande, o que se dirá para grandes sistemas?

• Não fosse o conceito de modularidade seria impossível alguém compreender um sistema de grande porte

• Diagrama estrutural: representação dos módulos de um sistema baseado no paradigma imperativo (Fig. 6.3)

• Este diagrama se baseia numa lista de procedimentos (divisão de trabalho), tais como ‘calcula salário’, ‘calcula impostos’, ‘calcula descontosPre’, etc

• Um sistema orientado por objetos se baseia na identificação dos objetos que aparecem no sistema. Exemplo: ‘folha de pagamento’, ‘empregado’, ‘registro de impostos’, ‘cheque de pagamento’, etc

• Tais objetos “se comunicam” entre si por meio de vários procedimentos (interface entre objetos)

• Uma vez definidos os objetos e identificadas as tarefas que cada um deles executa, passa-se ao projeto interno deles

• Acoplamento dos módulos: é a forma de conexão e comunicação entre os módulos, de seus dados e de suas rotinas (Fig. 6.4)