11_analise_de_sistemas_

Prévia do material em texto

Análise de Sistemas
Análise de Sistemas
1ª edição
2019
Autoria
Parecerista Validador
Bruno Rafael de Oliveira Rodrigues
Sandra Gavioli Puga / Ricardo Soares
*Todos os gráficos, tabelas e esquemas são creditados à autoria, salvo quando indicada a referência.
Informamos que é de inteira responsabilidade da autoria a emissão de conceitos. Nenhuma parte
desta publicação poderá ser reproduzida por qualquer meio ou forma sem autorização. A violação dos
direitos autorais é crime estabelecido pela Lei n.º 9.610/98 e punido pelo artigo 184 do Código Penal.
4
Sumário
Sumário
Unidade 1
1. Modelagem Conceitual de Sistemas ........................7
Unidade 2
2. Apresentação da UML e Visão de Sistema .............21
Unidade 3
3. Modelagem Estrutural ............................................36
Unidade 4
4. Modelagem Dinâmica ..............................................50
5
Palavras do professor
Nesta disciplina, você será apresentado aos conceitos, técnicas e padrões 
utilizados para modelar sistemas de informação de forma clara e eficiente. 
A proposta principal deste estudo é contextualizar o tema de maneira que 
você tenha condições de compreender as técnicas de análise de sistemas 
e projetar modelos de software que são importantes para todo profissional 
da área de desenvolvimento de sistemas.
Aqui serão abordados temas sobre as funções do analista de sistemas, 
a importância da modelagem, as características da análise orientada a 
objeto e o padrão da Linguagem de Modelagem Unificada (UML). Além 
disso, você, também estudará como realizar o levantamento de requisitos, 
conhecer o documento de visão e ferramentas para se desenvolver 
diagramas e modelos de sistemas de software. 
Por meio de exemplos, estudos de casos são, então, apresentados a 
cenários, nos quais é possível aplicar as técnicas estudadas. Dessa maneira, 
além do conteúdo teórico, é possível absorver a prática proposta.
Ao final desta disciplina, você será capaz de realizar a atividades de análise 
de sistemas, aplicando os padrões de análise e modelagem com uma 
visão ampla e crítica.
Bons estudos!
6
Objetivos da disciplina
• Compreender os princípios da análise de sistemas.
• Aplicar as técnicas de levantamento e análise de requisitos.
• Empregar os conceitos da análise orientada a objetos.
• Criar modelos de sistemas de software usando a linguagem UML.
7
 1Unidade 11. Modelagem Conceitual de 
