UNIVERSIDADE PAULISTA (UNIP)

INSTITUTO DE CIÊNCIAS EXATAS E TECNOLÓGICAS (ICET)

DISCIPLINA: ENGENHARIA DE SOFTWARE

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:

1. Os projetos reais raramente seguem o fluxo sequencial que o modelo propõe.

2. Muitas vezes é difícil para o cliente declarar todas as exigências explicitamente logo no
início.
3. 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

1. Obtenção dos Requisitos: o cliente descreve os requisitos os quais são traduzidos para um
protótipo operacional:
a. o cliente pode estar inseguro quanto aos requisitos
b. o cliente pode ser incapaz de especificar as informações de um modo que uma
ferramenta 4GL possa consumir
c. as 4GLs atuais não são sofisticadas suficientemente para acomodar a verdadeira
"linguagem natural"
 2. 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:
a. 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)
3. 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.
4. 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 de có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