ilovepdf_merged

Prévia do material em texto

ENGENHARIA DE 
SOFTWARE 
Aline Zanin
Conceitos da Engenharia 
de Software
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Reconhecer o histórico e os conceitos fundamentais da Engenharia
de Software.
 � Analisar a evolução do desenvolvimento de software.
 � Identificar a importância da Engenharia de Software.
Introdução
Por muitos anos a Engenharia de Software foi utilizada com o objetivo 
de criar software de qualidade dentro dos custos e dos prazos estimados 
pelo cliente, evitando desperdícios de tempo, esforços, direções erradas e 
atrasos. A criação de software foi subestimada e realizada sem nenhuma 
metodologia, gerando erros em sistemas, como problemas de cálculos 
e perdas financeiras e de tempo. Nesse período, podemos dizer 
que houve a crise do software. Com isso, em 1967, a Organização do 
Tratado do Atlântico Norte (OTAN) designou o termo Engenharia de 
Software para adequar o processo de desenvolvimento de software com 
metodologias já utilizadas em outras Engenharias. Uma série de 
metodologias e técnicas passaram a ser utilizadas antes, durante e 
depois da criação de software. Dados históricos apontam que houve 
uma diminuição brutal nos problemas em software após a adoção 
dessas metodologias, fazendo com que a indústria de software 
pudesse entregar sistemas com maior qualidade, em menos tempo e 
com custos reduzidos de manutenção. 
Neste capítulo, você irá adquirir conhecimentos fundamentais 
para avançar no aprendizado sobre Engenharia de Software. Iremos 
abordar inicialmente conceitos básicos sobre o que é essa Engenharia, 
sua história e a importância na indústria.
Histórico e conceitos fundamentais da 
Engenharia de Software
A Engenharia de Software é uma disciplina da Engenharia, mais especifica-
mente da Ciência da Computação, que estuda todos os processos envolvidos 
no desenvolvimento de software, uma atividade complexa que envolve a rea-
lização conjunta de diversas atividades distintas, as quais exigem habilidades 
multidisciplinares e, por consequência, trabalho colaborativo de um grande 
grupo de profissionais (SOMMERVILLE, 2011).
A Engenharia de Software é uma área de grande importância, uma vez 
que as pessoas e a sociedade como um todo estão a cada dia mais dependentes 
de software. Por isso, faz-se necessário que seja produzido software mais 
confiável e de forma mais rápida a cada dia. Além disso, para as empresas 
desenvolvedoras de sistemas, geralmente é mais barato, a longo prazo, usar 
métodos e técnicas da Engenharia de Software para o desenvolvimento de 
sistemas do que desenvolver os sistemas sem documentação e estruturação, 
uma vez que, desta forma, é desestruturada e dificultada a manutenção do 
software (SOMMERVILLE, 2011).
Contudo, esta disciplina nem sempre foi alvo de atenção dos profissionais 
de Tecnologia da Informação. Por muito tempo, o desenvolvimento de sistemas 
foi realizado sem atenção a processos, metodologias e estruturas organizacio-
nais no que diz respeito a tarefas, atividades e responsabilidades. Essa falta 
de controle sobre os processos fez com que, muitas vezes, o software fosse 
entregue aos clientes sem a devida qualidade e com grande número de erros, 
como problemas de cálculos e perdas financeiras e de tempo. Nesse período, 
podemos dizer que houve a crise do software. Com isso, em 1967, a OTAN 
designou o termo Engenharia de Software para adequar o processo de desen-
volvimento de software com metodologias já utilizadas em outras engenharias.
A partir desse momento, os profissionais e as empresas de Tecnologia 
da Informação passaram a preocupar-se mais com os diversos setores que 
envolvem o desenvolvimento de sistemas, como análise de requisitos, análise 
de sistemas, desenvolvimento, testes e implantação. Neste contexto, derivaram 
diversas metodologias, métodos e processos para auxiliar e guiar o trabalho 
de cada um desses segmentos. 
Conceitos da Engenharia de Software2
Evolução do desenvolvimento de software
O desenvolvimento de software, bem como outras Ciências, empregou diversas 
mudanças e adaptações para melhorar, facilitar e adaptar-se ao cotidiano dos 
profissionais que realizam esse trabalho. As principais evoluções no desen-
volvimento de software podem ser classificadas em dois grandes grupos: 
mudanças processuais e mudanças tecnológicas.
Mudanças tecnológicas
Embora atualmente, quando se fala em software, sejamos remetidos a lembrar 
de computadores modernos, smartphones, tablets, etc., o desenvolvimento de 
software começou muito antes desses dispositivos serem criados, sendo pro-
gramado por volta de 1725, em cartões perfurados. Posteriormente, surgiram 
as primeiras linguagens de programação, tais quais as que existem hoje, sendo 
elas FORTRAN (1955), List Processor (LISP) e Common Business Oriented 
Language (COBOL). Posteriormente, surgiram linguagens de programação de 
alto nível, isto é, que se aproximam mais da linguagem humana, são exemplos: 
Java, JavaScript, Visual Basic, Object Pascal e PHP (PACIEVITCH, 2017).
Junto com as linguagens de programação, foram sendo criados paradigmas 
para o desenvolvimento de sistemas. Um paradigma nada mais é do que a 
forma como um sistema é construído e seu desenvolvimento é organizado. 
Os paradigmas mais conhecidos são o paradigma estruturado e o paradigma 
orientado a objetos, sendo o paradigma orientado a objetos o mais utilizado 
atualmente. A programação orientada a objetos é um paradigma em que o 
software é construído considerando que tudo o que é inserido no programa é um 
objeto e que esse objeto pertence a uma classe e tem características (atributos) 
específicas sobre as quais podem ser feitas ações (métodos). Por outro lado, 
um princípio básico da programação estruturada é que um programa pode 
ser dividido em três partes que se interligam, sendo elas sequência, seleção e 
iteração (ABÍLIO, 2017). Na sequência, o código do programa é criado para 
ser executado de forma sequencial, seguindo estritamente a ordem na qual 
foi programado. Na seleção, o programa encontra locais onde pode seguir um 
ou mais caminhos distintos. Na interação, é permitido ao programa executar 
diversas vezes o mesmo trecho de código. 
3Conceitos da Engenharia de Software
 � Ao programar uma calculadora, quando cria-se um programa e o único fluxo 
que este pode seguir é receber dois números, somar esses números e mostrar o 
resultado, faz-se um programa utilizando apenas sequência.
 � Quando se insere neste programa a opção de selecionar se deve somar ou subtrair 
os números, se está programando uma seleção.
 � Quando, ao final do cálculo, pergunta-se para o usuário se deseja fazer novamente, 