Sistemas
Para iniciar seus estudos
Nesta unidade, serão apresentados os principais conceitos da disciplina de 
Análise de Sistemas, conhecendo seus objetivos e desafios. Na construção 
de um sistema, a fase de análise é extremamente importante. Nela, são 
definidos quais os elementos do sistema que transformarão problemas 
do mundo real em soluções tecnológicas. Para isso, é necessário 
compreender bem as necessidades que o cliente expõe e, por meio de 
padrões, desenvolver modelos que atendam a essas necessidades. Então, 
vamos conhecer melhor esse trabalho?
Objetivos de Aprendizagem
• Compreender a finalidade e a importância da fase de análise de 
sistemas e do processo de desenvolvimento de sistemas.
• Conhecer os principais problemas de comunicação enfrentados 
no desenvolvimento de projetos.
• Identificar as diferenças, vantagens e desvantagens entre as 
técnicas de desenvolvimento: estruturado e orientada a objetos.
• Assimilar os conceitos relacionados à orientação a objetos.
• Entender a importância de utilizar um padrão de modelagem.
8
Análise de Sistemas | Unidade 1 - Modelagem Conceitual de Sistemas
Introdução 
Atualmente, a demanda por sistemas de software está cada vez maior. A necessidade das empresas em informatizar 
e se atualizarem, devido às mudanças das tecnologias e das tendências mercado, fazem com que essa demanda 
aumente cada vez mais. Assim, construir sistemas de qualidade que supram a necessidade do mercado é um grande 
desafio. Para isso, o analista de sistemas deve conhecer e aplicar as técnicas de análise e modelagem de sistema.
Nesta unidade, são abordados os conceitos sobre modelagem conceitual de sistemas sendo apresentadas suas 
principais características. Por que esses conceitos são úteis? O desenvolvimento de um software é algo complexo 
que depende de vários fatores e colaboradores para ser realizado. Um fator muito relevante é a análise de sistemas 
que, entre suas funções, temos a elaboração de modelos com base nos requisitos “levantados” com o cliente. 
Assim, o analista de sistemas precisa possuir boa comunicação e bons conhecimentos técnicos. 
Além disso, é importante entender como funciona o processo de desenvolvimento de software e os conceitos 
básicos sobre análise de sistemas e orientação a objetos. Em geral, os processos de desenvolvimento são úteis 
para situar o analista em suas funções e o apoiar durante todas as etapas. Os conceitos sobre orientação a 
objetos devem ser bem compreendidos e aplicados na fase de análise. Uma vez que, a orientação a objetos é um 
paradigma bastante difundido e utilizado na modelagem de sistemas, ele se torna essencial para todo o trabalho. 
O levantamento de requisitos e a modelagem de sistemas sãos as principais atividades de um analista de sistemas. 
É de suma importância entender como elaborar requisitos e modelos. Dessa maneira, ao final desta unidade, 
você será capaz de aplicar esses conceitos e compreender o valor inestimável da modelagem de sistemas.
1.1 Entendendo o processo de desenvolvimento de software
O processo de software define as atividades que devem ser realizadas em cada etapa do desenvolvimento. 
As atividades vistas como fundamentais no processo de software são (SOMMERVILLE, 2011):
• Especificação: é o documento que define as funcionalidades e restrições do software.
• Projeto e implementação: é a fase onde são modelados e codificados os artefatos do software.
• Validação de software: é a fase que garante a qualidade do software que valida que ele está de acordo 
com a especificação.
• Evolução: na evolução, são adicionadas ao software já existente novas funcionalidades.
Existem vários modelos de processos de software que podem ser aplicados no desenvolvimento. Contudo, em 
todos os processos são aplicadas as atividades de arcabouço, que são atividades genéricas dos processos. Essas 
atividades podem ser classificadas como:
• Comunicação: é a atividade na qual são levantados os requisitos junto ao cliente.
• Planejamento: são elaborados o cronograma, as análises de riscos e os recursos necessários.
• Modelagem: traduz a especificação em formatos simbólicos, tanto em nível de requisito quanto em nível 
de projeto.
• Construção: são gerados os códigos e testes do software.
• Implantação: é quando se coloca o produto em produção, ou seja, é nesta atividade que o cliente recebe 
o software.
9
Análise de Sistemas | Unidade 1 - Modelagem Conceitual de Sistemas
Os modelos de processo de software não necessariamente são realizados de forma totalmente sequencial. 
Isso pode variar de acordo com a estratégia adotada para o projeto ou conforme as diretrizes da empresa 
desenvolvedora.
No processo de desenvolvimento de um software, são envolvidas diversas pessoas, no qual exige-se compromisso 
e comunicação durante todas as fases do projeto. Os participantes dos projetos são classificados em três 
categorias: cliente, usuário e desenvolvedor (PFLEEGER, 2004), que são definidas como:
• Cliente: é quem paga para que seja construído o sistema.
• Usuário: é quem usa o sistema, não necessariamente é o cliente.
• Desenvolvedor: é o responsável por desenvolver e manter o sistema.
Em cada categoria, os membros possuem responsabilidades que são vitais para o projeto. Diante desse cenário, 
o papel do analista de sistemas é essencial para a criação e manutenção de um software. 
Para melhorcompreensão das atividades de análise de sistemas, é importante conhecer o funcionamento dos 
processos de software e suas atividades.
No processo de desenvolvimento de sistemas, devem ser definidas as atividades e os responsáveis por executar 
cada uma dessas atividades, bem como quando essas atividades serão executadas. Em cada momento do 
processo de desenvolvimento são gerados artefatos, como documentação, diagramas e códigos, por exemplo. 
Porém, como esses artefatos devem ser usados em cada etapa do processo de desenvolvimento? Na prática, 
antes, cada empresa utilizava processos rígidos ou simplesmente não tinham processo bem definidos.
Pensando em resolver problemas de padrões de processo, foi gerado o Processo Unificado (PU) do inglês 
Unified Process (UP), o qual é chamado de framework, isto é, ele dispõe de processos e métodos para alcançar um 
objetivo que visa aumentar a qualidade do desenvolvimento de software. Tem como característica ser interativo e 
incremental. Assim, cada fase possui novas características e interações. O PU é centrado na arquitetura. Assim, é 
definida a estrutura do sistema em sua fase de concepção. Isso significa que, antes mesmo de definir as tecnologias 
como linguagem de programação ou banco de dados do sistema, já é possível definir as funções do sistema e 
como elas irão interagir. Além disso, é dirigido, por caso de uso, os casos de uso descrevem o comportamento 
de cada função do sistema de acordo com a perspectiva do usuário. No Processo Unificado, os casos de uso são 
empregados desde a fase de concepção do sistema até a fase de transição, no qual o sistema é entregue ao 
cliente. Nesse sentido, é possível realizar um melhor planejamento começando, por exemplo, pelos casos de uso 
mais prioritários e complexos.
O processo unificado define, também, as fases presentes em todo o desenvolvimento de software. Cada uma 
dessas fases será tratada a seguir.
• Concepção: Nesta fase, inicia-se o levantamento dos requisitos do sistema. É o momento em que se 
procura entender o negócio do cliente e são realizados os primeiros modelos conceituais e descrições do 
requisito. 
• Elaboração: É nesta fase que se viabiliza o requisito, dando continuidade ao processo modelando o 
sistema. 
• Construção: Esta é a fase de implementação, ou seja, a fase onde se codifica e testa o sistema. 
• Transição: Esta fase é o momento em que é realizada a entrega do produto ao cliente e a migração dele 
do desenvolvimento para produção. 
A figura a seguir é uma representação clássica do processo unificado que ficou muito conhecida pelo seu gráfico 
de baleias. Nesse gráfico, é possível ver as interações de cada fase ao longo do tempo no eixo horizontal e no eixo 
vertical o fluxo de trabalho, ou seja, as atividades realizadas no projeto. Assim, cada fluxo de trabalho é situado 
em uma fase, sendo a intensidade de utilização das atividades desse fluxo destacada no gráfico.
10
Análise de Sistemas | Unidade 1 - Modelagem Conceitual de Sistemas
Figura 1 – Processo Unificado (PU)
Fonte: KRUCHTEN, 2004.
O Processo Unificado possui outras vertentes, uma delas é o Processo Unificado da Rational 
(Rational Unified Process – RUP) que é o processo criado pela IBM. Outra vertente é o Processo 
Unificado Ágil (Agile Unified Process – AUP) cujas fases são adaptadas para se usar em 
metodologias ágeis.
Saiba mais
O Processo Unificado visa fornecer um arcabouço para o processo de desenvolvimento. Ele organiza os fluxos de 
trabalho em relação a cada fase. 
Lembre-se de que ele não diz que cada atividade do fluxo é totalmente sequencial, mas que 
permeia em cada fase durante o ciclo de vida do projeto.
Fique atento!
11
Análise de Sistemas | Unidade 1 - Modelagem Conceitual de Sistemas
1.2 O que é análise de sistemas 
O termo sistema é bastante amplo e utilizado em várias áreas do conhecimento. De modo geral, refere-se a um 
conjunto de elementos que operam colaborativamente. Na biologia, é comumente empregado para descrever a 
interação e o relacionamento entre os órgãos do corpo humano, como, por exemplo, sistema cardíaco, sistema 
respiratório, sistema nervoso, entre outros. 
Na computação, é comum utilizar o termo sistema para descrever a relação entre seus diversos componentes. 
Pode-se então definir formalmente um sistema sendo um conjunto intencional de componentes inter-
relacionados que funcionam juntos para atingir certo objetivo (SOMMERVILLE, 2011). Um componente pode ser 
entendido como um elemento independente no sistema. 
Os sistemas de informações realizam o processamento de dados que são inseridos em seu contexto e produzem 
uma saída útil para ser analisada pelo seu usuário, ou seja, é capaz de receber informações, processá-las e retornar 
uma saída, além de interagir com o ambiente e se retroalimentar, conforme mostra a Figura 2.
Figura 2 – Esquema de sistemas
Entrada Processamento
FeedbackAmbiente
Saída
Fonte: Adaptada de PALMISANO; ROSINI, 2003.
Assim, uma empresa pode ser considerada um sistema, uma vez que, existe a interação com clientes, funcionários, 
fornecedores, tecnologias que são características de um sistema. Os softwares utilizados por ela, também, são 
considerados sistemas, como sistemas de pagamento, sistemas de controle de estoque, sistema de vendas etc. 
Mas, então o que é a análise de sistemas? 
A análise de sistemas é a atividade na qual é idealizada a execução do desenvolvimento e manutenção do 
software. Faz parte dessa atividade o levantamento de requisitos junto ao cliente, ou seja, identificar o que o 
software deve realizar para atender à necessidade do cliente, além de documentar as necessidades do sistema por 
meio de padrões. Por meio dessas documentações, tanto o cliente quanto a equipe de desenvolvimento devem 
conseguir identificar essas necessidades.
1.3 O problema da comunicação na análise de sistemas
A chave para se entender e solucionar o problema do cliente é a comunicação. O analista de sistemas deve ter 
a consciência de realizar uma comunicação efetiva tanto com os clientes e usuários quanto com a equipe de 
desenvolvimento. Uma das principais fases do processo de desenvolvimento de software é o levantamento de 
requisitos. Essa é justamente a fase do processo que tem como finalidade descobrir, analisar, documentar e 
verificar os serviços e restrições (SOMMERVILLE, 2011). 
12
Análise de Sistemas | Unidade 1 - Modelagem Conceitual de Sistemas
Ao fazer o levantamento de requisitos, o analista cria o documento de especificação que é validado pelo cliente 
e que pode ser utilizado na construção do sistema. A satisfação do usuário e a qualidade do sistema dependem 
fortemente de uma documentação bem escrita e de requisitos bem pensados.
Quanto mais tardio são descobertos problemas nos requisitos, mais complicado fica de resolver o problema, uma 
vez que se tem retrabalho na construção. 
Além de tempo e dinheiro, a qualidade do sistema pode também ser comprometida, devido às mudanças 
estruturais.
Tenha em mente que o levantamento de requisitos é extremamente crítico para o sucesso ou fracasso do projeto. 
A Figura 3 é um exemplo clássico utilizado na área da computação para ilustrar a comunicação no desenvolvimento 
de sistemas.
Figura 3 – Projeto balanço na árvore 
Fonte: PROJECT CARTOON, 2007.
Na figura, é possível perceber que cada um dos envolvidos teve um entendimento sobre os requisitos do projeto. 
Dessa forma, todos realizaram suas atividades de forma diferente, prejudicando o projeto e principalmente não 
atendendo à necessidade do cliente.
É interessante observar que, durante a fase de requisitos, muitas vezes o cliente não passa todas as informações 
necessárias para o desenvolvimento do sistema porque ele julga que essas informações são óbvias. Porém, para 
o analista de sistemas, as explicações do cliente nem sempre são óbvias. Por exemplo,ao se realizar projetos 
de contabilidade, recursos humanos, sistemas médicos e outros, as informações de cada área, que são do 
conhecimento desses profissionais, não são facilmente interpretadas pelo analista de sistemas.
13
Análise de Sistemas | Unidade 1 - Modelagem Conceitual de Sistemas
A comunicação é um dos possíveis problemas que podem ocorrer durante o levantamento 
de requisitos. Reflita como é possível minimizar as omissões de informações por parte do 
cliente, uma vez que você não é conhecedor do assunto do cliente.
1.4 Modelagem de sistemas
No desenvolvimento de sistemas, existem duas estratégias de modelagem de sistemas que podem ser 
empregadas: a estruturada e a orientada a objetos.
Análise estruturada
A modelagem de requisitos que utiliza a análise estruturada é a modelagem clássica. Teve sua origem quando os 
sistemas computacionais mais complexos começaram a surgir. Nesse tipo de análise, os diagramas de fluxo de 
dados (data flow diagram) são usados para representar para mostrar uma visão e o fluxo do sistema. Eles permitem 
explorar o domínio funcional e representar o comportamento do sistema (PRESSMAN; MAXIM, 2016). 
A Figura 4 a seguir ilustra um exemplo de diagrama de fluxo de dados.
Figura 4 – Diagrama de fluxo de dados
Processo 1 Processo 2
Sim Não
Processo 4Processo 3
Decisão
Fonte: Elaborada pelo autor.
14
Análise de Sistemas | Unidade 1 - Modelagem Conceitual de Sistemas
Apesar de alguns profissionais afirmarem que a análise estruturada é ultrapassada, ela é muito útil para organizar 
os pensamentos e representar o entendimento do negócio. Porém, destaca-se que um dos problemas da análise 
estrutura é que, quanto mais complexo é o problema, mais complexo, também, é o modelo, o que pode complicar 
mais do que ajuda.
Existem muitas ferramentas para se fazer diagramas de fluxos de dados, tanto gratuitas, 
como o DIA e o yED, quanto proprietárias, como o Microsoft Visio e o Enterprise Architect. 
Procure algumas ferramentas de software que permitam desenhar diagramas de fluxos de 
dados e experimente alguma. Caso não queira instalar em seu computador, há também 
opções de ferramentas on-line, como o draw.io e Lucidchart.
Saiba mais
Orientação a objetos
A orientação a objetos é uma outra estratégia para a modelagem de sistemas. Nessa abordagem, a ideia é 
representar os objetos do mundo real que são modelados e construídos no sistema. 
Na orientação a objetos, um objeto é uma unidade autônoma que contém seus próprios dados que são 
manipulados para alcançar os objetivos do objeto (BEZERRA, 2015). 
Um sistema orientado a objetos é formado por objetos que interagem uns com os outros para cumprir realizar 
suas funções. Cada objeto deve possui sua própria responsabilidade e, quando necessário, troca informações 
com outros objetos.
A orientação a objetos é um padrão que pode ser adotado para construção de um sistema 
permeando as fases de análise e implementação do sistema. Alguns exemplos de linguagens 
de programação que podem ser utilizadas para a implementação são Java, C++ e C#.
Fique atento!
 
