Aula 02

Prévia do material em texto

Universidade Paulista (UNIP)
Instituto de Ciências Exatas e Tecnológicas (ICET)
Disciplina: Engenharia de Software
Prof. MSc. Vladimir Camelo
Engenharia de Software
O alicerce da engenharia de software é a camada de processo. O processo de engenharia de software é o adesivo que mantém unidas as camadas de tecnologias e permite o desenvolvimento racional e oportuno de softwares de computador. O processo define um arcabouço (conjunto de sub-rotinas, classes e objetos cooperantes que constituem um projeto reutilizável para um domínio de aplicação específico que captura as decisões de projeto que são comuns a esse domínio) que deve ser estabelecido para a efetiva utilização da tecnologia de engenharia de software. Os processos de software formam a base para o controle gerencial de projetos de software e estabelece o contexto no qual os métodos técnicos são aplicados, os produtos de trabalhos (modelos, documentos, dados, relatórios, formulários etc.) são produzidos, os marcos são estabelecidos, a qualidade é assegurada e as modificações são adequadamente geridas.
Engenharia em Camadas
Paradigmas de Engenharia de software
A engenharia de software compreende um conjunto de etapas que envolvem métodos, ferramentas e os procedimentos. Essas etapas muitas vezes são citadas como paradigmas da engenharia de software. Segundo Roger Pressman, “Paradigmas são os modelos de processos que possibilitam”:
Ao gerente: o controle do processo de desenvolvimento de sistemas de software;
Ao desenvolvedor: a obter a base para produzir, de maneira eficiente, software que satisfaça os requisitos preestabelecidos. 
Os paradigmas especificam algumas atividades que devem ser executadas, assim como a ordem em que devem ser executadas. A função dos paradigmas é diminuir os problemas encontrados no processo de desenvolvimento do software, e deve ser escolhido de acordo com a natureza do projeto e do produto a ser desenvolvido, dos métodos e ferramenta a ser utilizado e dos controles e produtos intermediários desejados. 
Um paradigma de programação fornece e determina a visão que o programador possui sobre a estruturação e execução do programa. Assim como diferentes grupos em engenharia de software propõem diferentes metodologias, diferentes linguagens de programação propõem diferentes paradigmas de programação. Um paradigma de engenharia de software é escolhido tendo como base:
A natureza do projeto e da aplicação;
Os métodos e as ferramentas a serem usados;
Os controles e os produtos que precisam ser entregues ao usuário. 
O Ciclo de Vida Clássico
O paradigma do ciclo de vida clássico da Engenharia de Software, também conhecido com Modelo Cascata, o paradigma requer uma abordagem sequencial ao desenvolvimento de software que se inicia em um nível básico e avança ao longo da Análise, Projeto, Codificação, Teste e Manutenção.
O Modelo de Ciclo de Vida Clássico abrange as seguintes atividades:
Análise e Engenharia de Sistemas: Uma vez que o software sempre faz parte de um sistema mais amplo, o trabalho inicia-se com o estabelecimento dos requisitos para todos os elementos do sistema. Essa visão é essencial quando o software deve fazer interface com outros elementos, tais como hardware, pessoas e banco de dados.
Análise de Requisitos de Software: O processo de coleta dos requisitos é intensificado e concentrado especificamente no software. O Engenheiro (“Analista”) de software deve compreender o domínio (escopo) da informação. Os requisitos são documentados e revistos com o cliente.
Projeto: O projeto de software é, de fato, um processo de múltiplos passos que se concentra em quatro atributos distintos: Estrutura de dados, Arquitetura de Software, Detalhes Procedimentais e Caracterização de Interface. Como os requisitos, o projeto é documentado e torna-se parte da configuração do software.
Codificação: A etapa de codificação executa a tarefa de traduzir o projeto em uma forma legível por máquina. Se o projeto estiver bem detalhado a codificação pode ser executada mecanicamente.
Testes: Tão logo finalizada a fase de codificação inicia-se os testes. O processo de testes concentra-se nos aspectos lógicos internos do software, garantindo que todas as rotinas tenham sido testadas. Concentra-se também nos aspectos funcionais externos, verificando se as entradas externas produzem resultados reais que reflitam o exigido.
Manutenção: Indubitavelmente, o software sofrerá mudanças depois que for entregue ao cliente. Mudanças essas por erros que foram encontrados ou porque o cliente exigiu acréscimos funcionais ou de desempenho. A manutenção reaplica cada uma das etapas precedentes do ciclo de vida clássico, e não a um novo.
O ciclo de vida clássico é o paradigma mas antigo e o mais amplamente usado da Engenharia de Software. Porém, nas últimas décadas várias críticas levantadas questionam sua aplicabilidade em todas as situações.
Alguns dos problemas levantados:
Os projetos reais raramente seguem o fluxo sequencial que o modelo propõe.
Muitas vezes é difícil para o cliente declarar todas as exigências explicitamente logo no início.
Exige paciência do cliente. Uma versão do software não estará disponível até um ponto tardio do cronograma do projeto. Um erro grosseiro se não detectado pode ser desastroso.
Apesar desses problemas serem reais o paradigma do Ciclo de Vida Clássico tem um lugar definido e importante na Engenharia de Software. Embora tenha fragilidade, ele é significativamente melhor do que uma abordagem casual ao desenvolvimento de software.
Prototipação
Prototipação é uma abordagem baseada numa visão evolutiva do desenvolvimento de software, afetando o processo como um todo. Esta abordagem envolve a produção de versões iniciais - "protótipos" - de um sistema futuro com o qual pode-se realizar verificações, testes e experimentações para se avaliar algumas de suas qualidades e possíveis capacidades antes que o sistema venha realmente a ser construído. 
Tipos de Protótipos
O relacionamento entre um protótipo e as atividades do processo de desenvolvimento - início do projeto e análise de requisitos, design da interface e da aplicação, e implementação - permite a identificação de 4  tipos de protótipos: 
Protótipo de Apresentação - oferece suporte ao início do projeto e é usado para convencer o cliente de que o futuro sistema é viável e que a interface do usuário se adéqua aos requisitos. Na maioria dos casos é usado para mostrar visão que o usuário têm do sistema e revelar aspectos importantes da interface. 
Protótipo Autêntico - é um sistema de software provisório e funcional, geralmente projetado para ilustrar aspectos específicos da interface de usuários ou parte da funcionalidade, ajudando na compreensão dos problemas envolvidos. 
Protótipo Funcional -- é derivado do modelo do domínio do problema ou da especificação do software e serve para ajudar à equipe de desenvolvimento compreender questões relacionadas com a construção do sistema. Esse protótipo não interessa aos usuários. 
Sistema Piloto - é usado não apenas com propósitos ilustrativos, mas como um núcleo básico operacional do sistema. Esse sistema deve ser instalado no ambiente de aplicação e experimentado com os usuários. 
Objetivos da Prototipação
Num projeto de software várias questões podem ser respondida com a construção de protótipos. Nas situações típicas de desenvolvimento podemos distinguir entre diferentes objetivos na prototipação: 
Exploratória - é quando o protótipo é usado para ajudar a esclarecer requisitos dos usuários com respeito ao sistema futuro. Uma prototipação também é exploratória quando se busca examinar uma variedade de opções de design de maneira a  evitar a escolha de uma abordagem específica não adequada. Com esses objetivos os desenvolvedores adquirem informações sobre o domínio, os usuário e tarefas. Os usuários podem emitir informações e sugestões mais precisas, tornando-se parceiro das decisões que envolvem o desenvolvimento. 
Experimental- é quando a prototipação foca aspectos técnicos do desenvolvimento, oferecendo aos desenvolvedores resultados experimentais para tomada de decisões de design e implementação. Um aspecto essencial é a viabilização de uma base de comunicação entre os usuários e desenvolvedores para soluções de problemas técnicos de viabilidade e usabilidade, dentre outros. As principais vantagens para os desenvolvedores são a verificação e validação das decisões tomadas e soluções apresentadas. 
Evolutiva - A prototipação pode ser aplicada de maneira bastante proveitosa num processo de reengenharia em organizações, para avaliar o impacto que a introdução de novas tecnologias pode trazer. Nesse caso o protótipo não é visto apenas como uma ferramenta em projetos individuais, mas como parte de um processo contínuo de evolução dos processos organizacionais. Os desenvolvedores não são mais os protagonistas da prototipação, mas consultores que trabalham em cooperação com os usuários no processo de reengenharia. 
Técnicas de prototipação
Do ponto de vista técnico, a prototipação pode ser conduzida segundo duas abordagens, relacionadas com técnicas específicas de construção. Experiências em desenvolvimento de software têm apontado inúmeras qualidades no design e implementação em diversas camadas. Essas camadas podem ir desde a interface de usuário à camadas mais básicas como uma base de dados e o sistema operacional. Dessa forma, podemos identificar duas formar de subdividir a prototipação. 
Prototipação horizontal: Apenas uma camada específica do sistema é construída. Por exemplo, a interface do usuário com suas janelas e widgets, ou camadas da aplicação como as funções para transação em BD. 
Prototipação vertical - Uma parte da funcionalidade do sistema é escolhida para ser implementada completamente. Esta técnica é apropriada quando aspectos da funcionalidade ainda estão em aberto. 
Um outro critério para se classificar protótipo é de acordo com o relacionamento entre o protótipo e o sistema final. Em certos casos, o protótipo serve apenas para propósitos de especificação do sistema final e não será usado como parte integrante do sistema final. Ele é jogado fora. Um outro caso, é quando o protótipo vai sendo incrementado e se torna parte integrante (building block) do sistema. Por fim, o protótipo pode ser construído apenas para a compreensão de certos problemas que envolvem determinados interesses. Não existe a intenção de transformá-lo num sistema. 
O Modelo de Transformação
O modelo de Transformação tem suas raízes na abordagem de métodos formais para o desenvolvimento de software. A ideia é que o desenvolvimento deve ser visto como uma sequencia de passos que gradualmente transforma uma especificação formal num programa. O passo inicial é transformar os requisitos informais numa especificação funcional formal e então transformada numa outra descrição formal mais detalhada, e assim, sucessivamente, até chegar no ponto em que se tenha componentes de programas que satisfaçam a especificação. Durante este processo de transformações sucessivas - chamado de otimização - as especificações formais produzidas podem ser executadas por um processador abstrato, permitindo uma verificação formal da sua validação antes mesmo que o programa venha a ser implementado. Antes de serem transformadas cada especificação formal deve ser verificada em relação às expectativas dos clientes e usuários. 
As transformações devem ser realizadas pelo engenheiro de software. A natureza formal da transformação possibilita a aplicação de verificações matemáticas como prova consistência e completude da especificação. As transformações podem ser realizadas de maneira automática por ferramentas que traduzem especificações formais mais abstratas em especificações mais detalhadas. 
Este modelo prevê que o engenheiro de software deve ter a sua disposição uma biblioteca de componentes reutilizáveis que satisfaça especificações formais. Na otimização, à medida que as especificações de mais baixo nível vão sendo obtidas verifica-se quais componentes da biblioteca implementam parte desta especificação. Um ambiente automatizado de desenvolvimento (uma ferramenta CASE - Computer Aided Software Engineering) pode auxiliar este processo armazenando o histórico de decisões dos engenheiros de software. 
Modelo em Espiral
O modelo em espiral foi proposto por Boehm em 1988 como forma de integrar os diversos modelos existentes à época, eliminando suas dificuldades e explorando seus pontos fortes. Este modelo foi desenvolvido para abranger as melhores características tanto do ciclo de vida clássico como da prototipação, acrescentando, ao mesmo tempo, um novo elemento - a análise de riscos - que falta a esses paradigmas. Entretanto a integração não se dá através da simples incorporação de características dos modelos anteriores. O modelo em espiral assume que o processo de desenvolvimento ocorre em ciclos, cada um contendo fases de avaliação e planejamento, onde a opção de abordagem para a próxima fase (ou ciclo) é determinada. Estas opções podem acomodar características de outros modelos. 
 