se está programando uma interação.
Mudanças de processo
No desenvolvimento de sistemas, além das mudanças tecnológicas, foram 
ocorrendo mudanças na forma como as empresas se organizam e estruturam 
o trabalho. A forma tradicional de desenvolvimento de sistemas foi a primeira 
a ser criada, empregando o ciclo de vida em estrutura de cascata (1970), na 
qual as etapas são executadas de forma sequencial, sem que seja possível 
retornar de uma etapa posterior para uma etapa anterior.
Figura 1. Modelo Cascata 
Fonte: Sommerville (2011, p. 20).
De�nição
de requisitos
Projeto de sistema
e software
Implentação
e teste unitário
Integração e
teste de sistema
Operação e
manutenção
Conceitos da Engenharia de Software4
Posteriormente, falou-se em desenvolvimento iterativo e incremental. 
Nesse modelo, implementa-se pequenas partes entregáveis do software para 
que o cliente tenha um feedback mais rápido sobre o produto que está sendo 
desenvolvimento.
Figura 2. Entrega Incremental.
Fonte: Sommerville (2011, p. 31).
De�nição esboço
de requisitos
Atribuir requisitos
aos incrementos
Validar
incrementos
Integrar
incrementos
Implantar
incrementos
Validar
sistema
Sistema
incompleto?
Sistema
completo?
Sistema
�nal
Projetar arquitetura
de sistema
Desenvolver incrementos
de sistema
O modelo emespiral se assemelha muito ao modelo iterativo e incremen-
tal, uma vez que ele também considera pequenas entregas de software e a 
execução de todas as etapas espiralmente (várias vezes). Contudo, o ciclo de 
vida espiral considera a presença explícita da análise de riscos como uma das 
etapas de cada iteração. Nesse processo em espiral, o ciclo de vida do software 
é representado como uma espiral em que a volta na espiral representa uma fase 
do processo de software, sendo que a volta mais interna pode preocupar-se 
com a viabilidade do sistema, o ciclo seguinte, com definição de requisitos, 
o seguinte, com o projeto do sistema, e assim por diante.
5Conceitos da Engenharia de Software
Figura 3. Modelo Espiral.
Fonte: Sommerville (2011, p. 33).
Determinar objetivos,
alternativas e restrições
Análise
de riscos
Protótipo
operacionalProtótipo 3
Protótipo 2
Protó-
tipo 1
Simulações, modelos, benchmarks
Requisitos
de S/W Projeto de
produto Projeto 
detalhado
Código
Teste unitário
Teste de
integraçãoTeste de
aceitação
Projeto 
V&V
Operação
Validação 
de requisitos
Conceito de 
operação
Plano de requisitos
Plano de ciclo de vida
Plano de 
desenvolvimento
Planejar próxima fase
Plano de integração 
e testes
Análise
de riscos
Análise
de riscos
Análise
de riscos
Avalir alternativas,
identi�car, resolver riscos
Desenvolver e veri�car próximo
nível do produto
Revisão
No ano de 2001, um grupo de profissionais de tecnologia da informação 
lançou um documento chamado Manifesto Ágil para o Desenvolvimento de 
Sistemas. Deste então popularizaram-se os métodos ágeis de desenvolvimento 
de sistemas, sendo os mais conhecidos o método Scrun e o método XP. Todos 
eles têm em comum a aplicação dos valores propostos pelo Manifesto Ágil 
para o Desenvolvimento de Sistemas, sendo eles: indivíduos e interações são 
mais que processos e ferramentas, software em funcionamento é mais que 
documentação abrangente, colaboração com o cliente é mais que negociação 
de contratos e respostas a mudanças são mais que seguir um plano (BECK 
et al., 2001).
Todos esses ciclos de vida, somados aos Métodos Ágeis de Desenvolvimento 
de Sistemas, apresentaram estrutura e organização maiores para o processo de 
desenvolvimento de sistemas, propiciando melhoria da comunicação entre os 
envolvidos no processo, seja entre os próprios profissionais de Tecnologia da 
Informação ou destes com o cliente. Com a adoção de processos e a atenção às 
evoluções tecnológicas, buscando sempre acompanhar aquilo que o mercado 
Conceitos da Engenharia de Software6
tem de melhor para oferecer, pode-se atingir maior excelência nos produtos 
entregues e atender melhor às necessidades do cliente.
Importância da Engenharia de Software
Conforme supracitado, a Engenharia de Software é uma disciplina de Enge-
nharia cujo foco está em todos os aspectos da produção de software, desde 
os estágios iniciais da especificação do sistema até a sua manutenção, quando 
o sistema já está sendo usado (SOMMERVILLE, 2011). Neste contexto, é
clara a importância fundamental da Engenharia de Software, uma vez que,
se o processo de desenvolvimento de sistemas envolve diversas atividades
distintas e a Engenharia de Software é a disciplina que preocupa-se em estudar 
e monitorar o bom andamento de todas essas atividades e a integração entre
elas, é trivial notar que é baseado na Engenharia de Software o sucesso de
um projeto no que tange a sua organização.
Engenharia de Software envolve planejamento. Planejamento diz respeito 
também a pessoas e cronograma de trabalho. Pessoas porque divide as respon-
sabilidades, de forma individual ou coletiva. Cronograma porque conforme 
o planejamento é que os gestores têm a possibilidade de mensurar o tempo
necessário para o desenvolvimento de cada projeto. Engenharia de Software
envolve também a preocupação com a qualidade do produto. Qualidade, neste
contexto, não se refere apenas à entrega de produtos em funcionamento, mas
também ao atendimento das necessidades do cliente, e, por isso, a área da
Engenharia de Software, que trata de engenharia de requisitos ou análise de
requisitos, tem importância fundamental, na medida em que é por meio dela
que as equipes de desenvolvimento recebem a expectativa do cliente sobre o
produto que está sendo desenvolvido para buscar atendê-la.
Além disso, na fase de desenvolvimento da programação em si, a Enge-
nharia de Software se faz presente, uma vez que a escolha do processo ideal 
irá influenciar diretamente no trabalho cotidiano de todos os envolvidos, 
incluindo a programação. Esse fator ganha relevância ainda maior em times 
que trabalham em horários distintos ou locais geograficamente distribuídos.
Uma vez entregue o software para o cliente, a Engenharia de Software 
tem sua importância revelada no momento de realizar a manutenção nesse 
software. Isto porque, se o sistema tiver sido corretamente planejado, o código 
do sistema tende a estar mais limpo e com menos defeitos. Isso irá causar 
menos manutenção e facilitar as manutenções que precisam ser realizadas.
7Conceitos da Engenharia de Software
Conceitos da Engenharia de Software8
ABÍLIO, I. Programação orientada a objetos versus programação estruturada. Disponí-
vel em: <http://www.devmedia.com.br/programacao-orientada-a-objetos-versus-
-programacao-estruturada/32813>. Acesso em: 17 ago. 2017.
BECK, K. et al. Manifesto for agile software development. c2001. Disponível em:<http://
agilemanifesto.org/>. Acesso em: 17 ago. 2017.
PACIEVITCH, Y. História da programação. Disponível em: <http://www.infoescola.com/
informatica/historia-da-programacao>. Acesso em: 17 ago. 2017.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
Leituras recomendadas
ENDEAVOR BRASIL. PDCA: a prática levando sua gestão à perfeição. 2015. Disponível 
em: <https://endeavor.org.br/pdca/>. Acesso em: 4 nov. 2016.
PEQUENO, C. N.; CARVALHO, M. G. F.; FONTES, V. M. Redução do consumo de produto 
químico utilizado em uma linha de produção de uma indústria de pneus. 2015. Trabalho 
de Conclusão de Curso (Graduação em Engenharia de Produção)–Universidade do 
Estado do Rio de Janeiro, Rio de Janeiro, 2015.
REY, B. Como fazer um brainstorming eficiente. 2013. Disponível em: <http://exame.abril.
com.br/carreira/como-fazer-um-brainstorming-eficiente/>. Acesso em: 4 nov. 2016.
RODRIGUES, S. Crise: perigo, oportunidade e… papo furado. 2013. Disponível em: 
<http://veja.abril.com.br/blog/sobre-palavras/lendo-a-lenda/crise-perigo-oportu-
nidade-e-papo-furado/>. Acesso em: 4 nov. 2016.
SILVA, M. D. L. et al. Gestão da produção: estudo sobre a gestão da manutenção na 
geração de energia e vapor utilizando caldeiras de uma indústria. In: ENCONTRO 
PARAENSE DE ENGENHARIA DE PRODUÇÃO, 7., 2016, Belém. Anais... Belém: [s.n.], 2016.
SLACK, N. et al. Gerenciamento de operações e de processos: princípios e práticas de 
impacto estratégico. 2. ed. Porto Alegre: Bookman, 2013.
SOUZA, T. de J. F. et al. Proposta de melhoria do processo de uma fábrica de polpas 
por meio da metodologia de análise e solução de problemas. In: ENCONTRO NACIO-
NAL DE ENGENHARIA DE PRODUÇÃO, 35., 2015, Fortaleza. Anais... Fortaleza: ABEPRO, 
2015. Disponível em: <http://www.abepro.org.br/biblioteca/TN_STP_207_228_27341.
pdf>. Acesso em: 4 nov. 2016. 
esaito
Retângulo
Conteúdo:
ENGENHARIA 
DE SOFTWARE
Aline Zanin
Izabelly Soares 
de Morais
Revisão técnica:
Jeferson Faleiro Leon
Desenvolvimento de Sistemas 
Especialista em Formação Pedagógica de Professores
Catalogação na publicação: Karin Lorien Menoncin CRB-10/2147
M827e Morais, Izabelly Soares de.
 Engenharia de software [recurso eletrônico] / Izabelly
 Soares de Morais, Aline Zanin ; revisão técnica : Jeferson
 Faleiro Leon. – Porto Alegre : SAGAH, 2017.
 
 ISBN 978-85-9502-253-9
 Engenharia. 2. Engenharia de software auxiliada por 
 computador. I. Zanin, Aline.II. Título.
 