Para melhor compreensão a orientação a objetos, alguns conceitos precisam ser entendidos, como por exemplo, 
a classificação, a abstração e a instanciação. Veja: 
15
Análise de Sistemas | Unidade 1 - Modelagem Conceitual de Sistemas
A classificação é a forma como os objetos são agrupados em um universo, por exemplo, cavalo, cachorro e gato 
podem ser classificados como animais, assim como carro, moto e avião como veículos. Para realizar a classificação 
de objetos, é necessário envolver, também, o processo de abstração, ou seja, como classificar os objetos. 
Os objetos podem ser classificados de acordo com suas características e comportamentos, por exemplo, um 
veículo tem como característica ser de metal, ter rodas ou asas e ter como comportamento a locomoção. Dessa 
maneira, o termo veículo é abstraído a muitos objetos, ou seja, é abstraída a classe veículo. Assim, a abstração está 
intimamente relacionada à classificação. Ao classificar um objeto do mundo real, estamos abstraindo esse objeto.
A percepção desse objeto dentro de uma classe é chamada de instanciação. Em outras palavras, ao reconhecer 
que um objeto contém característica de um grupo, logo se faz a instanciação desse objeto. Quando instanciamos 
um objeto de uma classe, estamos criando um novo item do conjunto representando por essa classe, com as 
mesmas características e os mesmos comportamentos de todos os outros objetos já instanciados (GUEDES, 2014).
O Quadro 1 a seguir exemplifica como esses conceitos podem ser apresentados:
Quadro 1 – Exemplo de objeto
Objeto Classe Características Comportamento
Cavalo Animal Mamífero, quadrúpede, 
herbívoro
Anda, corre, transporta 
seres humanos ou 
cargas
Cachorro Animal Mamífero, quadrúpede, 
onívoro
Late, brinca, protege a 
casa
Carro Veículo De Metal, quatro rodas, 
usa motor
Transporta pessoas e 
coisas
Avião Veículo De metal, possui asas e 
motor 
Voa e transporta 
pessoas ou carga
Fonte: Elaborada pelo autor.
Observe nos exemplos que é possível instanciar cada objeto em novos objetos, uma vez que, cada cachorro, por 
exemplo, pode ser de uma raça diferente. Dessa forma, poderia instanciar um pastor alemão ou um poodle que 
são objetos do tipo cachorro. Assim, tem-se características e comportamentos em comum. 
Para melhor elucidar os conceitos apresentados, vamos utilizar o exemplo de um sistema de estoque de uma loja. 
No exemplo, o estoque é um objeto que possui informações sobre a quantidade de cada produto, como ilustra o 
Quadro 2 a seguir.
Quadro 2 – Exemplo dos conceitos de objeto no sistema de estoque
Objeto Classe Características Comportamento
Estoque Produto Descrição, quantidade Controlar quantidade
Fonte: Elaborada pelo autor.
16
Análise de Sistemas | Unidade 1 - Modelagem Conceitual de Sistemas
Note que o objeto estoque pode representar qualquer produto, como um sapato, roupa ou outro. Ele possui 
características que definem o produto como a descrição do produto e a quantidade em estoque. Nesse exemplo, 
seu único comportamento é o de controlar a quantidade do produto. Assim, ele pode aumentar ou subtrair a 
quantidade em estoque desse produto.
Vale a pena entender o comportamento dos objetos por meio de três características: operação, mensagem e 
estado. 
A operação é a função que o objeto realiza, em geral, produzido com o estímulo de alguma mensagem vinda de 
outro objeto. Essa operação por sua vez pode alterar o estado dos valores desse objeto (BEZERRA, 2015). Nesse 
contexto, supondo o comportamento do objeto estoque durante uma venda. Ao ser acionada a ação de venda, 
a quantidade no estoque do produto vendido é automaticamente alterada. Conforme a figura a seguir é possível 
ver que o objeto estoque recebe a mensagem venda e este altera o estado do valor do seu atributo quantidade.
Figura 5 – Comportamento dos objetos
Venda
Estoque
Quantidade
Fonte: Elaborada pelo autor.
Vamos conhecer um pouco mais sobre orientação a objetos?
A orientação a objeto traz uma série de conceitos que são importantes para aumentar a qualidade do sistema 
ao se trabalhar com esse paradigma. Conceitos como de encapsulamento, polimorfismo, generalização e 
composição que são tipicamente encontrados em sistemas orientados a objetos. Bezerra (2015) descreve esses 
conceitos da seguinte maneira:
• Encapsulamento: a ideia do encapsulamento é de restringir o acesso aos comportamentos do objeto. 
• Generalização (herança): permite que um componente herde características de outro componente. 
• Polimorfismo: uma operação pode ser utilizada para realizar funções diferentes dentro do sistema. 
• Composição: permite criar objetos a partir de outro, em outras palavras, um objeto ser composto por 
outros objetos.Nesta unidade, o termo componente é utilizado para se referir sobre classes e objetos, em 
que, nas explicações a seguir, o termo pode ser entendido como ambos.
Fique atento!
17
Análise de Sistemas | Unidade 1 - Modelagem Conceitual de Sistemas
Ao modelar um projeto orientado a objetos e até mesmo ao codificá-lo, você deve seguir a 
recomendação de que o sistema tenha baixo acoplamento e alta coesão.
O que isso significa?
O acoplamento é o relacionamento que existe entre componentes do sistema. Ao se modelar um sistema, é 
comum que isso ocorra, pois um componente chama outro para realizar uma função. Porém, quando um 
componente é muito dependente de outro existe um forte acoplamento, ou que eles são fortemente acoplados. 
Isso é ruim, uma vez que, essa dependência pode prejudicar o comportamento do sistema com muita sobrecarga 
ou até mesmo quando se alterar um componente outro sofra com essa alteração de forma errada.
A coesão é o contrário do acoplamento, ao passo que o acoplamento cria dependências com componentes 
externos, a coesão possui mais responsabilidades do que ela deve de fato assumir. Em outras palavras, a coesão 
é quando um componente possui, além de suas próprias responsabilidades, as que seriam de outro componente. 
Assim, ao invés de um componente buscar por uma operação em outro, ele simplesmente implementa a 
operação nele mesmo. Assim, um componente quando possui muitas operações que, às vezes foge até mesmo 
do seu domínio, diz-se que ele tem baixa coesão, ou seja, o componente não está coeso com o que propõe. 
Nesse sentido, ao se dizer que um sistema deve ter alta coesão e baixo acoplamento, refere-se ao fato de que 
cada componente deve ter suas responsabilidades bem explícitas. E que, o uso errado da orientação a objetos 
na modelagem, como usar generalização indiscriminadamente pode causar alto acoplamento. Da mesma forma 
que, ao se colocar responsabilidades que fogem do domínio do componente causa-se baixa coesão. Portanto, 
deve se ficar atento a esses detalhes que são reflexos da abstração.
Quando não se entende bem o problema e não é possível abstrair bem os dados do mundo real para o modelado, 
alguns desses problemas citados costumam acontecer.
As vantagens de se usar a orientação a objetos no desenvolvimento de sistemas vão muito além de modismo ou 
simplicidade. Como principais vantagens, são consideradas a reusabilidade e a manutenibilidade. A reusabilidade 
permite que componentes já criados no projeto sejam utilizados por outros. Já a manutenibilidade, é a atividade 
realizada a entrega do produto ao cliente. Nessa atividade o cliente pode relatar defeitos ou melhorias ao sistema. 
Graças à orientação a objetos essa atividade, que representa grande parte do ciclo de vida do sistema, é facilitada. 
Na modelagem de sistemas, é utilizado a linguagem UML (Unified Modeling Language), no qual não é uma 
linguagem de programação, mas sim uma linguagem que utiliza a orientação a objetos para descrever o sistema.
A Orientação a Objetos permite aumentar a qualidade do projeto de software. Contudo, 
mesmo utilizando esse paradigma não é garantido que a qualidade será alcançada.
18
Análise de Sistemas | Unidade 1 - Modelagem Conceitual de Sistemas
1.5 A importância da modelagem de sistemas
Durante toda esta unidade, foi falado sobre modelar o sistema, mas...
Para que serve a modelagem?
Não é possível construir um software sem modelar?
Vejamos a argumentação desse contexto:
A modelagem é uma atividade do desenvolvimento de software que visa abstrair as informações levantadas junto 
ao cliente em um projeto no qual é possível se desenvolver o sistema. Por meio desses modelos, tem-se uma visão 
do fluxo de trabalho do cliente, da forma como os componentes do sistema devem se comportar, ser acessados e 
se comunicarem, entre outras informações que são totalmente relevantes durante sua construção.
Em geral, a pessoa que realiza a fase de concepção e elaboração não é a mesma que codifica e testa. Assim, existe 
uma ponte entre o cliente e o programador, que é justamente a parte que o analista de sistemas preenche. 
Entretanto, se o programador fizesse o levantamento dos requisitos junto ao cliente, haveria a necessidade de 
fazer os modelos? A resposta mais curta para essa pergunta é simplesmente sim, porque, ao fazer essa atividade, 
é preciso compreender as atividades do cliente e como elas são feitas para se propor uma solução viável no qual 
o software irá atender.
Fazendo uma analogia a construção civil, uma casa feita sem projeto costuma ter problemas estruturais e até 
mesmo funcionais. No software, por sua vez, acontece a mesma coisa. Quando não é feito o projeto do software 
que será construído, ele sofre com problemas estruturais e funcionais, uma vez que, não sendo planejado 
corretamente, a tendência é que a qualidade de software seja baixa. 
Como uma das funções da modelagem é aumentar a qualidade do sistema, pode-se entender que a sua 
manutenção, também, será facilitada graças ao modelo. Por meio dele, é possível preparar a estrutura do 
sistema para aceitar mudanças. Um sistema não é algo estático que, ao construí-lo, e está simplesmente pronto. 
Com o passar do tempo, novos requisitos podem ser agregados ao sistema e outros podem sofre alterações. 
Por esse motivo, quanto melhor preparado o sistema, maiores serão as chances de ele não sofrer tanto com as 
manutenções.
Além da qualidade, outro ponto que deve ser levado em consideração para se modelar sistemas é o de melhorar 
o planejamento. Graças à utilização de modelos, é possível estimar melhor o tempo e recursos necessários para 
que o sistema seja construído. Assim, a modelagem ajuda a satisfazer corretamente a necessidade do usuário, 
aumenta a qualidade do projeto, além de permitir que se entregue o projeto no prazo.
Mas, o que é um modelo conceitual? Como o próprio nome diz, o modelo conceitual busca extrair conceitos de 
um negócio. Suponha a modelagem de um sistema educacional, no qual se tem a seguinte representação: um 
aluno se matricula em um curso. O curso pode ter muitos alunos matriculados ou nenhum. 
Com base na descrição, a Figura 6 representa de forma simplória esse exemplo, no qual se tem os conceitos de 
Aluno e Curso que possuem os atributos nome e descrição, respectivamente, e estão relacionados por meio da 
matrícula.
19
Análise de Sistemas | Unidade 1 - Modelagem Conceitual de Sistemas
Figura 6 – Exemplo de modelo conceitual
Aluno 0..* 1..1 Curso
matricula descricaonome
Fonte: Elaborada pelo autor.
O modelo conceitual é útil durante o processo de análise para entender melhor o problema do negócio do cliente 
e validar se os termos presentes nesses conceitos, de fato, estão empregados de forma correta (WAZLAWICK, 
2010).
Síntese da unidade
Você foi capaz de compreender os conceitos básicos de análise de sistemas, os processos de desenvolvimento, a 
importância da comunicação não apenas no levantamento de requisitos, mas durante toda as fases do projeto. 
Viu-se os conceitos da análise estruturada e orientação a objetos que, apesar de parecer que um é evolução 
do outro, um pode complementar o outro. E foi vista também a importância de elaborar modelos de sistemas, 
independentemente de sua complexidade.
20
Considerações finais
Esta unidade apresentou os aspectos teóricos iniciais para a análise 
de sistemas. Os assuntos aqui tratados são de suma importância não 
apenas para o analista de sistemas, mas como para toda a equipe de 
desenvolvimento. Essa unidade é a porta de entrada para entender a 
complexidade por trás do desenvolvimento de sistemas. Agora siga em 
frente!
21
 2Unidade 22. Apresentação da UML e Visão 