O modelo original em espiral organiza o desenvolvimento como um processo iterativo em que vários conjuntos de 4 fases se sucedem até a obtenção do sistema final. Um ciclo se inicia com a determinação de objetivos, alternativas e restrições (1º tarefa) onde ocorre o comprometimento dos envolvidos e o estabelecimento de uma estratégia para alcançar os objetivos. Na 2º tarefa, avaliação de alternativas, identificação e solução de riscos (execução de uma análise de risco). Pode-se utilizar a Prototipação para tratar riscos. Se o risco for considerado inaceitável, pode parar o projeto. Na 3º tarefa ocorre o desenvolvimento do produto. Neste quadrante pode-se considerar o modelo cascata. Na 4º tarefa o produto é avaliado e se prepara para iniciar um novo ciclo.
Variações do modelo espiral consideram entre três e seis tarefas ou sectores da espiral, que podem ser: 
Comunicação com o cliente; 
Planeamento; 
Análise de risco; 
Engenharia; 
Construção e liberação; 
Avaliação do cliente
O modelo espiral é atualmente a abordagem mais realística para desenvolvimento de software em grande escala, e usa uma abordagem que capacita a empresa que presta o serviço, e o cliente a entender e reagir aos riscos em cada etapa. Este tipo de modelo exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso, pode ser difícil convencer os clientes que uma abordagem evolutiva é controlável. 
Vantagens 
O modelo em espiral permite que ao longo de cada iteração se obtenham versões do sistema cada vez mais completas, recorrendo à prototipagem para reduzir os riscos. Este tipo de modelo permite a abordagem do refinamento seguido pelo modelo em cascata, mas que incorpora um enquadramento iterativo que reflete de uma forma bastante realística, o processo de desenvolvimento. 
Desvantagens 
Pode ser difícil convencer clientes de que a abordagem evolutiva é controlável. A abordagem deste tipo de modelo exige considerável experiência na avaliação dos riscos para o sucesso. É importante salientar que podem existir diferenças entre o protótipo e o sistema final. O protótipo pode não cumprir os requisitos de desempenho, pode ser incompleto, e pode refletir somente algumas facetas do sistema a desenvolver. O modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado, por isso é necessário o uso de técnicas específicas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.
Técnicas de 4º Geração
O paradigma Técnicas de Quarta Geração (4GT) da Engenharia de Software concentrasse na capacidade de se especificar software a uma máquina em um nível que esteja próximo à linguagem natural. O 4GT inicia-se com uma etapa de coleta de requisitos com o cliente descrevendo os requisitos,e estes são traduzidos num protótipo operacional. Em alguns casos o cliente pode não ter certeza do que é exigido, pode ser ambíguo ao especificar fatos e pode ser inviável especificar as informações de maneira que uma ferramenta 4GT possa receber. Para pequenas aplicações, talvez seja possível passar diretamente da etapa de coleta das exigências para a implementação, utilizando uma linguagem 4GL. Para transformar a implementação de uma 4GT num produto, o desenvolvedor deve realizar testes cuidadosos, desenvolver uma documentação significativa e executar todas as demais atividades de "transição" que também são exigidas em outros paradigmas da Engenharia de Software.
Ferramentas do ambiente de desenvolvimento de software de 4GL
O ambiente de desenvolvimento de software que sustenta o ciclo de vida de 4a geração inclui as ferramentas:
Linguagens não procedimentais para consulta de banco de dados
Geração de relatórios
Manipulação de dados
Interação e definição de telas
Geração de códigos
Capacidade gráfica de alto nível
Capacidade de planilhas eletrônicas
Atividades das Técnicas de 4a Geração
Obtenção dos Requisitos: o cliente descreve os requisitos os quais são traduzidos para um protótipo operacional:
o cliente pode estar inseguro quanto aos requisitos
o cliente pode ser incapaz de especificar as informações de um modo que uma ferramenta 4GL possa consumir
as 4GLs atuais não são sofisticadas suficientemente para acomodar a verdadeira "linguagem natural"
Estratégia de "Projeto": para pequenas aplicações é possível mover-se do passo de Obtenção dos Requisitos para o passo de Implementação usando uma Linguagem de 4G:
Para grandes projetos é necessário desenvolver uma estratégia de projeto. De outro modo ocorrerão os mesmos problemas encontrados quando se usa abordagem convencional (baixa qualidade) 
Implementação usando 4GL: os resultados desejados são representados de modo que haja geração automática de código. Deve existir uma estrutura de dados com informações relevantes e que seja acessível pela 4GL.
Teste: o desenvolvedor deve efetuar testes e desenvolver uma documentação significativa. O software desenvolvido deve ser construído de maneira que a manutenção possa ser efetuada prontamente.
Reengenharia de Software
Reestruturar ou reescrever todo ou parte de um sistema legado sem alterar a sua funcionalidade. Pode ser aplicável quando alguns, mas nem todos os sub-sistemas de um sistema maior exigem manutenção frequente. Reengenharia envolve um esforço adicional para torná-los mais fáceis de manter. O sistema pode ser reestruturado e redocumentado partindo-se do código existente.
Processo de reengenharia de software.
Quando deve ser aplicada a reengenharia de software:
Quando as mudanças de um sistema estão confinadas a uma parte do sistema, então faz a reengenharia deve ser aplicada.
Quando o suporte de hardware ou software se torna obsoleto.
Quando ferramentas de apoio à reestruturação estão disponíveis.
Quando o sistema não é fácil de ser mantido sendo, porém, de grande utilidade, ele deve ser reconstruído. Partindo-se do sistema existente (via código-fonte, interface ou ambiente), são abstraídas as suas funcionalidades e são construídos o modelo de análise e o projeto do software. Esse processo é denominado reengenharia de software.
Definição de Engenharia Reversa: Processo de exame e compreensão do software existente, para recapturar ou recriar o projeto e decifrar os requisitos atualmente implementados pelo sistema, apresentando-os em um nível mais alto de abstração. Por meio da engenharia reversa um software pode ser visualizado em diferentes níveis de abstração. Cada visualização abstrai características próprias da fase do ciclo de vida correspondente à abstração.
Engenharia Progressiva VERSUS Engenharia Reversa:
Engenharia Progressiva: Processo tradicional de engenharia de software, caracterizado pelas atividades progressivas do ciclo de vida, que partem de um alto nível de abstração, para um baixo nível de abstração.
Engenharia Reversa: O processo inverso a Engenharia Progressiva, caracterizado pelas atividades retroativas do ciclo de vida, que partem de um baixo nível de abstração para um alto nível de abstração.
Segundo Roger Pressman (PRESSMAN, 1995), Chikofsky e Cross (CHIKOFSKY; CROSS, 1990), o termo engenharia reversa tem suas origens na análise do hardware, onde a prática de “decifrar” projetos de produtos era mais comum. Uma empresa desmonta um hardware comercializado a fim de entender os “segredos” de projeto e manufatura, num esforço de melhorar seus próprios produtos, como também analisar os produtos dos concorrentes.
Rekoff (REKOFF, 1985) define a engenharia reversa como “o processo de desenvolvimento de um conjunto de especificações para um complexo sistema de hardware através de um metódico exame de exemplares deste sistema”. Ele descreve este processo como sendo conduzido por alguém que não seja o desenvolvedor original do sistema: “sem os benefícios de qualquer documentação original (...) com o propósito de criar um clone do sistema de hardware original...”.
Metodologia de desenvolvimento de Sistemas
As metodologias para desenvolvimento de sistemas foram aceitas no meio tecnológico devido à necessidade de uma padronização do processo de análise e desenvolvimento. Uma metodologia de desenvolvimento constitui-se de uma abordagem organizada para se atingir um objetivo, possível por meio do cumprimento de um conjunto de procedimentos preestabelecidos. Desta forma, o produto se torna o componente mais importante de todo o processo de desenvolvimento.
Diferença entre método e metodologia 
O método pode ser definido como o caminho pelo qual se atinge um objetivo, ou seja, o caminho ordenado para chegar a um fim. Metodologia consiste na análise do estudo e avaliação dos vários métodos disponíveis pela aprovação das técnicas que serão aplicadas. Pode-se definir também como o estudo dos métodos, especialmente, os da ciência. No ramo da informática pode-se dizer que é uma pesquisa de métodos de programação e de exploração dos computadores e meios informáticos.
A metodologia é o passo a passo para se chegar ao resultado desejado. Ela identifica as principais atividades a serem executadas e indica as pessoas envolvidas nas atividades e os papéis de cada uma. Geralmente descreve critérios de entrada/saída e pontos de conferência para decisões. Já o método é uma abordagem técnica com um modelo para se realizar uma ou mais tarefas. (OLIVEIRA, 1999) 
Uso de Ferramentas CASE
As Ferramentas CASE (Computer-Aided Software Engineering) constituiem uma categoria de software que tem por finalidade auxiliar as atividades de engenharia de software, o que envolve recursos para gerencia, análise de requisitos, modelagem, programação, testes e manutenção de software. 
Classificação de CASE
Não há um padrão definido para classificar as CASE, de um modo geral é possível agrupá-las em:
Upper CASE: também referenciadas como Back End, são as CASE destinadas a apoiar as etapas iniciais de criação dos sistemas: as fases de planejamento, análise e projeto do sistema.
Lower CASE: também referenciadas como Front End, são as CASE destinadas a apoiar a codificação testes e manutenção da aplicação.
I-CASE: também referenciadas como Integrated CASE, são as CASE destinadas a apoiar todo o ciclo de vida do software, desde os requisitos do sistema até o controle final da qualidade do produto gerado, o software.
As Ferramentas CASE podem ainda ser agrupadas nas seguintes categorias: 
Modelação de processos de negócio
Modelação de análise e desenho do sistema
Desenho da base de dados
Programação de aplicações
Gestão de alterações no software
Testes
Orientadas para a Gestão de Projetos
Vantagens do uso de CASE
Dentre as principais vantagens do uso de ferramentas CASE podemos destacar:
Qualidade no produto final
Produtividade
Agilizar o tempo para tomada de decisão
Menor quantidade decódigos de programação
Melhoria e redução de custos na manutenção
RAD (Rapid Application Development): Desenvolvimento Rápido de Aplicativos, é uma ferramenta que visa a maior produtividade dos desenvolvedores. As ferramentas RAD devem propiciar um desenvolvimento de software interativo e incremental que enfatiza um ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias). O termo foi registrado por James Martin em 1991 e tem substituído gradativamente o termo de prototipação rápida que já foi muito utilizada no passado. Estas ferramentas empregam técnicas de quarta geração, trabalham com a reutilização de componentes de programa existentes quando possível, ou criam componentes reusáveis. Dentre as vantagens de se empregar uma rad temos:
Permite o desenvolvimento rápido e/ou a prototipagem de aplicações;
Enfatiza um ciclo de desenvolvimento extremamente curto (entre 60 e 100 dias);
Cada função principal pode ser direcionada para a uma equipe RAD separada e então integrada a formar um todo;
Criação e reutilização de componentes;
Usado principalmente para aplicações de sistemas de informações;
Grande redução de codificação manual;
Provável custo reduzido;
Aparência padronizada (As APIs e outros componentes reutilizáveis permitem uma aparencia consistente).
Exemplos de RAD
DELPHI, VISUAL BASIC, wxDesigner, Anubis PHP, IDE’s RAD (Eclipse, NetBeans)
Um comportamento de RAD no Delphi é o fato de ao se colocar um botão num formulário, ele automaticamente acrescenta, na clausula "uses", a library que contém o objeto Tbutton e cria um Tbutton. Caso o objeto TButton possuir dependências de outras classes, o Delphi se encarrega de encontra-las e incluí-las automaticamente.
Framework: é um conjunto de módulos que colaboram para realizar uma responsabilidade para um domínio de um sub-sistema da aplicação. Framework de software compreende de um conjunto de módulos, implementadas em uma linguagem específica, usadas para auxiliar o desenvolvimento de software de forma que os mesmos são reaproveitados. O framework atua onde há funcionalidades em comum a várias aplicações, porém para isso as aplicações devem ter algo razoavelmente grande em comum para que o mesmo possa atingir a várias aplicações. Um framework deve:
Ser reusável
Bem documentado 
Fácil de usar 
Conter funcionalidade abstrata (sem implementação) que deve ser completada 
Deve ser de uso seguro não permitindo que seus modulos sejam destruídos pelo usuário(desenvolvedor) 
Exemplos de Framework: miolo, microsoft.net, Zend, Spring, JUnit
Bibliografia
PRESSMAN, R. S. Engenharia de Software. 3.ed. São Paulo: Pearson Makron Books, 1995.
CHIKOFSKY, E. J.; CROSS, J. H. Reverse Engineering and Design Recovery: a taxonomy. IEEE Softw., Los Alamitos, CA, USA, v.7, n.1, p.13–17, 1990.
REKOFF, M. On reverse engineering. IEEE Transactions on Systems, Man and Cybernetics, [S.l.], v.3/4, p.244–252, 1985.
OLIVEIRA, Jayr Figueiredo de. Metodologia para desenvolvimento de Projeto de Sistemas. 4ª edição, São Paulo: Érica, 1999