CDU 004.41
Modelo de análise 
de software (análise 
estruturada)
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Identificar os objetivos da análise estruturada. 
 � Compreender os principais elementos de modelagem (diagrama de 
fluxo de dados e dicionário de dados). 
 � Descrever as vantagens e desvantagens desse modelo.
Introdução
A análise estruturada é um dos métodos utilizados e presentes nas ca-
madas da Engenharia de Software. As ferramentas de análise estruturada 
permitem que um profissional de software crie modelos de dados, mo-
delos de fluxos e modelos comportamentais para possibilitar a análise 
de consistência, a continuidade, a fácil edição e a extensão. 
Os modelos criados, empregando tais ferramentas, fornecem ao en-
genheiro de software uma visão da representação de análise e podem 
ajudar a eliminar erros antes que se propaguem pelo projeto ou, pior 
ainda, na própria implementação. 
A análise estruturada considera os dados e os processos que transfor-
mam os dados como entidades separadas na modelagem de um sistema. 
Os objetos de dados são modelados de maneira a definir seus atributos 
e relações. Processos que manipulam objetos de dados são modelados 
para mostrar como transformam os dados à medida que objetos de 
dados fluem por meio do sistema.
Neste capítulo, você vai adquirir conhecimentos fundamentais para 
avançar no aprendizado sobre análise estruturada. Vai ver também os 
principais elementos de modelagem e algumas vantagens e desvanta-
gens desse modelo.
Engenharia de software aplicada à análise 
estruturada de sistemas
A Engenharia de Software nos traz metodologias que auxiliam no processo de 
desenvolvimento de um software, porém, só começou a ser vista como algo 
colaborativo durante este processo no início da década de 1970. Foi entre as 
décadas de 1970 e 1980 que ocorreram grandes progressos nas técnicas que 
já estavam sendo utilizados anteriormente.
Um acontecimento muito relevante para o contexto computacional e do 
desenvolvimento de software foi o surgimento de um paradigma utilizado na 
análise de sistemas (que trazem um conjunto de elementos, que juntos têm 
o intuito de atingir algum propósito ou solucionar algum problema), que, 
inicialmente, foi definido como clássico, porém, posteriormente, passou a ser 
chamado também de estruturado. 
De acordo com Schach (2010, p. 40), uma das principais razões para o su-
cesso limitado do paradigma clássico foi que as técnicas clássicas são orientadas 
a operações ou orientadas a atributos (dados), mas não a ambos ao mesmo 
tempo. Os componentes básicos de um produto de software são as operações do 
produto e os atributos sobre os quais essas operações agem. Algumas técnicas 
clássicas, quanto à análise de fluxo de dados, são orientadas a operações, 
ou seja, tais técnicas se concentram nas operações do produto; os atributos 
ficam em segundo plano. Diferentemente, técnicas como o desenvolvimento 
de sistemas são orientadas a atributos. A ênfase, nesse caso, é nos atributos; 
as operações que atuam sobre os atributos são menos significativas.
 Ainda sob a ótica do autor, esses atributos devem ser apresentados de forma 