de Sistema
Para iniciar seus estudos
Nesta unidade, serão apresentados a linguagem UML e os conceitos e 
técnicas do levantamento de requisitos. O levantamento de requisitosé 
uma atividade na qual se compreende e documenta todos os requisitos 
do sistema. Para isso, são aplicadas técnicas para colher informações do 
cliente e também para documentá-las. Então vamos conhecer algumas 
dessas técnicas?
Objetivos de Aprendizagem
• Entender os conceitos da linguagem UML, seus diagramas e suas 
ferramentas.
• Definir as técnicas e artefatos usados no levantamento de 
requisitos.
• Identificar os requisitos de sistema.
• Criar casos de uso.
22
Análise de Sistemas | Unidade 2 - Apresentação da UML e Visão de Sistema
Introdução da unidade
A Linguagem de Modelagem Unificada (UML) é amplamente utilizada no mercado para se desenvolver sistemas. 
A UML contém diagramas que auxiliam os analistas durante todas as fases do desenvolvimento. À vista disso, 
conhecer seus recursos é de suma importância para realizar com qualidade as atividades de análise de sistemas. 
As técnicas de análise de requisitos são utilizadas para capturar e documentar os requisitos com o cliente. O 
levantamento de requisitos é uma fase delicada no desenvolvimento de sistemas. Por isso, espera-se que tais 
conceitos e técnicas sejam bem entendidos para que possam ser aplicados em cenários reais. 
No levantamento de requisitos, diversos artefatos são utilizados para se documentar as funcionalidades 
do sistema, bem como as caraterísticas necessárias para a sua construção. Assim, nesta unidade, você terá a 
oportunidade de enxergar como escrever e modelar casos de uso, que são documentos gerados na análise de 
requisitos que tratam da construção do sistema pela perspectiva do usuário. Esse artefato é bastante utilizado na 
área de desenvolvimento de sistemas e exige atenção do analista. 
Pois bem, esperamos que consiga assimilar todo o conteúdo aqui passado e que esses sejam utilizados da melhor 
maneira em sua vida profissional. 
Bons estudos!
2.1 Linguagem de Modelagem unificada (UML)
Um artefato é um componente do produto de software, como um documento de especificação, um módulo de 
um programa ou um manual (SCHACH, 2009). Em todas as fases do desenvolvimento de sistemas, são gerados 
artefatos que permitem à equipe de desenvolvimento e ao cliente visualizarem o projeto de software que será 
construído. A Unified Modeling Language (UML) ou Linguagem de Modelagem Unificada foi criada para auxiliar 
na documentação de sistemas orientados a objetos, com a intenção de melhorar o planejamento do projeto e 
aumentar a qualidade do sistema. 
A UML é uma linguagem usada para modelar sistemas usando o paradigma de orientação a objetos. É bom 
frisar que ela não é uma linguagem de programação, mas uma linguagem de modelagem que auxilia no 
desenvolvimento de sistemas. Guedes (2014) adiciona que a UML é utilizada para representar as características, 
comportamento e estrutura do sistema, bem como a dinâmica dos processos.
A UML é dividida em três grupos de diagramas (WAZLAWICK, 2010):
• Digramas estruturais: diagramas de pacotes, classes, objetos, estrutura, componentes e distribuição.
• Diagramas comportamentais: diagramas de caso de uso, atividades e máquina de estado.
• Diagramas de interação: representados pelos diagramas de comunicação, sequência, tempo e visão de 
integração.
Apesar da grande quantidade de diagramas disponíveis, é interessante entender que no projeto não é necessário 
usar todos os diagramas. Isso varia de acordo com o sistema a ser modelado e com os padrões requeridos pela 
empresa de desenvolvimento. Algumas empresas costumam fixar os artefatos que elas determinam que sejam 
produzidos.
23
Análise de Sistemas | Unidade 2 - Apresentação da UML e Visão de Sistema
O padrão UML foi disponibilizado à comunidade de desenvolvimento de sistemas na década de 1990, quando 
Booch, Jacobson e Rumbaugh uniram os seus métodos, o método de BOOCH, Object Modeling Technique (OMT) 
e Object-Oriented Software Engineering (OOSE), com o apoio da Rational. Atualmente, a UML é mantida pela Object 
Management Group (OMG) e é a linguagem de modelagem padrão no desenvolvimento de software (GUEDES, 
2014).
2.1.1 Diagramas UML
Para melhor compreender como funcionam os diagramas UML, veja os conceitos dos principais diagramas 
utilizados no desenvolvimento de sistemas. Pressman e Maxim (2016) descrevem:
• Diagrama de caso de uso: procura mostrar as funcionalidades do sistema pela visão do usuário, assim 
ele mostra a interação do usuário no sistema, e por ele é possível se ter uma visão geral do sistema.
• Diagrama de classes: descrevem uma visão estática ou estrutural do sistema. Ele é composto pelas 
classes, seus atributos, operações e relacionamentos.
• Diagrama de objetos: representa classes com visão estática do sistema, assim os objetos mostram os 
valores armazenados pelos objetos das classes, que são determinados em dado momento na execução 
do sistema. Nesse caso, esse diagrama é útil para simular as situações das classes.
• Diagrama de atividades: esse diagrama é semelhante a um fluxograma, ele mostra o comportamento 
dinâmico do sistema por meio de fluxos de controle, podendo mostrar também fluxos concorrentes.
• Diagrama de sequência: nesse diagrama é mostrada a comunicação dinâmica dos objetos no momento 
de execução, ou seja, ele procura exibir o que acontece quando um determinado objeto é executado em 
ordem temporal. Dessa maneira, é possível ver as interações desse objeto.
• Diagrama de estado: no sistema, um objeto pode mudar constantemente os valores de suas variáveis. 
O diagrama de estado procurar exibir como essas variáveis de controle trabalham ao longo do processo 
do sistema. Ele ajuda a descobrir situações perdidas ou inesperadas, garantindo que os eventos possíveis 
para aquele estado sejam levados em conta durante sua transição.
2.1.2 Ferramentas UML
Existem diversas ferramentas profissionais e gratuitas que podem ser usadas para se construir diagramas UML. 
Entre as mais populares do mercado, podem ser vistas: a Enterprise Architect (EA), as suítes da International Business 
Machines (IBM) e Microsoft Visio.
A EA é uma ferramenta bastante robusta disseminada no mercado. É uma ferramenta proprietária mantida 
pela Sparx Systems. Por meio dessa ferramenta, é possível construir praticamente todos os artefatos da fase de 
requisitos e modelagem de sistemas.
A IBM disponibiliza suítes de ferramentas agregadas que permitem construir modelos UML, como é o caso da IBM 
Rational Software Architect, IBM Rational Rhapsody Developer, IBM Rational Rose e IBM Rational Modeler. 
24
Análise de Sistemas | Unidade 2 - Apresentação da UML e Visão de Sistema
A Microsoft, em sua Integrated Development Environment (IDE)/Ambiente de Desenvolvimento Integrado - Microsoft 
Visual Studio, possibilita que se criem diagramas UML a partir dela. Além de diagramas, essa ferramenta oferece 
suporte a várias linguagens de programação, como C#, Basic, C++, entre outras.
Outras ferramentas que ficaram conhecidas no cenário UML foram a StarUML e Astah (antigo JUDE). Estas eram 
ferramentas gratuitas, porém no momento estão sendo disponibilizadas em versão paga. Contudo, o Astah ainda 
possui uma versão gratuita para estudantes, que pode ser adquirida mediante solicitação no seu próprio site.
As ferramentas que continuam sendo disponibilizadas de forma gratuita são: DIA, ArgoUML, UMBRELLO e 
PlantUML. Porém, com exceção da PlantUML, todas estão defasadas com a versão atual da UML e não têm evoluído 
muito nos últimos anos, isto é, não há novas versões e nem todas suportam os incrementos da UML.
Os diagramas UML podem, ainda, ser gerados dentro de IDEs, como o Eclipse e NetBeans. Nesse caso, é necessário 
baixar e instalar os plug-ins desses recursos. Vale lembrar que nem todo plug-in do Eclipse é disponibilizado de 
forma gratuita. 
Seguindo a tendência de ferramentas on-line, os diagramas UML também podem ser modelados sem a 
necessidadede instalar programas no computador. É o caso da Draw.io e Lucidchart. Eles oferecem aos usuários 
a possibilidade de modelar diagramas UML e outros apenas utilizando o navegador e a Internet. Para isso, basta 
possuir uma conta. No caso da Lucidchart, esta oferece uma versão de teste, mas depois é cobrado.
Apesar da grande quantidade de ferramentas disponíveis, todas são muito similares. Algumas, além de 
possibilitarem o desenho dos diagramas, permitem gerar código-fonte para a linguagem de programação 
configurada. Isso poupa o desenvolvedor do trabalho de digitar novamente os nomes de classes, atributos, etc.
Figura 7 – Ferramentas UML
Fonte: SHUTTERSTOCK, 2018.
25
Análise de Sistemas | Unidade 2 - Apresentação da UML e Visão de Sistema
Para saber um pouco mais, procure experimentar algumas das ferramentas mencionadas 
e dar uma olhada nos seus manuais. Faça os exemplos aqui apresentados e experimente 
algumas de suas funções. Além das ferramentas citadas, existem outras.
Saiba mais
2.1.3 Documento de visão
O documento de visão é primeiro documento a ser criado ao se iniciar um projeto de software. Nele, apresenta-se 
uma visão macro do projeto, ou seja, são colocados os requisitos do sistema de forma geral, sem muitos detalhes. 
Em suma, esse é um documento de mercado que tem como ideia registrar o que será construído e o que o cliente 
espera. 
Esse documento é feito pelo analista de requisitos, no qual é realizado o primeiro levantamento de requisitos 
do sistema. Nele, são descritos o escopo e as restrições do sistema, identificando as principais necessidades do 
cliente, os objetivos do sistema e a visão geral da solução. Quanto mais detalhado for o documento de visão, 
melhor será para planejar o sistema, assim, caso o analista julgue necessário, pode adicionar diagramas e propor 
soluções. 
A partir do documento de visão, os requisitos são detalhados e amadurecidos. É importante de ser feito, para 
deixar claro tanto para a equipe de desenvolvimento quanto para o cliente, qual o escopo e as restrições do 
projeto (ENGHOLM, 2017).
Figura 8 – Documento de visão
Fonte: SHUTTERSTOCK, 2018.
26
Análise de Sistemas | Unidade 2 - Apresentação da UML e Visão de Sistema
2.1.4 Engenharia de requisitos
O processo que reúne o conjunto de tarefas e técnicas para se fazer o levantamento de requisitos é chamado de 
engenharia de requisitos. 
A engenharia de requisitos tem início no processo de comunicação e modelagem do projeto. Ela abrange as 
atividades de concepção, levantamento, elaboração, negociação, especificação, validação e gestão. Cada uma 
dessas atividades pode ser realizada em paralelo ou de acordo com o processo adotado pela empresa. Pressman 
e Maxim (2016) descrevem essas atividades da seguinte forma:
• Concepção: essa é a atividade inicial de um projeto de software, e nela é estabelecido o projeto, definindo 
o problema a ser resolvido e as pessoas envolvidas. Nessa atividade são definidos o plano de negócio e a 
viabilidade para ele. Aqui já se tem uma noção do escopo do projeto. 
• Levantamento: é questionado ao cliente o que de fato se deve ser construído. Nessa fase surgem diversos 
problemas como no escopo do sistema, no seu entendimento e sua volatilidade, ou seja, as recorrentes 
mudanças no requisito.
• Elaboração: é a atividade que modela o sistema, ou seja, refina os dados obtidos na concepção e 
levantamento e utiliza diagramas para documentá-las. 
• Negociação: quando surgem conflitos de requisitos, prioridades ou o escopo se amplia mais do que o 
previsto, o analista deve fazer negociações para gerenciar os conflitos e definir as prioridades a serem feitas. 
• Especificação: são os documentos e modelos gerados a partir do requisito.
• Validação: quando documentados os requisitos, o cliente precisa validar essas informações. Nessa 
atividade a equipe valida o que foi escrito na especificação como forma de garantir a qualidade do 
produto, assim, é verificado o seu entendimento para não haver ambiguidade. O cliente pode participar 
dessa fase para complementar a documentação.
• Gestão de requisitos: nessa etapa são gerenciadas as mudanças do requisito do sistema, assim, 
controlam-se o projeto e acompanhamentos sobre as necessidades de mudanças. 
Essas atividades fazem parte de um ciclo percorrido pelo analista para projetar o sistema. Elas não precisam ser 
realizadas exatamente de forma sequencial, mas devem ser compreendidas para que o analista se posicione 
conforme a situação. As empresas de desenvolvimento podem adotar ou adaptar processos em que são definidos 
como efetuar essas atividades.
2.1.5 Levantamento e análise de requisitos
O levantamento de requisitos é a atividade do desenvolvimento de sistemas na qual o analista procura entender 
e documentar as funcionalidades e restrições do sistema para atender à necessidade do cliente. Essa atividade, 
apesar de parecer simples, é uma das mais complexas do desenvolvimento. Essa complexidade está relacionada 
ao fato que o cliente, muitas vezes, não sabe o que quer. Além disso, a volatilidade com que os problemas ocorrem 
é muito grande. Assim, o cliente pode não ter certeza do que está relatando ou a visão que ele tinha no momento 
do levantamento de requisitos já não é a mesma depois. 
27
Análise de Sistemas | Unidade 2 - Apresentação da UML e Visão de Sistema
Existem sistemas em que as mudanças no requisito são constantes. Por isso, um bom gerenciamento dos 
requisitos e técnicas de negociação devem ser aplicadas para minimizar os impactos causados pelas mudanças. 
Quanto mais tarde os problemas de requisitos forem encontrados, maiores serão seus custos.
O termo levantamento de requisitos é conhecido também como elicitação de requisitos. Nele, são combinados 
elementos de resolução de problemas, elaboração, negociação e especificação. Assim, são identificados 
os problemas a serem tratados pelo sistema, negociam-se as abordagens e se definem algumas soluções 
(PRESSMAN; MAXIM, 2016).
O processo de elicitação e análise de requisitos passam pelas seguintes atividades: obtenção de requisitos; 
classificação e organização de requisitos; priorização e negociação de requisitos; documentação de requisitos. 
Essas atividades podem ser descritas da seguinte forma (SOMMERVILLE, 2011):
• Obtenção de requisitos: ocorre a interação com as partes interessadas (stakeholders) para coletar 
informações sobre os requisitos. 
• Classificação e organização de requisitos: se agrupam os requisitos relacionados, e esses são 
organizados de forma coerente. 
• Priorização e negociação de requisitos: é usada no momento em que se têm requisitos no sistema que 
começam a ser conflitantes entre si. Nesse momento, o analista deve procurar negociar os requisitos para 
evitar conflitos e também para priorizá-los. 
• Documentação de requisitos: os requisitos levantados são documentados, podendo ser documentos 
formais ou informais, passando por um ciclo iterativo.
Para fazer o levantamento de requisitos, algumas técnicas podem ser utilizadas, como (SOMMERVILLE, 2011):
• Pontos de vista: são verificados os requisitos com diversos stakeholders, nesse caso são verificados os 
requisitos do sistema por meio de várias pessoas que têm atividades diferentes na empresa, logo, pontos 
de vistas diferentes.
• Entrevistas: podem ser feitas com um roteiro predefinido ou de uma forma exploratória. Em geral, as 
entrevistas acontecem com a combinação dos dois. As entrevistas são úteis para se ter um conhecimento 
geral, mas não do domínio, uma vez que, durante as entrevistas, o cliente pode utilizar termos que são 
apenas do domínio do negócio dele e ser mal interpretado pelo analista, por causa das ambiguidades da 
língua.
• Cenário: o usuário descreve por meio de exemplos a interação com o sistema. Assim, pode capturar 
fluxos, o que pode dar errado no sistema, atividadessimultâneas entre outras. 
• Caso de uso: identifica as ações e os agentes que irão interagir com o sistema, é composto por vários 
cenários detalhados que podem estar relacionados entre si.
• Etnografia: é uma técnica de levantamento de requisitos que se baseia na observação. Nela o analista 
observa o dia a dia do trabalho na empresa para melhor compreender o seu funcionamento, capturando 
requisitos que estão implícitos. 
28
Análise de Sistemas | Unidade 2 - Apresentação da UML e Visão de Sistema
Além das técnicas de levantamento de requisitos aqui citadas, existem outras que podem ser 
exploradas, como a prototipação e Joint Application Design (JAD).
Saiba mais
2.1.5.1 Requisitos e regras de negócio
Os requisitos são classificados em requisitos funcionais, não funcionais e de domínio. Os requisitos funcionais 
são aqueles que ditam as funcionalidades do sistema (o que o sistema pode ou não fazer), estando ligados 
explicitamente às características do sistema. 
Já os requisitos não funcionais são restrições de funcionamento do sistema, tais como o tempo de resposta, 
o armazenamento e limitações de hardware, podendo ser, também, vindas de fontes externas, como 
interoperabilidade e requisitos da própria organização. 
Sommerville (2011) descreve os requisitos não funcionais definindo-os em grupos maiores, veja:
• Requisitos de produto: definem o comportamento do produto, como, por exemplo, requisitos de 
velocidade, quanto de memória ele requer, quantidade de falhas aceitáveis, portabilidade e usabilidade.
• Requisitos organizacionais: são definições das políticas do cliente ou do desenvolvedor, como padrões 
de processos e linguagem de programação.
• Requisitos externos: como o próprio nome sinaliza, esses requisitos são definidos por outros, como 
sistemas no qual o produto irá interagir (interoperabilidade), conformidade com a lei e questões éticas.
Os requisitos de domínio são os requisitos que fazem parte do domínio do negócio do cliente. Eles contêm 
conceitos que estão diretamente relacionados ao negócio. Assim, para se fazer um cálculo trabalhista, por 
exemplo, é necessário entender seu domínio e os termos utilizados por ele.
As regras de negócio definem as restrições lógicas ou tecnológicas que se aplicam a uma funcionalidade 
(WAZLAWICK, 2010). As regras de negócio são regras que regem o negócio e complementam o funcionamento 
de certos processos. Estão mais relacionadas ao domínio e existem independentes do sistema.
Vazquez e Simões (2016) aconselham que as regras de negócio sejam especificadas independentemente dos 
requisitos funcionais, para facilitar modificações e serem reutilizadas.
Os requisitos também são classificados como requisitos de usuário e requisitos de sistema. Os requisitos de 
usuário descrevem o que se espera do sistema e quais são suas restrições. E os requisitos de sistema detalham as 
funções, restrições e serviços do sistema (SOMMERVILLE, 2011). 
Tanto os requisitos de usuário quanto o de sistema englobam os requisitos funcionais, não funcionais e de domínio. 
No entanto, no requisito de usuário, se usa uma linguagem mais simples, descrevendo o comportamento do 
sistema que deve ser compreendido pelos usuários, ou seja, não são usados termos técnicos. 
29
Análise de Sistemas | Unidade 2 - Apresentação da UML e Visão de Sistema
Os requisitos de sistema descrevem de forma mais detalhada os requisitos do usuário. Eles devem descrever 
todo o sistema e explicar detalhes dos requisitos. Também podem servir como contratos na implementação do 
sistema, por isso deve-se evitar termos muito técnicos.
 
Os requisitos funcionais, não funcionais e regras de negócio podem se confundir. Os 
requisitos nem sempre são claros de serem classificados.
Fique atento!
2.1.5.2 Caso de uso
Um caso de uso representa o comportamento do sistema pela perspectiva do usuário final. Assim, um caso de 
uso deve ser escrito para fornecer detalhes desse comportamento. O texto pode ser uma descrição a respeito das 
tarefas ou interações. Desse modo, alguns elementos devem estar presentes na descrição do caso de uso. 
Em todo caso de uso, existe a presença de atores. Os atores são as pessoas ou dispositivos que interagem 
com o sistema. Em geral, eles possuem papéis para operar o sistema. Apesar do ator exercer a funções de um 
usuário final, não significa que ele vai representar uma determinada pessoa, mas sim os papéis necessários para 
determinada função (PRESSMAN; MAXIM, 2016). 
Para exemplificar, imaginando o contexto de um sistema escolar acessado pela Internet, foram identificados os 
atores: professor, aluno, coordenador. O professor lança as aulas, notas e faltas dos alunos. Os alunos visualizam 
as aulas, notas e faltas. E o coordenador gerencia o curso, professores e turmas. Nesse caso, existem três atores, 
porém é comum que o coordenador também seja um professor. Dessa maneira, essa pessoa terá dois papéis, que 
são representados por dois atores diferentes no caso de uso: o de coordenador e o de professor, mesmo que esse 
usuário final seja uma única pessoa. 
Para ampliar o entendimento sobre os atores, é possível enriquecer ainda mais o exemplo. Suponha que 
esse sistema educacional precise trocar informações com o sistema da secretaria de educação para fornecer 
informações sobre os alunos da escola. Assim, o sistema da secretaria de educação terá de acessar os relatórios 
sobre os alunos e professores a partir do sistema educacional. Nesse caso, o sistema da secretaria de educação é 
considerado um ator, pois interage com as funcionalidades do sistema.
30
Análise de Sistemas | Unidade 2 - Apresentação da UML e Visão de Sistema
Nem sempre os atores são identificados nas primeiras interações com o cliente. Esses atores 
podem ir surgindo quando se aprende mais sobre o negócio do cliente. Assim, se descobre 
incialmente os atores primários e, posteriormente, os atores secundários, que fornecem 
suporte ao funcionamento do sistema.
Fique atento!
No exemplo do sistema educacional, foram fornecidas algumas informações sobre ele e como os atores interagem 
com o sistema. Por exemplo, foi dito que o professor lança as aulas dadas, as notas e as faltas dos alunos. Por 
meio dessas frases, é possível verificar a interação do professor com o sistema, fornecendo os conceitos para se 
desenvolver as funcionalidades do sistema. 
Para detalhar o caso de uso, além do ator, são necessárias que outras informações sejam fornecidas. Veja no 
Quadro 3 como são definidas as partes do caso de uso.
Quadro 3 – Elementos do caso de uso 
Ator Alguém ou algo que interage no sistema
Stakeholder Quem tem interesse no sistema
Ator primário Quem o ou que inicia a interação com o sistema
Caso de uso Funcionalidade com o comportamento do sistema
Escopo Identifica o sistema
Precondição O que deve existir para acionar o caso de uso
Cenário de sucesso principal Um caso em que nada acontece errado
Extensões O que pode acontecer de diferente durante aquele cenário
Fonte: Adaptado de COCKBURN, 2005. 
Um exemplo bastante simples dessa aplicação pode ser visto da seguinte forma: o professor (ator) lança nota 
(caso de uso). O caso de uso lançar nota pode ser identificado no escopo do sistema educacional.
31
Análise de Sistemas | Unidade 2 - Apresentação da UML e Visão de Sistema
Quadro 4 – Caso de uso
Ator: professor
Precondição: está no período de lançamento de notas
Cenário principal:
 1 – O professor acessou o caso de uso de lançamento de notas
 2 – O professor escolhe a turma
 3 – O sistema exibe os alunos com os campos de notas habilitados
 4 – O professor lança as notas dos alunos 
 5 – O sistema soma todas as notas de cada aluno e preenche o campo total para cada aluno
 6 – O professor salva o lançamento de nota