explícita, assim como os principais objetivos e funcionalidades do sistema. 
Dessa forma, Schach (2010, p. 351) diz que 
“um documento de especificação deve satisfazer a duas exigências mutuamente 
contraditórias. De um lado, esse documento deve ser claro e inteligível para 
o cliente, que, provavelmente, não é um especialista em informática. [...] De 
outro lado, o documento de especificação deve ser completo e detalhado, pois é 
praticamente a única fonte de informações disponível para elaborar o projeto”. 
Modelo de análise de software (análise estruturada)2
A análise estruturada traz uma sequência de desenvolvimento, ou seja, 
uma fase que tanto depende dos resultados obtidos em suas fases anteriores 
quanto afeta as fases posteriores. Em razão da utilização de uma metodologia 
disciplinada, que exige certa sistematização de etapas e até do uso de técni-
cas, faz-se necessária uma boa comunicação, clara e concisa, entre todos os 
envolvidos no projeto. Portanto, podemos concluir que 
“compõe-se de um conjunto de técnicas e ferramentas, em constante evolução. 
Seu conceito fundamental é a construção de um modelo lógico (não físico) de 
um sistema, utilizando técnicas gráficas capazes de levar usuários, analistas 
e projetistas a formarem um quadro claro e geral do sistema e de como suas 
partes se encaixam para atender às necessidades daquele que dele precisam. 
Antes do desenvolvimento dessas ferramentas de Análise Estruturada de 
Sistemas, todos os detalhes da implementação física eram perdidos” (GANE; 
SARSON, 1985). 
A Figura 1 a seguir traz alguns símbolos criados por Gane e Sarson para 
a realização da análise estruturada de software. Esta notação é vista como 
uma das mais utilizadas na prática da análise estruturada.
Figura 1. Os símbolos da análise de sistemas 
estruturada de Gane e Sarson.
Fonte: Schach (2010, p. 356).
3Modelo de análise de software (análise estruturada)
Para utilizar esse tipo de análise, devemos inicialmente determinar as 
necessidades do sistema, para que, depois, o fluxo de dados lógico determine 
“o que” deverá ser feito e o fluxo de dados físicos determine “como” será 
realizado. A representação gráfica facilita a visualização de todo o sistema, 
tanto para a equipe de desenvolvimento quanto para o cliente, que geralmente 
é leigo nos assuntos que norteiam o ciclo de desenvolvimento de um sistema 
computacional. Para isso, trataremos no próximo tópico sobre os principais 
elementos de modelagem utilizados neste modelo de análise.
O uso de elementos gráficos para especificar software foi uma técnica importante dos 
anos 1970. Três técnicas que utilizam elementos gráficos tornaram-se particularmente 
populares: as técnicas de DeMarco (1978), Gane e Sarson (1979) e Yourdon e Constantine 
(1985). Todas elas são igualmente satisfatórias e, basicamente, equivalentes (SCRACH, 
2010).
Elementos de modelagem
Um sistema computacional tem três estágios básicos: entrada, processamento 
e saída de dados. Para isso, o uso de uma análise de software estruturada 
requer que haja o estudo da viabilidade do projeto e a análise e as especifi-
cações dos requisitos e do projeto, para que possa ocorrer a implementação, 
os testes e a manutenção do sistema que será desenvolvido. Um elemento 
ligado à modelagem que podemos destacar é o uso dos gráficos, que trazem 
simbologias conceituais e que seguem uma sequência lógica de execução, 
permitindo que tanto os clientes quanto a equipe desenvolvedora compreenda 
as especificações do sistema.
As metodologias que utilizam este princípio foram desenvolvidas para 
auxiliar os desenvolvedores neste processo. Para isso, diversas ferramentas 
e metodologias foram predefinidas. Selecionamos aqui o diagrama de fluxo 
de dados (DFD) e o dicionário de dados (DD).
Modelo de análise de software (análise estruturada)4
Diagrama de fluxo de dados (DFD)
O diagrama de fluxo de dados (DFD), assim como os demais diagramas, tem 
como função principal expor informações vistas antes como abstratas, tais 
como os processos que compõem o sistema. É visto como a principal ferramenta 
utilizada para a análise estruturada, pois deixa em evidência todo o fluxo de 
entrada e saída de dados. 
Dessa forma, este tipo de diagrama “é construído identificando-se os 
fluxos de dados contidos no documento de levantamento de necessidades ou 
no protótipo rápido. Cada fluxo de dados inicia e termina em uma origem, um 
destino de dados (representado por um quadrado duplo), ou um repositório 
de dados (representado por um retângulo com um lado aberto). Os dados são 
transformados por um ou mais processos (representados por um retângulo com 
cantos arredondados). A cada refinamento gradual sucessivo é acrescentado um 
novo fluxo de dados ao DFD, ou um fluxo de dados existenteé refinado pelo 
acréscimo de outros detalhes” (SCHACH, 2010). Esses recursos gráficos podem 
ser visualizados na Figura 1, mostrada anteriormente, na qual os símbolos da 
análise de sistemas estruturada propostos por Gane e Sarson foram expostos.
Conforme Oliveira (2011), os autores Yourdon e Constantine (1985) apre-
sentam, em sua obra, alguns conceitos sobre os componentes do diagrama 
de fluxo de dados. Mais tarde, outros autores acrescentaram mais algumas 
representações gráficas e que são retratadas a seguir no Quadro 1.
Componentes do DFD Funções Regras
Bolha de processos Representa um 
processo, uma 
atividade ou 
uma função. É 
o componente 
ativo que realiza 
a transformação 
no sistema. 
- Todo nome de processo 
deve indicar uma ação a ser 
feita, ou seja, deve conter 
um verbo infinitivo mais um 
complemento. Exemplo: 
emitir cobrança, gerar 
relatório, cadastrar cliente; 
- Todo processo deve estar 
devidamente numerado, 
levando em consideração 
o número e o nível em 
que ele se encontra.
Quadro 1. Componentes gráfico do diagrama de fluxos de dados.
(Continua)
5Modelo de análise de software (análise estruturada)
Componentes do DFD Funções Regras
Processos São as várias 
atividades 
realizadas no 
sistema.
Deve conter:
- Identificação: é um 
número atribuído ao 
processo, exclusivamente 
para identificá-lo, não 
tendo, portanto, outro 
significado. Geralmente, 
esses números são 
colocados da esquerda 
para a direita no diagrama 
de fluxo de informações; 
- Descrição: é uma frase 
imperativa, formada por 
um verbo referente a uma 
ação (registro, controle, 
preencha, etc.), seguido 
por um objeto. Exemplo: 
“remeta pagamento atraso”; 
- Localização física: é 
o nome da unidade 
organizacional responsável 
pela atividade, no caso de o 
sistema ser implementado 
(DUQUE DE CAXIAS, 2017). 
Fluxo de Dados Representa os 
insumos ou 
produtos dos 
processos, ou seja, 
representa dados 
trafegando entre 
processos ou 
entre processos e 
o mundo externo. 
As setas indicam 
o sentido do 
fluxo, e devem 
vir com o nome 
do fluxo ao qual 
estão associadas.
- Todo fluxo de dados 
deve ter nome;
- Fluxo de dados não 
tem ação, somente 
representam os dados;
- Não podem existir 
nomes repetidos de 
fluxo de dados.
Quadro 1. Componentes gráfico do diagrama de fluxos de dados.
(Continuação)
(Continua)
Modelo de análise de software (análise estruturada)6
(Continuação)
Componentes do DFD Funções Regras
Entidade Externa Representa o 
processo de 
entrada ou 
recebimento de 
dados, que são 
denominados 
respectivamente 
de fontes e 
terminadores.
- Entidade externa 
não se comunica com 
outra entidade;
- Entidade externa não 
acessa depósito de dados.
Depósito de Dados 
ou Arquivos
Elementos que 
representam um 
arquivo ou um 
local onde as 
informações são 
depositadas para 
uso posterior 
por qualquer 
processo dentro 
do escopo do 
sistema. Exemplo: 
pastas, ficheiros, 
dentre outros.
- Não podem existir 
depósitos de dados 
somente com entrada 
ou somente com saídas 
dentro do sistema.
Convenções Adicionais É utilizado quando 
o cruzamento 
de linhas de 
fluxos deve ser 
minimizado e/
ou quando o 
cruzamento 
for inevitável 
(TEIXEIRA, 
2003, p. 69).
Quadro 1. Componentes gráfico do diagrama de fluxos de dados.
7Modelo de análise de software (análise estruturada)
Algumas boas práticas são indicadas para que um diagrama de fluxo de 
dados seja concebido de maneira correta, no sentido de que todas as informa-
ções inseridas irão retornar o resultado esperado. Para isso, Teixeira (2003, 
p. 72), destacam-se as seguintes diretrizes:
 � escolher nomes significativos para os processos, fluxos, depósitos e 
terminadores.
 � numerar os processos.
 � produzir o DFD seguindo a organização visual de seus elementos.
 � evitar trazer complexidade ao DFD.
 � verificar a consistência interna do DFD e de seu relacionamento com 
outros DFDs.
Dicionário de dados (DD)
A concepção de um software envolve diversas operações. Para isso, os recur-
sos tecnológicos nos auxiliam durante esse processo. Além de metodologias, 
existem diversas formas práticas de se desenvolver algo. Para tanto, podemos 
fazer uso das chamadas ferramentas “CASE”, que nada mais são do que a uti-
lização do computador como recurso para aplicação de práticas da Engenharia.
Uma importante categoria das ferramentas CASE são os dicionários de 
dados (DD), uma lista informatizada de todos os dados definidos no produto. 
Um produto grande contém dezenas (talvez centenas) de milhares de dados, 
e o computador é ideal para armazenar informações, como nomes e tipos de 
variáveis e o local em que cada uma delas é definida, bem como nomes de 
procedimento e de parâmetros e seus tipos. Uma parte importante de toda a 
entrada de um dicionário de dados é a descrição do item 
O poder dos dicionários de dados pode ser ampliado combinando-o com 
um verificador de consistência, uma ferramenta para verificar se cada dado no 
documento de especificações está refletido no projeto e, ao contrário, se cada 
dado no projeto foi definido no documento de especificações O dicionário de 
dados pode ser visto como um parâmetro que traz informações sobre todos os 
elementos do sistema. Para isso, ele possui algumas informações relevantes, 
como os dados elementares, que estão envolvidos no contexto do usuário, por 
exemplo, quando vamos preencher o endereço de um usuário, geralmente essa 
informação requer diversos dados, ou seja, é um elemento de dados composto, 
pois para ficar completo temos que inserir, além do nome da rua ou avenida, 
o número, o CEP e até outras informações (SCHACH, 2010).
Modelo de análise de software (análise estruturada)8
Com o uso do DD, podemos detalhar os seguintes itens: depósito de dados, 
fluxo de dados e dados que são elementares e constituem fluxos e depósito de 
dados. De acordo com o material disponibilizado pela Universidade Estadual 
Paulista (UNESP, 2015), cada entrada é constituída por um identificador e sua 
respectiva descrição. Esta descrição deve ser composta por: 
 � O seu significado;
 � O seu conteúdo (utilizado apenas em dados compostos);
 � Os valores permitidos e as unidades (utilizados apenas para dados 
elementares);
 � A chave primária (apenas para depósito de dados).
O material ainda traz a notação utilizada no dicionário de dados, que será 
apresentada no Quadro 2 a seguir:
UNESP, 2015.
Símbolo Significado
= é constituído por ou é definido por
+ e (conjunção ou concatenação)
( ) enquadram componentes opcionais
[ ] enquadram componentes que são 
utilizadas alternativamente
| separam componentes alternativas enquadradas por [ ] 
{ } enquadram componentes que se repetem 0 ou mais vezes
* * enquadram comentários
@ identifica a chave primária de um depósito
Quadro 2. Notação do dicionário de dados (DD).
A descrição de alguns dados elementares é necessária apenas quando as 
informações dos elementos de dados não ficam claras e podem gerar entendi-
mentos dúbios. O ideal é que o sistema retorne sempre mensagens confirmando 
se os procedimentos foram concluídos e/ou realizados com sucesso, como a 
9Modelo de análise de software (análise estruturada)
confirmação de que um cadastro foi finalizado. Geralmente, a descrição dos 
dados informa o modo correto de se preencher alguns campos. Um exemplo 
clássico é o CPF, que pode conter ou não os caracteres, como pontos e hífen. 
Dessa forma, deve haver uma sinalização informando como o usuário deve 
preencher este campo, ou seja, se é ou não para utilizar os caracteres ou apenas 
números para informar o CPF.
Os elementos de modelagem visam oferecer um suporte maior para a 
realização da análise estruturada de sistemas.
Além dos elementos da modelagem utilizados em uma análise estruturada de software, 
podemos citar também a existência dos fluxogramas, que também trazem represen-
tações gráficas ao processo de produção de um software. 
De acordo com Manzano (2012), a análise estruturada é uma ferramenta usada e 
desenvolvidapelos profissionais da área de análise de sistemas. Tem como finalidade 
descrever o fluxo de ação de um determinado trabalho lógico, seja manual ou mecânico, 
especificando os suportes usados para os dados e para as informações. Usa símbolos 
convencionais (norma ISO 5807:1985), permitindo poucas variações.
Vantagens e desvantagens da análise 
estruturada
De acordo com Schach (2010), entre as técnicas que formavam o paradigma 
clássico havia a análise de sistemas estruturada, a análise de fluxo de dados, a 
programação estruturada e os testes estruturados. Inicialmente, quando usadas, 
essas técnicas pareciam extremamente promissoras. Entretanto, à medida que 
o tempo foi passando, constatou-se que elas ficaram aquém do esperado em 
dois aspectos, os quais são expostos pelo autor a seguir:
1. Algumas vezes, as técnicas eram incapazes de lidar com o tamanho cada 
vez maior dos produtos de software, isto é, as técnicas clássicas eram 
adequadas para elaborar produtos de escala pequena (tipicamente com 
5 mil linhas de código) ou até mesmo produtos de escala média, com 
cerca de 50 mil linhas de código. Atualmente, entretanto, produtos de 
larga escala, com 500 mil linhas de código, são relativamente comuns. 
Modelo de análise de software (análise estruturada)10
Até mesmo produtos com 5 milhões ou mais de linhas de código não 
são considerados raros. Entretanto, as técnicas clássicas normalmente 
não conseguem ser ampliadas de forma a conseguir lidar com o desen-
volvimento dos produtos atuais de maior porte.
2. O paradigma clássico não estava à altura das expectativas iniciais 
durante a manutenção pós-entrega. Um importante agente propulsor 
do paradigma clássico há 30 anos foi que, em média, dois terços do 
orçamento para software eram destinados à manutenção pós-entrega. 
Infelizmente, o paradigma clássico não havia resolvido esse problema, 
várias organizações ainda despendem de 70% a 80% ou mais de seu 
tempo e esforços em manutenção pós-entrega (YOURDON, 1992; 
HATTON, 1998 apud SCHACH, 2010). 
Diante das informações trazidas pelo autor, podemos concluir que a análise 
estruturada nos traz conceitos tradicionais e iniciais sobre a prática, quando 
inserida no processo de desenvolvimento de um software. Porém, não se tornou 
menos importante, pois traz a base de outras metodologias de análise, sendo, 
dessa forma, utilizada até os dias de hoje.
Ela é indicada diante de contextos simples, já o diagrama de fluxo de dados, 
pode ajudar a esboçar uma visão do sistema, fazendo com que seja necessário 
o uso de metodologias mais concisas e que possam abranger qualquer tipo de 
contexto, até mesmo porque atualmente vivemos em uma era tecnológica que 
exige cada vez mais sistemas computacionais complexos.
Acesso o link a seguir e leia o artigo Need for systems analysis 
and design, que aborda a importância da realização da 
análise de sistemas. 
https://goo.gl/yYX9ss
11Modelo de análise de software (análise estruturada)
Figura 2. Diagrama de fluxo de dados com todos os elementos gráficos. 
Fonte: Schach (2010, p. 357)
DEMARCO, T. Structured Analysis and System Specification. New York: Yourdon Press, 1978.
DUQUE DE CAXIAS. Secretaria Municipal de Educação. Análise Estruturada: diagrama 
de Fluxo de Dados. Duque de Caxias: SME, 2017. Disponível em: <http://smedu-
quedecaxias.rj.gov.br/nead/Biblioteca/Forma%C3%A7%C3%A3o%20Continuada/
Tecnologia/cursos/programacao/analise%20e%20logica/metodo%20integrado/
DFD.pdf>. Acesso em: 13 ago. 2017.
GANE, C. P.; SARSON, T. Análise Estruturada de Sistemas. São Paulo: LTC, 1985.
KENDALL, J. E.; KENDALL, K. E. Systems Analysis and Design. Upper Saddle River: Pren-
tice Hall, 2002.
MANZANO, J. A. N. G.; OLIVEIRA, J. F. Algoritmos: lógica para desenvolvimento e 
programação de computadores. 26. ed. São Paulo: Érica, 2012.
OLIVEIRA. R. C. Engenharia de Software. Uberlândia: UFU, 2011. Disponível em: < http://
www.facom.ufu.br/~ronaldooliveira/aps-2017-2.html#material>. Acesso em: 13 ago. 
2017.
SCHACH, S. R. Engenharia de software: os paradigmas clássicos e orientado a objetos. 
7. ed. Porto Alegre: AMGH, 2010.
Modelo de análise de software (análise estruturada)12
TEIXEIRA, M. N. Análise estruturada de sistemas. 3M Soluções, São Paulo, 2003. Dis-
ponível em: http://www.3msolucoes.com.br/adm/downloads/AE_Aulas_final.pdf. 
Acesso em: 13 ago. 2017.
UNESP. Dicionário de dados (DD): análise estruturada. São Paulo: UNESP, 2015. Disponível 
em: <https://moodle.unesp.br/ava/pluginfile.php/24935/mod_resource/content/2/4-
-DicionarioDados.pdf>. Acesso em : 16 out. 2017.
YOURDON, E.; CONSTANTINE, L. L. Structured Design: fundamentals of a Discipline 
of Computer Program and Systems Design. Englewood Cliffs: Prentice Hall, 1979.
Leituras recomendadas
JONES, M. P. Projeto Estruturado de Sistemas. Nova Iorque: McGraw-Hill, 1988.
MARTIN, J.; MCCLURE, C. Técnicas Estruturadas e CASE. São Paulo: Makron Books,1991.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem profissional. 
8. ed. Porto Alegre: AMGH, 2016.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
SLACK, N.; CHAMBERS, S.; JOHNSTON, R.; BETTS, A. Gerenciamento de operações e de pro-
cessos: princípios e práticas de impacto estratégico. 2. ed. Porto Alegre: Bookman, 2013.
13Modelo de análise de software (análise estruturada)
Conteúdo:
ENGENHARIA 
DE SOFTWARE
Izabelly Soares de Morais
Modelo de análise de 
software (orientada 
a objetos)
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Identificar os objetivos da análise orientada a objetos.
 � Aplicar os principais elementos de modelagem (diagramas da UML).
 � Avaliar as vantagens e as desvantagens deste modelo.