Extensão:
5a – O professor cancela o lançamento de notas
Fonte:Elaborado pelo autor.
O exemplo apresentado é um simples caso de uso para exemplo didático. De acordo com o exemplo, é possível 
ver o fluxo principal, que é o fluxo mais importante do caso de uso. Nele, são descritos os passos necessários para 
o funcionamento do sistema e os fluxos alternativos, que são as opções do caso de uso que podem ser acionados 
pelo ator. Além disso, estão presentes as regras de negócio, que são as regras do cliente, ou seja, elas existem 
mesmo sem a existência do sistema. E por último, o fluxo de exceção, que captura as exceções ou possíveis falhas 
que podem ocorrer no sistema durante a execução do caso de uso.
Existem muitos exemplos na Internet de como escrever casos de uso. Pesquise mais!
Saiba mais
2.1.5.3 Diagramas de caso de uso
Para representar os casos de uso, a UML possui um padrão de diagrama que é usado de modo gráfico para 
simbolizar e facilitar a comunicação no requisito. Ele deve ser usado para ilustrar o comportamento do sistema 
32
Análise de Sistemas | Unidade 2 - Apresentação da UML e Visão de Sistema
junto ao usuário. Assim, os elementos presentes nesse diagrama são: atores, casos de uso e as associações, 
conforme ilustra a Figura 9:
Figura 9 – Exemplo de caso de uso de sistema escolar – visão do professor
Professor
Lançar Nota
Lançar Falta
Registrar Conteúdo da Aula
Fonte: Elaborada pelo autor.
Os atores são representados por um “bonequinho”, já os casos de uso são representados por uma elipse. Repare 
que na Figura 9 existe uma linha ligando o ator ao caso de uso. No caso, essa linha é chamada de associação. 
A associação indica que o ator utiliza um determinado caso de uso. A associação pode estar relacionando não 
apenas atores e casos de uso, mas podem estar associados dois casos de uso ou dois atores. 
Existem outros tipos de associações que podem ser explorados no diagrama de caso de uso, como a generalização, 
inclusão e extensão. 
A generalização é usada para representar a herança. Nela, um ator pode herdar características de outro ator ou 
um caso de uso pode herdar atributos de outro caso de uso. 
A inclusão é indicada pela linha tracejada e pela palavra <include>. Essa associação indica que o caso de uso deve 
obrigatoriamente usar o outro caso de uso, também. 
Diferentemente da inclusão, a extensão indica que os recursos de outro caso de uso podem ser usados, mas não 
é obrigatória sua utilização. Ela é representada pela linha tracejada e pelo termo <<extend>>.
33
Análise de Sistemas | Unidade 2 - Apresentação da UML e Visão de Sistema
Figura 10 – Exemplo de caso de uso de sistema escolar – visão professor e coordenador
Professor
Coordenador
Lançar Nota
Lançar Falta
Registrar Conteúdo da Aula
Gerenciar curso
<<extend>>
<<include>>
Cadastrar disciplina
Gerenciar Professor Verificar Professor
Gerenciar Turma
Fonte: Elaborada pelo autor.
A Figura 10 exemplifica o que foi explicado de uma forma hipotética do sistema escolar descrito. Por meio desse 
diagrama, o coordenador herda todas as funcionalidades do professor. Assim, o coordenador tem seus casos 
de uso: gerenciar curso, gerenciar professor, gerenciar turma. Ele também pode executar os casos de uso de 
professor: lançar nota, lançar falta e registrar conteúdo da ala. Contudo, o ator professor não pode executar os 
casos de uso do coordenador. Observe que a seta entre o coordenador e professor é o que indica a generalização. 
Essa seta pode ser usada, também, para generalizar casos de uso. 
A Figura 11 mostra como um caso de uso pode estar relacionado a outro por meio da generalização. Nesse 
exemplo, o caso de uso lançar conceito herda as funcionalidades do caso de uso lançar nota para as disciplinas 
de educação física, ensino religioso e outras que utilizam conceitos em suas avaliações. 
Figura 11 – Exemplo de generalização entre casos de uso
Lançar Nota
Lançar Conceito
Fonte: Elaborado pelo autor.
34
Análise de Sistemas | Unidade 2 - Apresentação da UML e Visão de Sistema
Os casos de uso gerenciar professor e verificar professor na Figura 10 estão associados com o tipo de inclusão. 
Isso indica que, sempre que o coordenador for utilizar o caso de uso de gerenciar professor, é obrigatório chamar 
o caso de uso verificar professor. Dessa forma, é garantido que o professor exista no sistema.
Já os casos de uso gerenciar curso e cadastrar disciplina possuem uma associação de extensão. Nessa associação, 
durante o gerenciar curso, o coordenador pode precisar cadastrar alguma disciplina. Assim, ele tem como opção 
chamar o caso de uso cadastrar disciplina, ou seja, essa associação não obriga o ator usar o caso de uso.
Por meio do diagrama de caso de uso, o entendimento a respeito do funcionamento do sistema fica melhor 
representado. Esse diagrama permite obter a visão geral do sistema, a forma como usuário interage com ele e até 
como o sistema deve se comportar. Portanto, esse é um diagrama fundamental no levantamento de requisitos.
Síntese da unidade
Nesta unidade, você foi apresentado à linguagem UML e ao levantamento de requisitos. A UML fornece 
diagramas úteis para o desenvolvimento de sistemas. Já o requisito de sistemas é uma atividade complexa, que 
exige atenção do analista. Este, por sua vez, tem à sua disposição diversos recursos para realizar o levantamento 
e documentação de requisitos, que serão validados pelo cliente e construídos pela equipe de desenvolvimento.
35
Considerações finais
Esta unidade apresentou as informações a respeito do processo de 
levantamento de requisitos e das ferramentas e padrões da UML. Espera-se 
que os conhecimentos aqui abordados sejam bem aproveitados nos seus 
estudos e no meio profissional. É sempre bom lembrar que o conteúdo 
aqui presente não esgota o assunto. Dessa forma, é indicado que procure 
mais nas indicações do material e consulte as referências indicadas para 
ampliar os conhecimentos adquiridos.
36
 3Unidade 33. Modelagem Estrutural 