Introdução
A análise orientada a objetos, diferentemente do enfoque tradicional, 
sugere que um sistema é uma coletânea de objetos que interagem entre 
si, com características próprias, representadas por atributos e operações. 
Neste tipo de análise, os atributos representam os dados de um objeto 
e servem para expressar características e informações. Já as operações 
são as ações que podem ser realizadas pelo objeto. O mais interessante 
é a possibilidade de modelar o sistema usando objetos que representam 
elementos do mundo real. Isso permite que sistemas complexos sejam 
facilmente modelados e implementados, além de facilitar o seu cresci-
mento e a manutenção.
Neste capítulo, você vai adquirir conhecimentos fundamentais para 
avançar no aprendizado sobre análise orientada a objetos. Explore concei-
tos básicos sobre o modelo, suas ferramentas, vantagens e desvantagens.
Engenharia de software aplicada à análise de 
software orientada a objetos
A era tecnológica almeja por softwares cada vez mais complexos. Essa com-
plexidade está ligada diretamente à grande quantidade de informações que 
devem ser processadas simultaneamente. Com o tempo, os recursos tecno-
lógicos passaram por diversas mudanças, tanto em seus dispositivos físicos 
quanto lógicos. A Engenharia de Software surgiu devido à necessidade de 
haver técnicas que norteassem o processo de desenvolvimento do software.
Diante dos diversos conceitos, métricas e ferramentas que regem a Engenha-
ria de Software, foram desenvolvidas maneiras de realizar a análise de software. 
Primeiramente, o modelo mais utilizado foi o modelo de análise estruturada, 
que ficou conhecido também como um modelo clássico. Por ser clássico, ele 
traz conceitos de base para se realizar a análise de um software. Porém, como 
citado anteriormente, vivemos em uma era em que os artefatos tecnológicos 
devem ser cada vez mais robustos e compatíveis às novas tecnologias. 
A OOA (análise orientada a objetos, em inglês object-oriented analysis,) 
é uma técnica de análise semiformal para o paradigma de orientação a obje-
tos. A análise orientada a objetos é um componente-chave do paradigma de 
orientação a objetos. Quando esse fluxo de trabalho é realizado, as classes são 
extraídas. Os casosde uso e as classes são a base de um produto de software 
orientado a objetos a ser desenvolvido (SCHACH, 2010, p.395). Dessa forma, 
“concentra-se na definição de classes e na maneira como colaboram entre si 
para atender aos requisitos dos clientes” (PRESSMAN; MAXIM, 2016, p. 
172). Uma classe traz um conceito do mundo real, representa algum conceito, 
um objeto, que tem comportamento e características e que executa ações.
Assim como as diversas vertentes da Engenharia de Software, a metodologia 
de análise de software também requer técnicas específicas para que todos os 
detalhes observados sejam documentados, seja por meio da escrita de uma 
documentação específica, seja pelo uso de recursos gráficos. Veremos quais 
elementos são utilizados pela análise orientada a objetos no próximo tópico.
Uma das metodologias existentes na Engenharia de Software é a meto-
dologia ágil e que pode ser aplicada na análise de software. No The Official 
Agile Modeling Site, Scott Ambler (apud PRESSMAN; MAXIM, 2016, p. 81), 
descreve modelagem ágil (AM) da seguinte maneira:
Modelagem ágil (AM) consiste em uma metodologia prática, voltada para a 
modelagem e documentação de sistemas baseados em software. Simplificando, 
modelagem ágil consiste em um conjunto de valores, princípios e práticas 
voltados para a modelagem do software que podem ser aplicados a um projeto 
de desenvolvimento de software de forma leve e eficiente. Os modelos ágeis 
são mais eficientes do que os tradicionais pelo fato de serem simplesmente 
bons, pois não têm a obrigação de ser perfeitos.
Modelo de análise de software (orientada a objetos)2
Elementos da modelagem orientada a objetos
O modelo de análise de software estruturado faz uso do diagrama de fluxo de 
dados e do dicionário de dados, não se limitando a nenhum desses elementos, 
até mesmo porque o uso de uma metodologia ou ferramenta irá depender do 
contexto ao qual ela será inserida. Dessa forma, para a realização da análise de 
software orientado a objetos, se faz comum o uso da linguagem de modelagem 
unificada (do inglês UML – unified modeling language) como elemento de 
representação gráfica e informacional de dados e informações de um software. 
Linguagem de modelagem unificada (UML)
A UML nos permite visualizar e especificar detalhes de um software em 
desenvolvimento por meio de uma linguagem específica. Ela permite que 
elementos, relacionamentos e diagramas sejam modelados. Esses elementos 
podem ser estruturais, comportamentais e, até, simples anotações sobre os 
artefatos do software, que são compostos por classes, componente, interações, 
pacotes, dentre outros. Os relacionamentos entre as classes, ou seja, entre 
os objetos dentro de um contexto de orientação a objetos, ocorrem por meio 
de dependências, associações, implementações e até generalizações. Cada 
relacionamento é estabelecido conforme o problema a ser solucionado.
Para Larman (2007, p. 39), a palavra visual na definição é um ponto-chave. 
A UML é a notação diagramática padrão, de fato, para desenhar ou apresentar 
figuras (com algum texto) relacionadas a software – principalmente software 
orientado a objetos (OO). Em Fowler (2003 apud Larman, 2007), três modos 
pelos quais as pessoas aplicam UML são apresentados:
 � UML como rascunho: diagramas incompletos e informais (frequente-
mente rascunhados à mão em quadros brancos) criados para explorar 
partes difíceis do problema ou espaço de soluções, explorando o poder 
das linguagens visuais.
 � UML como planta de software: diagramas de projeto relativamente 