Para iniciar seus estudos
Nesta unidade, serão apresentados os diagramas de classe e objetos 
conforme a notação UML. Por meio desses diagramas, você será capaz 
de representar a estrutura de um sistema. Eles são a base fundamental do 
projeto de software. Essa estrutura permite que o sistema seja codificado 
para se tornar um produto. Então vamos conhecer mais?
Objetivos de Aprendizagem
• Descrever um projeto de software por meio de sua representação 
gráfica.
• Criar diagramas de classes e diagramas de objetos.
37
Análise de Sistemas | Unidade 3 - Modelagem Estrutural 
Introdução da unidade
Um projeto de software inicia-se na concepção do problema que o cliente almeja resolver com um sistema no 
qual são levantados os requisitos necessários para sua construção. Antes de iniciar a codificação desse sistema, é 
necessário que seja feito um projeto para estruturar a sua implementação.
Similar a um projeto de uma casa ou de um edifício, a construção de um sistema precisa ser bem planejada e 
estruturada para aumentar a qualidade do projeto, além de melhorar sua manutenção e reuso.
Assim, a UML tem um papel fundamental nesse processo, que é de estruturar esse sistema por meio do paradigma 
de orientação a objetos. A orientação a objetos utiliza-se de classes e objetos para trabalhar. Dessa forma, não é 
blasfêmia dizer que o diagrama de classes é o diagrama mais importante em um projeto de software orientado a 
objetos. 
No diagrama de classes, são expostas as classes que são abstrações do mundo real e suas propriedades e 
operações. Essa abstração fornece aos objetos as funcionalidades necessárias. Para desenvolver esses diagramas, 
é bom que se tenha boa noção sobre orientação a objetos, pois seus conceitos são amplamente utilizados por 
esses diagramas.
Tanto o analista de sistemas como o desenvolvedor devem ter conhecimento sobreesses diagramas. Por serem a 
base de todo sistema orientado a objetos, são bastante utilizados no mercado.
Assim, fique atento aos detalhes e exemplos apresentados nesta unidade. 
Bons estudos!
3.1 Projeto de software
Em projetos de software, são criados modelos úteis para a construção de sistemas. Após o levantamento de 
requisitos, é importante estruturar como o sistema será desenvolvido. Em um projeto orientado a objetos, 
os modelos que representam a estrutura do sistema são os modelos de classes e objetos. A UML dispõe de 
diagramas de classes e diagramas de objetos para fazer essa representação. Modelos são representações 
gráficas que descrevem o processo de negócio, o problema a ser resolvido e o sistema a ser desenvolvido 
(SOMMERVILLE, 2011).
A descrição dos requisitos do sistema é feita por meio de linguagem natural, que é a linguagem em que nos 
comunicamos, português, inglês, espanhol, etc. Os requisitos podem ainda conter diagramas para representar 
graficamente o escopo do sistema, definindo então o comportamento do sistema. Em outra perspectiva, 
têm-se os modelos nos quais a arquitetura do sistema ou a estrutura de dados é feita. Ressalta-se que esses 
modelos não exatamente devem ser criados após a fase de análise e que eles podem ser utilizados nessa fase 
para melhor compreensão do desenvolvimento. Em geral, esse fluxo ocorre conforme a figura 12:
38
Análise de Sistemas | Unidade 3 - Modelagem Estrutural 
Figura 12 – Metodologia do projeto de software
Requisitos Domínio Projeto
Fonte: Elaborado pelo autor
Durante os requisitos, são gerados os artefatos necessários para o entendimento do projeto, que pode conter 
o modelo de domínio, também chamado de modelo conceitual. Nesse modelo, as classes são apresentadas 
de forma simples, apenas para representar o entendimento do domínio de negócio. Já os diagramas de classe 
referentes ao projeto levam em consideração as tecnologias a serem utilizadas. As classes são melhores 
representadas com suas propriedades e comportamentos, gerando o diagrama de classe de especificação 
(WAZLAWICK, 2010).
O projeto de software é aplicado independentemente do modelo de processo de software. Assim, o projeto 
de software é uma atividade de modelagem que antecede a construção do sistema. Por meio do projeto é 
que os desenvolvedores serão guiados a codificar o sistema seguindo os requisitos e a arquitetura do projeto 
(PRESSMAN; MAXIM, 2016). O projeto de software deve garantir a qualidade do produto. Assim como na 
construção de uma casa, são feitas plantas da casa para se estruturar o que será construído, dessa maneira, 
pode-se ter uma visão do que deve ser feito, além de permitir estimar melhor o tempo e custo do projeto. 
Em desenvolvimento de sistemas, o projeto não é diferente, ele ajuda a equipe a visualizar como deve ser sua 
construção, além de permitir estimar melhor tempo e custo do projeto.
Por trabalhar com o paradigma de orientação a objetos, os diagramas UML tendem a aumentar a qualidade 
do produto, visto que sistemas orientados a objetos são mais fáceis de serem alterados. Em geral, há um 
mapeamento claro entre entidades do mundo real e os objetos do sistema, o que aumenta a compreensão 
e facilidade de manutenção. Objetos, ainda, são componentes reusáveis porque são encapsulados de forma 
independente de estado e operação. A reusabilidade reduz o custo de projeto, programação e validação, 
também reduz os riscos no desenvolvimento (SOMMERVILLE, 2011).
3.2 Diagrama de classe
O diagrama de classe é um diagrama UML que mostra uma visão estática do sistema. Como o próprio nome diz, 
esse diagrama estrutura de maneira lógica as classes de um sistema orientado a objetos. Na orientação a objetos, 
a classe contém os atributos e métodos, ou seja, eles descrevem as características e comportamentos de um 
objeto. Uma classe pode se relacionar com outra classe por meio de associações. Em um diagrama de classes, é 
exibido justamente o relacionamento entre as classes. 
No processo unificado, visto na unidade 1 desta disciplina, é sugerido que se crie o modelo conceitual na fase de 
análise. Esse modelo ajuda a identificar termos de negócio do cliente e mostra como os conceitos são relacionados. 
Assim, são modeladas as classes, atributos e os relacionamentos entre as classes. Contudo, o comportamento da 
classe é detalhado na fase de projeto, transformando o modelo conceitual em modelo de domínio, assim como o 
modelo conceitual pode ser usado para produzir o modelo lógico de banco de dados (GUEDES, 2014).
As classes de análise podem ser categorizadas da seguinte maneira (PRESSMAN; MAXIM, 2016):
39
Análise de Sistemas | Unidade 3 - Modelagem Estrutural 
• classes de entidade ou classes de modelo ou negócio, que representam o que deve ser armazenado no 
banco de dados;
• classes de fronteira são usadas para criar uma interface exibida ou interagida com o usuário, como uma 
tela ou relatório;
• classes de controle são usadas para gerenciar a criação ou atualização de objetos, instância de objetos de 
fronteira, comunicação entre conjuntos de objetos e validação dos dados
Para melhor compreender a estrutura de uma classe, são apresentados os conceitos de suas partes, como os 
atributos e métodos. No diagrama de classes, a classe é representada por um retângulo com duas divisões, a 
primeira divisão contém os atributos, e a segunda divisão, os métodos, conforme figura a seguir.
Figura 13 – Exemplo de classe - conta corrente
ContaCorrente
-numeroconta: Long
-saldo: Double
+consultarSaldo(): Double
+sacar(valor: Double): void
+depositar(valor: Double): void
Fonte: Elaborada pelo autor.
Seguindo a convenção da orientação a objetos, o nome das classes é escrito com a inicial 
da palavra em maiúsculo, e o restante, em minúsculo. Quando se tem junção de palavras, as 
duas iniciam com letra maiúscula, por exemplo, conta correte seria ContaCorrente. E o nome 
da classe deve ser único.
Fique atento!
3.2.1 Atributos ou propriedades
Os atributos (também chamados propriedades) definem uma classe. Por exemplo, toda conta corrente, para 
existir, deve ter um número que a identifica e um valor ou saldo. Observe que, antes dos nomes dos atributos, 
existe um sinal de menos (-) e, antes do nome dos métodos, existe um sinal de mais (+). Esses sinais indicam a 
visibilidade do atributo e do método. Eles podem ser privados (-), públicos (+), protegidos (#) ou ser acessados 
por qualquer objeto dentro do pacote (~). Isso indica a forma como eles estão encapsulados, ou seja, se podem 
ou não ser acessados. 
40
Análise de Sistemas | Unidade 3 - Modelagem Estrutural 
Quando se tem atributos privados, esses atributos só podem ser acessados pela própria classe, no caso de 
ContaCorrente somente ela pode acessar os atributos número e saldo, pois seus atributos estão como privados. 
Caso esses atributos fossem protegidos, as classes que derivam dessa classe poderiam utilizar esses atributos, 
mas como são privados, o uso desses atributos se limita à classe. Em contrapartida, os métodos estão como 
públicos. Isso significa que qualquer classe pode acessar esses métodos. 
Na orientação a objetos, é recomendado que os atributos estejam como privados ou protegidos, enquanto os 
métodos declarados, como públicos. Esse recurso diminui o acoplamento entre as classes, ou seja, um sistema 
com classes mais independentes (LOBO, 2009).
Além da visibilidade dos atributos, no diagrama de classe é definido o tipo que o atributo deve assumir. Esse tipo 
é justamente o tipo que o atributo assume em uma linguagem de programação, como integer, string, double, etc. 
Assim como o nome das classes, existe uma sugestão de padronização dos nomes dos atributos. Em geral, o 
nome do atributo é escrito com os caracteres em minúsculo, caso seja nome composto, o segundo nome terá o 
segundo carácter em maiúsculo, porexemplo, nomeContaCorrente.
3.2.1.1 Métodos ou operações
Os métodos também são chamados de operações ou comportamentos. Eles executam as funções de uma 
classe, no exemplo da figura Exemplo de classe: conta corrente, os métodos consultarSaldo(), sacar() e depositar() 
representam o comportamento que essa classe pode ter. Em outras palavras, toda conta corrente tem suas 
propriedades de número da conta e saldo, e o usuário é capaz de consultar o saldo dessa conta, sacar ou depositar 
um valor. Comparada com a programação estruturada, os atributos seriam as variáveis, e os métodos, as funções 
e procedimentos. As operações de uma classe podem ser divididas em quatro categorias (PRESSMAN; MAXIM, 
2016): 
1. operações que manipulam dados de alguma forma; 
2. operações que realizam um cálculo;
3. operações que pesquisam o estado de um objeto;
4. operações que monitoram um objeto em termos de ocorrência de um evento de controle.
Os métodos podem ou não receber parâmetros e devolvê-los. No caso do método sacar, ele recebe um valor 
que é a quantia que o usuário deseja retirar. O método sacar deve, então, apenas retirar o valor que está sendo 
informado. Ele recebe o parâmetro e não informa retorno, o termo void indica que ele não retorna valor. Já o 
método consultarSaldo() não está recebendo nenhum parâmetro, mas deve retornar um valor ao usuário do tipo 
Double. Ou seja, os métodos podem ou não ter tipos definidos, bem como os atributos.
3.2.2 Relacionamentos
Em um diagrama de classes, os seus relacionamentos mostram como elas são de fato utilizadas. Entre os 
relacionamentos, têm-se as associações, a generalização, a dependência, a agregação e a composição.
41
Análise de Sistemas | Unidade 3 - Modelagem Estrutural 
3.2.2.1 Associação
A associação entre duas classes indica que há uma relação estrutural entre elas e são representadas por uma 
linha cheia que liga uma classe a outra. Essa linha pode ser rotulada, e a seta em sua extremidade indica a sua 
navegabilidade. Uma associação sem seta indica uma associação bidirecional, mas pode significar também 
que a navegabilidade não é importante (PRESSMAN; MAXIM, 2016). Assim, uma associação com uma seta em 
sua extremidade indica que é associação unidirecional, e uma seta nas duas extremidades indica uma relação 
bidirecional. A seta indica que uma classe pode acessar de forma fácil a classe para qual a seta aponta (PRESSMAN; 
MAXIM, 2016). Na figura a seguir, por exemplo, a conta pode acessar facilmente a Agência, pois nessa classe ela 
possui conhecimento da agência, o mesmo não é verdade ao contrário, pois a agência não conhece diretamente 
a conta. Pensando em nível de código, a declaração do objeto agência estará na classe conta, mas o contrário 
não é verdadeiro.
As associações podem conter multiplicidade, indicando a quantidade de objetos que elas suportam. A 
multiplicidade pode ser definida pela seguinte cardinalidade:
• 0..1: possui nenhum ou um objeto.
• 1: pode ter apenas um objeto.
• 0..*: possui nenhum ou vários objetos.
• *: muitos objetos.
• 1..*: possui no mínimo um objeto e, no máximo, vários.
A figura a seguir mostra o relacionamento entre as classes:
Figura 14 – Associação entre as classes
Fonte: Elaborada pelo autor.
42
Análise de Sistemas | Unidade 3 - Modelagem Estrutural 
Essa figura exibe o relacionamento das classes por meio da associação e multiplicidade entre agência e conta. 
Nesse caso, o diagrama mostra uma navegação direcionada, na qual uma agência tem várias contas e uma conta 
tem apenas uma agência. Além da associação unidirecional, é possível utilizar associações bidirecionais quando é 
interessante mostrar a navegabilidade pelos dois sentidos. A associação bidirecional, em geral, não é tão simples 
de codificar, pois é necessário que as duas propriedades se mantenham sincronizadas e, em um dos lados da 
associação, é preciso controlar o relacionamento. 
Em alguns casos, é necessário que seja explicitada a classe de associação, sendo que as classes de associação 
são geralmente utilizadas em relacionamentos muitos para muitos. Em relacionamentos de um para muitos, 
por exemplo, se tem um relacionamento binário, ou seja, um relacionamento apenas com duas classes. Porém, 
pode acontecer de ser necessário ter mais de uma classe nos relacionamentos, então têm-se os relacionamentos 
n-ários. Comumente, são vistos os relacionamentos ternários com três classes e quaternários com quatro classes 
relacionadas. Uma classe pode se relacionar com ela mesma, com as mesmas propriedades da associação, nesse 
caso, tem-se o autorrelacionamento.
Um detalhe importante a ser observado na figura Associação entre as classes é que 
a classeConta é uma classe abstrata, isso quer dizer que ela não pode ser instanciada 
diretamente. Para isso, é necessário ser utilizada por uma classe concreta, como ContaCorrente 
e ContaPoupanca. A classe abstrata na UML é representada pelo nome da classe em itálico.
Fique atento!
3.2.2.2 Dependência
Pode-se representar uma dependência de uma classe a outra por meio de uma linha tracejada e esta pode ou 
não conter rótulos ou setas (PRESSMAN; MAXIM, 2016). Ao fazer esse tipo de relacionamento, ao alterar uma 
classe, torna-se quase obrigatório alterar a classe dependente também.
Apesar da dependência entre as classes parecer algo ruim, em geral ela é bastante comum. Várias razões levam 
a dependência entre as classes, como: uma classe que envia uma mensagem para outra; uma classe que tem 
a outra como parte de seus dados; uma classe menciona uma outra como um parâmetro de uma operação 
(FOWLER, 2014).
A dependência caminha em única direção, ou seja, não é um relacionamento transitivo. Assim, temos a 
dependência ilustrada pela figura a seguir. As alterações feitas na ClasseA refletem na ClasseC e ClasseB. O 
mesmo não ocorre se a alteração for feita na ClasseB, em que apenas a ClasseC sofre com as mudanças. Se as 
mudanças ocorrerem na ClasseC, nenhuma das outras sofre com a alteração.
 
43
Análise de Sistemas | Unidade 3 - Modelagem Estrutural 
Figura 15 – Relação de dependência em classes UML
Fonte: Elaborada pelo autor.
Na figura “Associação entre as classes”, existe também uma dependência sendo indicada. 
Você consegue identificá-la? Observe a relação que existe entre agência e banco.
3.2.2.3 Agregação
Uma agregação é um tipo de associação que indica uma relação “todo/parte”. Ela é representada por uma linha 
com um losango branco na ponta. A classe que está na extremidade do losango é considerada o todo, e o da 
outra extremidade é considerada a parte (PRESSMAN; MAXIM, 2016). Na agregação, a relação entre as classes é 
fraca, o que sugere que um pode existir sem o outro, como mostra a figura a seguir.
Figura 16 – Exemplo de agregação em UML
Fonte: Elaborada pelo autor.
No exemplo da figura Exemplo de agregação em UML, é possível ver como o relacionamento entre as classes é 
fraco. Um ônibus pode ter várias pessoas, no caso, passageiros, porém os passageiros existem sem o ônibus e o 
ônibus existe sem os passageiros. A agregação é uma associação difícil.
44
Análise de Sistemas | Unidade 3 - Modelagem Estrutural 
3.2.2.4 Composição
A composição, ao contrário da agregação, apresenta um forte relacionamento entre a parte e o todo. Em uma 
composição, as partes não fazem sentido sem o todo. Na UML, ela é representada por uma linha cheia e, na 
extremidade do todo, um losango preto, como mostra a figura a seguir.
Figura 17 – Exemplo composição em UML
Fonte: Elaborada pelo autor.
Conforme a figura apresentada, é visto um forte relacionamento entre uma nota fiscal e os itens da nota fiscal. 
Nesse exemplo, os itens da nota só fazem sentido estando na nota fiscal, e a nota fiscal precisa de itens para ser 
gerada.
Existe uma certa confusão entre o uso da agregação e da composição. O uso da agregação