detalhados, usados seja em Engenharia reversa, para visualizar e melhor 
entender o código existente em diagramas UML; ou geração de código 
(Engenharia avante).
 ■ Em Engenharia reversa: uma ferramenta UML lê o código fonte ou 
o código binário e gera (tipicamente) diagramas UML de pacotes, de 
3Modelo de análise de software (orientada a objetos)
classes e de sequência. Essas “plantas de software” podem ajudar o 
leitor a entender os elementos, a estrutura e as colaborações globais.
 ■ Antes da programação, alguns diagramas detalhados podem fornecer 
diretrizes para a geração de código (por exemplo, em Java), quer 
manualmente, quer automaticamente, com uma ferramenta. É comum 
que os diagramas sejam usados para uma parte do código e outra 
parte seja preenchida por um desenvolvedor que esteja codificando 
(talvez também aplicando rascunhos UML).
 � UML como linguagem de programação: especificação executável com-
pleta de um sistema de software em UML. Código executável será 
automaticamente gerado, mas não é normalmente visto ou modificado 
por desenvolvedores; trabalha-se apenas na “linguagem de programa-
ção” UML. Esse uso da UML requer um modo prático de diagramar 
todo o comportamento ou a lógica (provavelmente usando diagramas 
de interação ou estado) e está ainda em desenvolvimento em termos 
de teoria, ferramentas robustas e usabilidade.
Ainda sob o ponto de vista do autor, “a UML descreve tipos de esboço 
de diagramas, tais como diagramas de classe e diagramas de sequência. Ela 
não superpõe a eles uma perspectiva de modelagem. Por exemplo, a mesma 
notação UML de diagrama de classes pode ser usada para desenhar imagens 
de conceitos do mundo real ou de classes de software em Java” (LARMAN, 
2007, p. 40).
Diagrama de classe
O diagrama de classe 
“fornece um conjunto inicial de elementos de notação que todos os outros 
diagramas de estrutura usam. A representação UML de uma classe é um 
retângulo contendo três compartimentos empilhados verticalmente [...]. O 
compartimento superior mostra o nome da classe. O compartimento do meio 
lista os atributos da classe. O compartimento inferior lista as operações 
da classe. Ao projetar um elemento de classes em um diagrama de classes, 
deve-se usar o compartimento superior, e os dois compartimentos inferiores 
são opcionais (os dois inferiores seriam desnecessários em um diagrama que 
ilustrasse um nível mais alto de detalhes, no qual o propósito fosse mostrar 
somente o relacionamento entre os classificadores (BELL, 2016, p. 3). 
Modelo de análise de software (orientada a objetos)4
A Figura 1 a seguir traz um exemplo da notação gráfica do diagrama de 
classes.
Figura 1. Notação de um diagrama de classe.
O contexto que envolve a manipulação de objetos traz também a questão 
da herança, a qual permite que uma classe herde outras funcionalidades e 
até outros atributos. A representação gráfica desse conceito é realizada pela 
ligação entre as classes por meio de uma ponta de seta, já que o “traço” re-
presenta apenas uma associação. Neste caso, essa ponta de seta não deve ser 
preenchida e deve apontar, da classe que está disponibilizando, seus atributos 
e operações. Chamamos essa classe de superclasse (Figura 2).
Figura 2. Representação de uma herança no diagrama de classe.
5Modelo de análise de software (orientada a objetos)
De acordo com Pressman e Maxim (2016, p. 895), 
qualquer alteração nos atributos ou nas operações contidas dentro de uma 
superclasse é imediatamente herdada por todas as subclasses. Portanto, a 
hierarquia de classes torna-se um mecanismo pelo qual alterações (em altos 
níveis) podem ser imediatamente propagadas em um sistema. É importante 
notar que, em cada nível de hierarquia de classe, novos atributos e operações 
podem ser acrescentados àqueles que foram herdados de níveis mais altos 
na hierarquia.
As operações que envolvem o diagrama de classes podem ser contempladas também 
com outros tipos de eventos. Para isso, Bell (2016) descreve as seguintes associações 
que podem ser utilizadas com o diagrama de classes:
 � Associação bidirecional (padrão): Uma associação é uma ligação entre duas classes. 
As associações são sempre consideradas bidirecionais. Isso significa que ambas as 
classes estão cientes de cada uma e do relacionamento que têm, a menos que 
você qualifique a associação como algum outro tipo. 
 � Associação unidirecional: em uma associação unidirecional, duas classes sãore-
lacionadas, mas somente uma classe reconhece que o relacionamento existe. 
 � Uso de pacotes, interfaces e outros tipos de associações.
Casos de uso 
O caso de uso é outro diagrama da UML, e Alistair Cockburn (2001, apud 
PRESSMAN; MAXIM, 2016, p. 149) observa que “um caso de uso captura 
um contrato [...] [que] descreve o comportamento do sistema sob várias con-
dições, à medida que o sistema responde a uma solicitação de um de seus 
envolvidos”. Para Pressman e Maxim (2016, p. 149), basicamente, um caso 
de uso conta uma jornada estilizada sobre como um usuário (desempenhando 
um de uma série de papéis possíveis) interage com o sistema sob um conjunto 
de circunstâncias específicas.
De acordo com Schach (2010, p. 290), outra forma de interpretar um caso 
de uso é que ele mostra a interação entre o produto de software e o ambiente 
no qual ele opera, isto é, o ator é o membro do mundo externo ao produto de 
software, ao passo que o retângulo no caso de uso representa o produto de 
software. Normalmente, é mais fácil identificar um ator.
Modelo de análise de software (orientada a objetos)6
 � Frequentemente, ator é um usuário de produto de software. No caso 
de um produto de software para a área bancária, os usuários desse 
produto de software são os clientes e os funcionários do banco, como 
caixas e gerentes.
 � Em geral, o ator desempenha um papel em relação ao produto de sof-
tware, que poderia ser como usuário deste. Entretanto, o iniciador de 
um caso de uso, ou alguém que desempenhe um papel crítico em um 
caso de uso, também desempenha um papel, portanto, é considerado 
um ator, independentemente de essa pessoa também ser um usuário do 
produto de software (Figura 3).
Figura 3. Representação do diagrama de caso de uso.
Assim como no diagrama de classe, o caso de uso também traz associações, 
que relacionam os autores, os casos de uso, e até outros autores que podem 
estar envolvidos no mesmo contexto. Para Jacobson (1992 apud PRESSMAN; 
MAXIM, 2016, p. 150), algumas perguntas que devem ser respondidas por 
um caso de uso:
 � Quais são as metas do ator? 
 � Que precondições devem existir antes de uma jornada começar? 
 � Que tarefas ou funções principais são realizadas pelo ator?
 � Que exceções poderiam ser consideradas à medida que uma jornada 
é descrita?
 � Quais são as variações possíveis na interação do ator? 
 � Que informações de sistema o ator adquire, produz ou modifica? 
 � O ator terá de informar o sistema sobre mudanças no ambiente externo? 
 � Que informações o ator deseja do sistema? 
 � O ator gostaria de ser informado sobre mudanças inesperadas?
7Modelo de análise de software (orientada a objetos)
Diversos mecanismos podem ser utilizados na concepção de um caso de 
uso. Geralmente, as informações contidas nesse tipo de diagrama são oriun-
das de uma completa documentação de requisitos, os quais devem trazer os 
requisitos funcionais do sistema. Dessa forma, todos devem trazer mais clareza 
e consistência ao sistema, pois demonstram visualmente alguns de seus mais 
importantes aspectos, que são suas funcionalidades.
A UML tem muitos tipos de diagramas e, dessa forma, apoia a criação de diferentes 
modelos de sistema. No entanto, uma pesquisa em 2007 (ERICKSON; SIAU, 2007 apud 
SOMMERVILLE, 2011, p. 83) mostrou que a maioria dos usuários de UML acredita que 
cinco tipos de diagramas podem representar a essência de um sistema:
 � diagramas de atividades, que mostram as atividades envolvidas em um processo 
ou no processamento de dados;
 � diagramas de casos de uso, que mostram as interações entre um sistema e seu 
ambiente;
 � Diagramas de sequência, que mostram as interações entre os atores e o sistema, 
e entre os componentes do sistema;
 � Diagramas de estado, que mostram como o sistema reage aos eventos internos 
e externos.
Vantagens e desvantagens da análise orientada 
a objetos
A demanda social trouxe diversas versões da UML. Dessa forma, suas co-
notações buscaram sempre acompanhar a necessidade dos desenvolvedores 
de software. Com isso, uma das vantagens em utilizar a UML na análise de 
software orientada a objetos é que sempre há alguma atualização nova, para 
que sua usabilidade não fique obsoleta. Ela também traz facilidades que visam 
à melhor compreensão das funcionalidades de um sistema, deixando todos os 
detalhes mais claros, não só para os desenvolvedores, mas também para os 
clientes, que na maioria das vezes são leigos no assunto.
Modelo de análise de software (orientada a objetos)8
A desvantagem se encontra no tempo, o qual deve ser dedicado ao desen-
volvimento dos diagramas e, consequentemente, de uma vasta documentação. 
Dessa forma, só é indicado dar início ao processo de implementação após 
todo o sistema ter sido especificado nos diagramas. Outro fator atrelado à 
desvantagem do uso da UML na análise de software orientado a objetos é a 
familiaridade da equipe desenvolvedora com as notações dos diagramas e com 
as ferramentas utilizadas para desenvolvê-los, um fato que acaba atrelado ao 
tempo – e sabemos que para obter lucro no desenvolvimento de um software 
o custo-benefício deve estar ligado diretamente ao investimento de tempo,
ferramentas e uma equipe especializada.
De qualquer forma, a Engenharia de Software traz métodos que podem ser 
adaptáveis a qualquer projeto. O importante é sabermos que temos diversas 
opções. Porém, para realizarmos a melhor escolha, devemos conhecer todas 
as técnicas disponíveis e sabermos como elas operam em um ciclo de desen-
volvimento de software. 
A UML começou como um esforço de Booch e Rumbaugh, em 1994, não apenas 
com o intuito de criar uma notação comum, mas de combinar seus dois métodos: 
o de Booch e o OMT. Assim, o primeiro rascunho público do que hoje é a UML foi
apresentado como o Método Unificado (Unified Method). Ivar Jacobson, o criador do 
Método Objectory, se juntou a eles na Rational Corporation e, já formando um grupo, 
vieram a ser conhecidos como “os três amigos”. Foi nesse ponto que eles decidiram
reduzir o escopo do seu esforço e enfocar em uma notação comum de diagramação 
a UML em vez de um método comum (LARMAN, 2007, p. 43).
9Modelo de análise de software (orientada a objetos)
Veja a seguir um exemplo prático de um diagrama de caso de uso que traz o contexto 
de uma empresa da área de segurança residencial. Na imagem deste diagrama de caso 
de uso, podemos identificar os atores: proprietário e administrador do sistema, e os casos 
de uso: arma/desarma o sistema, acessa o sistema via internet, dentre outros (Figura 4).
Figura 4. Exemplo de diagrama de casos de uso e seus atores.
Fonte: Pressman e Maxim (2016, p. 153)
Modelo de análise de software (orientada a objetos)10
BELL, D. Fundamentos básicos de UML: o diagrama de classes. Uma introdução aos 
diagramas de estrutura em UML 2. IBM developerWorks, Nova York, 2016. Disponível em: 
<https://www.ibm.com/developerworks/br/rational/library/content/RationalEdge/
sep04/bell/index.html>. Acesso em: 16 ago. 2017.
COCKBURN, A. Writing Effective Use-Cases. Reading: Addison-Wesley, 2001.
FOWLER, M. UML Distilled. 3. ed. Reading: Addison-Wesley.2003.
JACOBSON, I. Object-Oriented Software Engineering. Reading: Addison-Wesley, 1992.
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orien-
tados a objetos e ao desenvolvimento iterativo.3. ed. Porto Alegre: Bookman, 2007.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem profissional. 
8. ed. Porto Alegre: AMGH, 2016.
SCHACH, S.R. Engenharia de software: os paradigmas clássicos e orientado a objetos. 
7. ed. Porto Alegre: AMGH, 2010.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
Leituras recomendadas
DEMARCO, T. Structured Analysis and System Specification. New York: Yourdon Press, 1978.
SLACK, N.; CHAMBERS, S.; JOHNSTON, R.; BETTS, A. Gerenciamento de operações e de 
processos: princípios e práticas de impacto estratégico. 2. ed. Porto Alegre: Bookman, 2013.
YOURDON, E.; CONSTANTINE,L. L. Structured Design: fundamentals of a Discipline 
of Computer Program and Systems Design. Englewood Cliffs: Prentice Hall, 1979.
11Modelo de análise de software (orientada a objetos)