MODELAGEM DO SISTEMA COM A ANÁLISE ORIENTADA A OBJETOS - APRENDIZAGEM EM FOCO

Prévia do material em texto

WBA0448_v1.0
MODELAGEM DO SISTEMA COM A 
ANÁLISE ORIENTADA A OBJETOS 
APRENDIZAGEM EM FOCO
2
APRESENTAÇÃO DA DISCIPLINA
Autoria: Iolanda Cláudia Sanches Catarino
Leitura crítica: Rogério Colpani
A disciplina de Modelagem do sistema com a análise orientada 
a objetos contempla uma visão da evolução da análise e do 
processo de desenvolvimento de software, enfatizando os 
fundamentos do paradigma orientado a objetos e abordando 
as técnicas de modelagem estrutural e comportamental da 
Linguagem de Modelagem Unificada (Unified Modeling Language 
– UML), visando a modelagem da fase de análise de sistemas 
orientados a objetos, independentemente do modelo de processo 
de software. No primeiro tema da disciplina contextualiza-se 
uma fundamentação sobre a evolução histórica dos paradigmas 
da análise e desenvolvimento de software, uma descrição das 
características dos principais métodos orientados a objetos 
que se destacaram na década de 1990 e apresentam-se as 
características, conceitos e pilares que sustentam o paradigma 
orientado a objetos. No segundo tema da disciplina apresenta-se 
uma visão geral de todas as técnicas de modelagem estrutural e 
comportamental da UML 2.5.1, totalizando os quatorze diagramas, 
sendo que os diagramas comportamentais se subdividem nos 
diagramas de interação. O terceiro tema da disciplina concentra-
se nas principais técnicas de modelagem comportamental da 
UML aplicadas à documentação da fase de análise, consistindo na 
definição, objetivo, notação gráfica e exemplo dos elementos das 
técnicas de – Diagrama de Casos de Uso, Diagrama de Atividade, 
Diagrama de Máquina de Estados e o Diagrama de Sequência. E 
por fim, o último tema da disciplina aborda as principais técnicas 
de modelagem estrutural da UML aplicadas à documentação da 
fase de análise, consistindo na definição, objetivo, notação gráfica 
3
e exemplo dos elementos das técnicas de – Diagrama de Pacotes, 
Diagrama de Classes e o Diagrama de Estrutura Composta.
INTRODUÇÃO
Olá, aluno (a)! A Aprendizagem em Foco visa destacar, de maneira 
direta e assertiva, os principais conceitos inerentes à temática 
abordada na disciplina. Além disso, também pretende provocar 
reflexões que estimulem a aplicação da teoria na prática 
profissional. Vem conosco!
TEMA 1
Análise e desenvolvimento de 
software orientado a objetos 
______________________________________________________________
Autoria: Iolanda Cláudia Sanches Catarino
Leitura crítica: Rogério Colpani
5
DIRETO AO PONTO
O processo de engenharia de software abrange todas as decisões 
que são tomadas quanto ao planejamento de execução do 
projeto, a definição do método com suas fases e técnicas de 
modelagem, ferramentas de desenvolvimento, tecnologias 
de implementação e testes e demais padrões necessários, 
decorrentes da complexidade e domínio de um sistema de 
software. A evolução histórica dos paradigmas da análise e 
desenvolvimento de software fundamenta-se nas análises 
Estruturada, Essencial e Orientada a Objetos, a partir da década de 
1970.
A Análise Estruturada, no início da década de 1970, tem como 
foco os elementos processos e dados em estruturas separadas, 
abstraindo o mundo real, com base em processos e fluxos de 
dados com detalhamento top-down, ou seja, do nível macro para 
os menores detalhes, contudo a programação era implementada 
de forma modular com refinamentos sucessivos, acarretando 
problemas de decomposição funcional. A Análise Estruturada 
Essencial ou Moderna, na década de 1980, caracteriza-se por 
ser uma evolução da Análise Estruturada. A Análise Orientada 
a Objetos emergiu entre meados da década de 1980 e 1990, 
acompanhando a evolução das linguagens de programação 
orientadas a objetos, consolidando-se um novo paradigma de 
desenvolvimento de software. A orientação a objetos concentra-
se no elemento objeto, considerado uma unidade autônoma, que 
contém tanto a estrutura dos dados como o seu comportamento, 
que é representado pelas operações, assim realizando suas 
tarefas de forma colaborativa, resultando nas funcionalidades do 
sistema de software. 
6
Na década de 1990 surgiram diversos métodos para apoiar 
o paradigma orientado a objetos, sendo que as técnicas de 
modelagem específicas para documentarem as fases de análise 
e projeto se relacionam e são consistentes, enfatizando as 
perspectivas estática e dinâmica da modelagem do software. De 
uma forma geral, a modelagem da fase de análise documenta a 
visão lógica do software, ou seja, a identificação e definição do 
domínio do problema, especificando os requisitos de sistema; 
e a modelagem da fase de projeto documenta a visão física do 
software, com um refinamento da documentação elaborada 
na fase de análise, complementando-a com definições das 
tecnologias de linguagens de programação, frameworks, patterns, 
componentes de software e banco de dados que serão adotados 
para implementação do software, ou seja, define-se o domínio da 
solução. O Quadro 1 apresenta a relação dos métodos orientados 
a objetos mais conhecidos com o ano de lançamento.
Quadro 1 – Métodos Orientados a Objetos
Ano Métodos
1988 Shlaer e Mellor (Sally Shlaer e Stephen Mellor)
1990 Rebecca Wirfs-Brock
1991 Grady Booch
1991 Object Modelling Technique (OMT) de James Rumbaugh, 
Michael Blaha, William Premerlani, Frederick Eddy e 
William Lorensen
1992 Object-Oriented Software Enginneering (OOSE) e o 
Objectory de Ivar Jacobson
1992 Coad e Yourdon (Peter Coad e Edward Yourdon)
1993 Martin e Odell (James Martin e James J. Odell)
1994 Fusion de Derek Coleman
1997 Unified Modeling Language (UML) de Grady Booch, 
James Rumbaugh e Ivar Jacobson
Fonte: elaborado pela autora.
7
Para assegurar o sucesso do desenvolvimento orientado a 
objetos é importante compreender os conceitos básicos que 
fundamentam o paradigma orientado a objetos. Um objeto pode 
ser definido como qualquer coisa concreta ou abstrata do mundo 
real, com características e comportamento próprio em uma única 
estrutura, sendo possível identificá-lo. O conceito de abstração 
consiste na concentração dos aspectos importantes e relevantes 
dos objetos, considerando o contexto analisado e o domínio do 
sistema. Uma classe representa um grupo de objetos do mundo 
real que possui tipos de características e de comportamento em 
comum, sendo que as características descrevem os atributos 
ou propriedades dos objetos e o comportamento descreve 
as operações. Cada ocorrência de um objeto representa uma 
instância da classe. 
Um atributo descreve uma característica possuída por todos 
os objetos de uma classe, assumindo valores específicos para 
cada objeto. Uma operação descreve uma ação que o próprio 
objeto executa ou uma ação que o objeto pode executar, a 
partir do disparo de um evento, ou seja, é uma ordem que faz 
o objeto reagir decorrente do acontecimento de um evento, 
sendo compartilhada por todos os objetos da mesma classe. 
O mecanismo de invocação de uma operação representa uma 
mensagem enviada, sendo a forma de conseguir executar um 
método. A implementação de uma operação é chamada de 
método. 
Eventos são os acontecimentos que provocam a mudança de 
estado dos objetos. Um evento ao ser disparado envia uma 
mensagem, invocando uma operação dos objetos de uma 
classe, assim provocando a mudança de estado do objeto. Um 
estado representa a abstração de uma forma de apresentação 
dos objetos em um instante de tempo com uma duração, 
demostrando a reação de um objeto em resposta a um evento. 
8
Uma transição de estado representa a mudança de estado de um 
objeto em resposta a um evento disparado. 
O conceito de encapsulamento representa o ato de reunir, em 
uma estrutura chamada classe, os atributos e operações dos 
objetos, permitindo que um objeto proteja a integridade de suas 
partes. O objetivo do encapsulamento é restringir a visibilidade ou 
escopo das informações dos objetos de uma classe, sendo que a 
única maneira de acessar as operações de um objeto é por meio 
de interfacesfornecidas pelo objeto. O conceito de generalização, 
também denominado de herança, representa a propriedade pela 
qual uma classe pode herdar atributos e operações de uma classe 
que generaliza as características e comportamentos comuns 
de um grupo de objetos. Por fim, o conceito de polimorfismo 
significa que a mesma operação pode atuar de diversas formas 
em classes distintas. Uma operação polimórfica possui o mesmo 
nome em classes distintas, mas em cada classe o método 
implementado é diferente. O polimorfismo está associado ao 
conceito de herança.
Referências bibliográficas
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. 2. 
ed. Rio de Janeiro: Campus, 2006. 
GUEDES, G. T. A. UML: uma abordagem prática. 3. ed. São Paulo: 
Novatec, 201. 
PARA SABER MAIS
O cenário competitivo do mercado, diante da transformação 
digital dos negócios, requer das organizações flexibilidade e 
9
adaptabilidade para aperfeiçoarem constantemente os seus 
processos e forma de gestão. Para apoiar a especificação dos 
processos de negócio de uma organização, a Modelagem 
Organizacional visa facilitar a compreensão do ambiente 
organizacional e é reconhecida como uma importante 
atividade pela Engenharia de Requisitos, para obter uma 
melhor compreensão sobre os relacionamentos entre os níveis 
organizacionais e funcionais do ambiente, compreendendo, assim, 
as razões envolvidas nos processos de decisões e as complexas 
interações entre a organização e as pessoas. 
Entre os vários métodos para conceber a Modelagem 
Organizacional, o método Enterprise Knowledge Development (EKD) 
facilita a aquisição do conhecimento da estrutura organizacional 
e estratégica e auxilia na captura dos requisitos organizacionais, 
possibilitando a compreensão das necessidades do ambiente 
empresarial por parte de todos os envolvidos na modelagem de 
processos de negócio, e consequentemente, na especificação dos 
requisitos de um sistema de informação (GUERRINI et al., 2014).
Para fazer a identificação dos requisitos de um sistema 
computacional e descrever os processos de negócio de uma 
organização, existem diversas técnicas ou procedimentos que 
podem ser utilizados. As técnicas “têm a finalidade de promover 
a compreensão do analista de processos sobre a ordem, a 
hierarquia e a sequência lógica das atividades necessárias a uma 
unidade organizacional, para a produção de bens ou a prestação 
de serviços” (VALLE; OLIVEIRA, 2013, p. 28).
Um processo de negócio é um conjunto de atividades ou tarefas 
estruturadas relacionadas que produzem um serviço ou produto 
específico para seus clientes, demonstrando o que deve ser 
realizado, como deve ser realizado e quem é o responsável. Os 
processos de negócio são classificados quanto a sua qualificação 
10
Lorem ipsum dolor sit amet
Autoria: Nome do autor da disciplina
Leitura crítica: Nome do autor da disciplina
em: Primários ou de Negócios, Apoio ou Suporte e Gerencial 
(VALLE; OLIVEIRA, 2013). A Modelagem de Processos de Negócio 
(Business Process Modeling - BPM) visa criar um modelo de 
processos por meio da construção de diagramas operacionais 
sobre seu comportamento.
O Business Process Modeling Notation (BPMN) é um padrão para 
modelagem de processos de negócio. Segundo Valle e Oliveira 
(2013), o BPMN tem a finalidade de criar uma linguagem única 
e padrão para a modelagem de processos de negócio capaz de 
facilitar o entendimento e treinamento do usuário. O BPMN possui 
um único modelo de diagrama, chamado de Business Process 
Diagram (BPD - Diagrama de Processo de Negócio), que oferece 
recursos para a modelagem dos mais variados tipos de processos, 
desde os mais genéricos aos específicos.
Referências bibliográficas
GUERRINI, F. M. et al. Modelagem da organização: uma visão 
integrada. Porto Alegre: Bookman, 2014.
VALLE, R.; OLIVEIRA, S. B. de (Org.). Análise e modelagem de 
processos de negócio: foco na notação BPMN (Business Process 
Modeling Notation). São Paulo: Atlas, 2013.
TEORIA EM PRÁTICA
Considere a necessidade de desenvolver um sistema de 
informação para uma empresa que atua no segmento de 
organização e realização de eventos científicos. Com base na 
descrição do contexto do sistema a seguir, faça: 
11
a. Listagem dos requisitos funcionais.
b. Representação do nome das classes e suas relações.
O sistema deve controlar a submissão e avaliação de trabalhos 
para eventos científicos. Um autor pode realizar muitas 
submissões, a partir do envio de seu trabalho, respeitando o 
deadline do evento. Existem três tipos válidos de submissão de 
trabalhos: artigos curtos ou longos, cursos ou palestras. Um autor 
ou avaliador deve se cadastrar no sistema, criando o seu login e 
senha. Uma submissão pode ser elaborada por mais de um autor, 
totalizando cinco autores, no máximo, com a indicação de um 
autor responsável pela submissão. Toda submissão é avaliada por 
uma comissão de três avaliadores, considerando a atribuição de 
uma nota para diferentes quesitos de qualidade do trabalho. É de 
responsabilidade do coordenador do evento notificar os autores 
sobre a aceitação ou não de suas submissões no evento.
Para conhecer a resolução comentada proposta pelo 
professor, acesse a videoaula deste Teoria em Prática no 
ambiente de aprendizagem.
LEITURA FUNDAMENTAL
Indicação 1
O Capítulo 2 - Identificando e classificando os processos de sua 
organização tem como objetivo compreender as maneiras de 
identificar e classificar os processos de negócios organizacionais, 
com base no padrão de referência Process Classification Framework 
(PCF) da American Productivity and Quality Control, bastante aceito 
e utilizado por várias organizações em todo o mundo. No Capítulo 
Indicações de leitura
12
3 - Qualificando os processos de sua organização, você conhecerá 
outro tipo de classificação de processos, com base na qualificação 
de processos.
Para realizar a leitura, acesse a plataforma Biblioteca Virtual da 
Kroton/Minha Biblioteca/Acessar Portal e busque pelo título da 
obra.
VALLE, R.; OLIVEIRA, S. B. de (Org.). Análise e modelagem de 
processos de negócio: foco na notação BPMN (Business Process 
Modeling Notation). São Paulo: Atlas, 2013.
Indicação 2
O Capítulo 5 – Uma introdução à notação BPMN, tem como objetivo 
apresentar a notação dos elementos básicos da modelagem de 
processos, e o Capítulo 6 – Conhecendo melhor a notação BPMN, 
descreve os elementos por função de representação para elaborar 
o Business Process Diagram (BPD - Diagrama de Processo de 
Negócio). Para realizar a leitura, acesse a plataforma Biblioteca 
Virtual da Kroton/Minha Biblioteca/Acessar Portal e busque pelo 
título da obra.
CAMPOS, A. L. N. Modelagem de processos com BPMN. 2. ed. Rio 
de Janeiro: Brasport, 2014. 
QUIZ
Prezado aluno, as questões do Quiz têm como propósito a 
verificação de leitura dos itens Direto ao Ponto, Para Saber 
13
Mais, Teoria em Prática e Leitura Fundamental, presentes 
neste Aprendizagem em Foco.
Para as avaliações virtuais e presenciais, as questões serão 
elaboradas a partir de todos os itens do Aprendizagem em 
Foco e dos slides usados para a gravação das videoaulas, 
além de questões de interpretação com embasamento no 
cabeçalho da questão.
1. O paradigma orientado a objetos fundamentou-se nas 
características das linguagens de programação que ganharam 
grande visibilidade na década de 1980. Posteriormente, 
surgiram diversos métodos de desenvolvimento de software 
orientado a objetos. 
 
Assinale a alternativa correta que descreve os pilares do 
paradigma orientado a objetos. 
a. Abstração, Objeto, Classe e Processo.
b. Abstração, Encapsulamento, Herança e Polimorfismo.
c. Classe, Herança, Generalização e Especialização.
d. Encapsulamento, Transição, Método e Mensagem.
e. Encapsulamento, Polimorfismo, Agregação e Composição. 
2. Um processo organizacional pode ser definido como um 
conjunto de atividades preestabelecidas que, quando 
executadas numa determinada sequência, conduzem a 
um resultado esperado e asseguramo atendimento das 
necessidades e expectativas dos clientes e demais partes 
envolvidas no processo. 
 
14
Assinale a alternativa correta que indica a classificação 
dos tipos de processos organizacionais, quanto a sua 
qualificação:
a. Operacionais, Táticos e Estratégicos.
b. Operacionais, Funcionais e Analíticos.
c. Primários ou Essenciais, Suporte e Negócio.
d. Primários ou de Negócios, Apoio e Gerencial.
e. Essenciais, Secundários e Estratégicos. 
GABARITO
Questão 1 - Resposta B
Resolução: Dos conceitos básicos da orientação a objetos, 
os conceitos de Abstração, Encapsulamento, Herança e 
Polimorfismo que são considerados os pilares do paradigma 
orientado a objetos, porque eles se aplicaram no elemento 
principal do paradigma, o conceito de objeto, com isso 
sustentam os princípios-chave do paradigma: Reusabilidade, 
Extensibilidade, Confiabilidade e Manutenibilidade. 
Questão 2 - Resposta D
Resolução: Uma das maneiras de classificar os processos 
organizacionais é usando a Arquitetura PCF da Process 
Classification Framework (PCF) da American Productivity 
and Quality Control, bastante aceita e utilizada por várias 
organizações do mundo. Outra classificação conhecida na 
literatura, é denominada de classificação por qualificação, 
que considera certas características que permitem fazer a sua 
qualificação, distinguindo os processos organizacionais em: 
Primários ou de Negócios, Apoio ou Suporte e Gerencial.
15
Segundo Valle e Oliveira (2013), os:
Processos Primários ou de Negócios: são aqueles que 
abrangem as atividades essenciais que uma organização 
precisa realizar para cumprir sua missão de negócio, gerando 
valor à entrega final para o cliente. Exemplo: manufatura de 
produtos e serviços de pós-venda.
Processos de Apoio ou Suporte: são aqueles que ajudam ou 
facilitam a execução dos Processos Primários. Não oferecem 
valor diretamente ao cliente final, mas garantem o sucesso 
dos processos primários. Exemplo: Gestão de Recursos 
Humanos e Gestão de TI.
Processos de Gerenciamento: são aqueles que medem, 
monitoram e controlam as atividades de uma organização. 
São parecidos com os Processos de Suporte, pois não 
agregam valor ao cliente, mas a outros processos, como os 
Processos Primários e os Processos de Suporte. Exemplos: 
Governança Corporativa e Gestão de Performance.
TEMA 2
Linguagem de Modelagem 
Unificada (UML): modelagem 
comportamental e estrutural de 
software
______________________________________________________________
Autoria: Iolanda Cláudia Sanches Catarino
Leitura crítica: Rogério Colpani
17
DIRETO AO PONTO
A Linguagem de Modelagem Unificada (UML – Unified Modeling 
Language) consiste da união dos métodos de Grady Booch, James 
Rumbaugh (OMT- Object Modeling Technique) e Ivar Jacobson (OOSE 
– Object-Oriented Software Engineering), sendo uma linguagem 
para especificação, visualização e documentação de software 
orientado a objetos, apoiando o desenvolvimento incremental, 
com base em modelos que podem evoluir com a inclusão de 
novos detalhes, contudo não estão vinculados exclusivamente a 
uma fase do processo de desenvolvimento de software, definindo 
quem deve fazer o que, quando e como. Atualmente, a Agência 
Americana de Padrões - Object Management Group (OMG) é a 
organização internacional responsável em manter e administrar a 
UML, e desde o seu lançamento, várias atualizações foram feitas, 
sendo que a versão 2.0 foi oficialmente apresentada em 2005 e 
atualmente a versão 2.5.1 foi lançada em dezembro de 2017.
A UML fornece múltiplas visões da modelagem do sistema 
sob diferentes aspectos de análise e detalhamento e privilegia 
a descrição da modelagem de sistemas de software em três 
perspectivas principais de visões. A estrutural, que enfatiza a 
visão estática do sistema, ou seja, os dados; a funcional, que 
prioriza as funcionalidades do sistema, enfatizando os requisitos 
funcionais; e a temporal, que prioriza a especificação dos eventos, 
representando o comportamento dos objetos em tempo de 
execução.
A UML 2.0 abrange as técnicas de modelagem classificadas em 
estruturais e comportamentais. A UML não faz grande distinção 
entre a modelagem das fases de Análise e Projeto de um processo 
de desenvolvimento de software. A atividade de Projeto é uma 
extensão refinada dos diagramas elaborados na fase de Análise 
18
com detalhes de implementação. As técnicas de modelagem 
comportamentais representam o comportamento e a interação 
entre os elementos do sistema, colaborando para modelagem da 
visão dinâmica do sistema. A perspectiva de interação representa 
um subgrupo dos diagramas comportamentais, que mostra a 
interação de como os objetos do sistema agem internamente 
para apoiarem a realização das funcionalidades representadas 
pelos casos de uso. As técnicas de modelagem estruturais da 
UML demostram a estrutura das classes e do software, a partir da 
identificação dos objetos do sistema, representando a modelagem 
com visão estática do sistema. O Quadro 1 a seguir apresenta as 
técnicas de modelagem comportamental e estrutural da UML.
Quadro 1 – Classificação dos diagramas da UML 2.5
Diagrama de Casos de Uso Representa as funcionalidades 
ou serviços do software e suas 
interações com os atores do 
sistema. É o diagrama mais 
geral e informal da UML.
Diagrama de Atividades Demonstra o fluxo de controle 
de um conjunto de atividades 
que representa a execução 
de um procedimento, caso 
de uso, processo de negócio, 
subsistema ou até o sistema 
completo.
Diagrama de Máquina de 
Estados
Demonstra o comportamento 
de um elemento – objeto ou 
caso de uso, por meio de um 
conjunto de transições de 
estados, em um determinado 
período de tempo.
Diagramas Comportamentais
19
Diagrama de Sequência Representa a ordem temporal 
em que as mensagens são 
trocadas entre os objetos 
envolvidos na execução de um 
caso de uso.
Diagrama de Comunicação Representa o inter-
relacionamento entre os 
objetos envolvidos na execução 
do caso de uso, com a troca de 
mensagens. 
Diagrama de Visão Geral de 
Interação
Demostra uma variação do 
Diagrama de Atividades, 
utilizando quadros no lugar 
dos nós de ação e integrando 
diferentes tipos de diagramas 
de interação para representar 
um processo geral.
Diagrama de Tempo Representa de forma concisa e 
simples à mudança no estado 
de um objeto durante um 
período de tempo em que um 
objeto executa algo importante, 
em resposta aos eventos 
disparados.
Diagrama de Pacotes Demonstra como os 
elementos do sistema estão 
organizados em pacotes e 
suas dependências, ou seja, 
categorizados em grupos de 
elementos que representam as 
partes do sistema.
Diagramas Comportamentais de Interação
Diagramas Estuturais
20
Diagrama de Classes Representa um conjunto de 
classes com seus atributos, 
operações e relacionamentos, 
demostrando a modelagem da 
visão estática dos objetos do 
sistema.
Diagrama de Objetos Representa instâncias do 
Diagrama de Classes, com 
base na descrição dos valores 
dos atributos dos objetos e os 
vínculos estabelecidos entre os 
objetos.
Diagrama de Estrutura 
Composta
Representa as colaborações 
entre elementos que cooperam 
entre si para executarem uma 
função específica.
Diagrama de Componentes Representa os aspectos físicos 
do sistema, demonstrando 
a visão estática de 
implementação do sistema, 
com a reutilização de 
componentes.
Diagrama de Implantação Demonstra a organização da 
arquitetura física do sistema, 
com base na representação de 
Nós que representam um item 
de hardware do sistema, um 
dispositivo ou os ambientes 
de execução que integram o 
sistema.
21
Diagrama de Perfil Demostra a criação de uma 
extensão da notação da UML, 
para domínios de software 
com características específicas, 
representadas por estereótipos.
Fonte: elaborado pela autora.
A representação do Diagrama de Casos de Uso é complementada 
com a Documentação de Casos de Uso, que pode ser 
demonstrada em formatos distintos, descrevendo oseventos que 
são disparados durante a execução do Caso de Uso, de forma 
textual detalhada ou não, contudo, respeitando uma sequência 
lógica temporal de execução dos eventos. O Diagrama de 
Sequência baseia-se no Diagrama de Casos de Uso, elaborando 
normalmente um Diagrama de Sequência para cada caso de uso e 
apoiando-se no Diagrama de Classes para determinar os objetos 
das classes envolvidas no processo. E o Diagrama de Comunicação 
é uma outra perspectiva de visão da troca de mensagens entre os 
objetos.
Referências bibliográficas
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. 2. 
ed. Rio de Janeiro: Campus, 2006. 
GUEDES, G. T. A. UML: uma abordagem prática. 3. ed. São Paulo: 
Novatec, 2018. 
22
PARA SABER MAIS
Ao longo da história da engenharia de software, os modelos de 
processo evoluíram para atenderem de forma eficaz as inúmeras 
características, domínios e tecnologias de desenvolvimento de 
software. Segundo Pressman e Maxim (2016, p. 40) “um modelo 
de processo fornece um guia específico para o trabalho de 
engenharia de software. Ele define o fluxo de todas as atividades, 
ações e tarefas, o grau de iteração, os artefatos e a organização do 
trabalho a ser feito”.
Com o desenvolvimento de softwares orientado a objetos, o 
modelo de processo denominado Processo Unificado (PU - Unified 
Process) surgiu para apoiar a Linguagem de Modelagem Unificada 
(UML - Unified Modeling Language), enfatizando as características 
de desenvolvimento dirigido a casos de uso, centrado na 
arquitetura, iterativo e incremental, e fornecendo uma forma 
sistemática e evolutiva de modelar sistemas com a UML. 
O PU consiste na repetição de ciclos durante o processo de 
desenvolvimento do software, permitindo um acompanhamento 
efetivo de projetos grandes e complexos. Cada ciclo do PU é 
concluído com uma versão pronta do produto para distribuição, 
conhecido como uma iteração, e é subdividido em quatro fases 
sucessivas: Concepção, Elaboração, Construção e Transição. 
Cada fase, por sua vez, constitui cinco atividades (workflows) do 
processo: Requisitos, Análise e Projeto, Implementação e Testes. 
As fases tratam a dimensão do tempo de execução e as atividades 
são executadas de forma incremental e evolutiva, representando 
a entrega dos artefatos de software. A Figura 1 representa o PU, 
sendo que a ênfase sobre as várias atividades muda em cada fase 
do processo.
23
Na fase de Concepção define-se a ideia inicial do negócio, o 
domínio do problema e a delimitação do escopo e planejamento 
do projeto. Identifica-se os atores do sistema, definindo a natureza 
dessa interação em uma perspectiva de alto nível e elenca-
se os principais casos de uso do sistema. A atividade principal 
da fase de Concepção está no entendimento dos requisitos e a 
descrição do escopo do projeto. Na fase de Elaboração define-
se o comportamento funcional dos requisitos do sistema, 
estabelecendo a arquitetura e mecanismos do domínio do 
problema, consolidando a fase de concepção e agregando valor a 
cada iteração-incremento desenvolvido. As atividades da fase de 
Elaboração asseguram a consistência dos requisitos do sistema 
com as necessidades dos usuários, definindo a previsão de custos 
e prazos para a conclusão do desenvolvimento. As principais 
atividades da fase de Elaboração são a especificação dos requisitos 
funcionais do sistema, na atividade de Requisitos, e a especificação 
da modelagem das atividades de Análise e Projeto, contudo alguns 
artefatos de projeto e implementação são produzidos com o 
intuito de prototipar uma versão do software.
24
Figura 1 – Processo Unificado
 
Fonte: Medeiros (2004, p. 16).
Na fase de Construção define-se uma arquitetura executável do 
software com a implementação e testes das funcionalidades 
do sistema. Nesta fase, as principais atividades do processo se 
concentram no projeto e na implementação, visando evoluir e 
melhorar o protótipo inicial, obtendo uma versão operacional do 
software. Na fase de Transição o sistema é disponibilizado aos 
usuários e a demanda de novas funcionalidades ou adequações 
são acompanhadas. Nesta fase, a principal atividade do processo é 
a realização de testes.
Referências bibliográficas
MEDEIROS, E. S. de. Desenvolvendo software com UML 2.0: 
definitivo. São Paulo: Pearson, 2004.
25
PRESSMAN, R.; MAXIM, B. Engenharia de software: uma 
abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016.
TEORIA EM PRÁTICA
Considere a necessidade de desenvolver um sistema de 
informação para uma empresa que atua no segmento de 
organização e realização de eventos científicos.
Com base na descrição do contexto do sistema a seguir, elabore 
o Diagrama de Casos de Uso correspondente à atividade de 
Requisitos do Processo Unificado, considerando os seguintes 
requisitos funcionais já identificados: Manter Evento, Manter 
Tema de Trabalho, Manter Tipo de Evento, Manter Autor, Manter 
Instituição de Ensino, Manter Avaliador, Manter Especialidade de 
Avaliador, Manter País, Manter Requisito da Avaliação, Manter 
Usuário, Logar Sistema, Submeter Trabalho, Avaliar Trabalho, 
Registrar Comentário de Trabalho, Aprovar Trabalho e Notificar 
Autor de Trabalho.
O sistema deve controlar a submissão e avaliação de trabalhos 
para eventos científicos. Um autor pode realizar muitas 
submissões, a partir do envio de seu trabalho, respeitando o 
deadline do evento. Existem três tipos válidos de submissão de 
trabalhos: artigos curtos ou longos, cursos ou palestras. Um autor 
ou avaliador deve se cadastrar no sistema, criando o seu login e 
senha. Uma submissão pode ser elaborada por mais de um autor, 
totalizando cinco autores, no máximo, com a indicação de um 
autor responsável pela submissão. Toda submissão é avaliada por 
uma comissão de três avaliadores, considerando a atribuição de 
uma nota para diferentes quesitos de qualidade do trabalho. É de 
26
responsabilidade do coordenador do evento notificar os autores 
sobre a aceitação ou não de suas submissões no evento.
Para conhecer a resolução comentada proposta pelo 
professor, acesse a videoaula deste Teoria em Prática no 
ambiente de aprendizagem.
LEITURA FUNDAMENTAL
Indicação 1
O Capítulo 9 – Modelagem de requisitos: métodos baseados em 
cenários, tem como objetivo conhecer e compreender alguns 
métodos para o levantamento e documentação da análise de 
requisitos, a partir de técnicas que enfatizam a especificação dos 
requisitos funcionais do sistema, no formato de descrição de 
cenários, complementando-as com técnicas gráficas, no formato 
de diagramas.
Para realizar a leitura, acesse a plataforma Biblioteca Virtual da 
Kroton/Minha Biblioteca/Acessar Portal e busque pelo título da 
obra.
PRESSMAN, R.; MAXIM, B. Engenharia de software: uma 
abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016.
Indicação 2
O Capítulo 9 – Casos de Uso, tem como objetivo apresentar a técnica 
de modelagem – Diagrama de Casos de Uso, adotada principalmente 
Indicações de leitura
27
para modelar os requisitos funcionais de sistemas de software. O 
capítulo apresenta os conceitos, notação e exemplos do Diagrama 
de Casos de Uso. Para realizar a leitura, acesse a plataforma 
Biblioteca Virtual da Kroton/Minha Biblioteca/Acessar Portal e 
busque pelo título da obra.
FOWLER, M. UML essencial: um breve guia para a linguagem-
padrão de modelagem de objetos. 3. ed. Porto Alegre, Bookman, 
2005. 
QUIZ
Prezado aluno, as questões do Quiz têm como propósito a 
verificação de leitura dos itens Direto ao Ponto, Para Saber 
Mais, Teoria em Prática e Leitura Fundamental, presentes 
neste Aprendizagem em Foco.
Para as avaliações virtuais e presenciais, as questões serão 
elaboradas a partir de todos os itens do Aprendizagem em 
Foco e dos slides usados para a gravação das videoaulas, 
além de questões de interpretação com embasamento no 
cabeçalho da questão.
1. A Linguagem de Modelagem Unificada (UML) 2.0 abrange 
as técnicas de modelagem classificadas em estrutural e 
comportamental. As técnicasestruturais demonstram a 
estrutura das classes e do software, com base na identificação 
dos objetos do sistema, representando a modelagem com 
visão estática do sistema. 
 
Assinale a alternativa correta que relaciona algumas técnicas 
estruturais: 
28
a. Diagrama de Casos de Uso; Diagrama de Atividades; 
Diagrama de Sequência.
b. Diagrama de Casos de Uso; Diagrama de Sequência; 
Diagrama de Comunicação.
c. Diagrama de Pacotes; Diagrama de Objetos; Diagrama de 
Classes.
d. Diagrama de Componentes; Diagrama de Classes; Diagrama 
de Máquina de Estados.
e. Diagrama de Classes; Diagrama de Casos de Uso; Diagrama 
de Tempo. 
2. Com o desenvolvimento de softwares orientado a objetos, 
o Processo Unificado (PU) surgiu para apoiar a Linguagem 
de Modelagem Unificada (UML). O PU faz uma distinção 
entre fases e atividades, considerando que as fases de 
Concepção, Elaboração, Construção e Transição tratam a 
dimensão do tempo de execução, enquanto as atividades 
de Requisitos, Análise e Projeto, Implementação e 
Testes são executadas de forma incremental e evolutiva, 
representando a entrega dos artefatos de software. 
 
Assinale a alternativa correta que indica as atividades 
principais que são executadas na fase de Elaboração.
a. Requisitos; Testes.
b. Requisitos; Análise e Projeto.
c. Análise e Projeto; Implementação.
d. Análise e Projeto; Testes.
e. Análise e Projeto; Testes. 
29
GABARITO
Questão 1 - Resposta C
Resolução: Das 14 técnicas de modelagem da UML, são 
técnicas estruturais: Diagrama de Pacotes, Diagrama de 
Objetos, Diagrama de Classes, Diagrama de Estrutura 
Composta, Diagrama de Componentes, Diagrama de 
Implantação e o Diagrama de Perfil, que foi introduzido na 
versão 2.5 da UML. 
Questão 2 - Resposta B
Resolução: Na fase de Elaboração define-se o 
comportamento funcional dos requisitos do sistema, 
estabelecendo a arquitetura e mecanismos do domínio do 
problema, consolidando a fase de concepção e agregando 
valor a cada iteração-incremento desenvolvido. As atividades 
da fase de Elaboração asseguram a consistência dos 
requisitos do sistema com as necessidades dos usuários, 
definindo a previsão de custos e prazos para a conclusão 
do desenvolvimento. As principais atividades da fase de 
Elaboração são a especificação dos requisitos funcionais 
do sistema, na atividade de Requisitos, e a especificação da 
modelagem das atividades de Análise e Projeto, contudo 
alguns artefatos de projeto e implementação são produzidos 
com o intuito de prototipar uma versão do software. 
TEMA 3
Modelagem comportamental 
da análise com a Linguagem de 
Modelagem Unificada (UML)
______________________________________________________________
Autoria: Iolanda Cláudia Sanches Catarino
Leitura crítica: Rogério Colpani
31
DIRETO AO PONTO
As técnicas de modelagem comportamental da Unified Modeling 
Language (UML) enfatizam a perspectiva da visão dinâmica de 
execução do sistema. Na modelagem de análise com a UML, o 
primeiro diagrama a ser especificado é o Diagrama de Casos de 
Uso, na sequência prioriza a definição da estrutura das classes 
de objetos, a partir da especificação do Diagrama de Classes, 
técnica de modelagem estrutural, e posteriormente recomenda-
se retomar a modelagem comportamental de cada caso de 
uso. O Quadro 1 a seguir descreve as técnicas de modelagem 
comportamental da UML:
32
Figura 1 – Técnicas de Modelagem Comportamental da UML
Diagrama Principais Elementos do Diagrama
Diagrama de 
Casos de Uso (Use 
Cases): adotado 
para documentar 
a modelagem de 
negócio do sistema, a 
modelagem conceitual 
de análise de requisitos 
e principalmente a 
modelagem lógica e 
funcional da fase de 
análise, representando 
um refinamento da 
especificação dos 
requisitos funcionais 
do sistema com o 
objetivo de representar 
os serviços, tarefas ou 
funcionalidades do 
software.
a) Sistema: representa a modelagem da 
fronteira do sistema, indicando uma ideia 
visual clara da fronteira do sistema. b) Ator: 
representa qualquer elemento externo ao 
sistema que interage com as funcionalidades 
do sistema, podendo ser pessoas, hardware, 
dispositivo, outro sistema etc. c) Caso de 
Uso: representa um relato de uso de uma 
funcionalidade do sistema, sem revelar o 
seu comportamento interno. d) Associação: 
representa um relacionamento de 
comunicação entre ator e os casos de uso, 
indicando uma interação com o sistema. e) 
Generalização: é um tipo de relacionamento 
que representa o reuso de comportamento 
existente entre casos de uso ou entre atores. 
f) Extensão: é um tipo de relacionamento de 
dependência existente somente entre casos 
de uso para indicar a chamada opcional de 
execução de outro caso de uso. g) Inclusão: 
é um tipo de relacionamento existente 
somente entre casos de uso para indicar a 
continuidade de execução obrigatória entre 
os casos de uso.
33
Diagrama de 
Atividades: demonstra 
o fluxo de controle 
de um conjunto 
de atividades que 
representa a execução 
de procedimentos, 
casos de uso, 
processos de negócio, 
subsistemas ou até o 
sistema completo.
a) Atividade: representa a sequência de 
tarefas em um fluxo de trabalho que resulta 
em um comportamento de um processo. 
Uma atividade é composta por um conjunto 
de ações. b) Nó de Ação: representa um 
único passo de execução imediata de uma 
atividade, sendo o elemento mais básico 
de uma atividade, ou seja, não pode ser 
decomposto. c) Nó Inicial: representa o início 
do fluxo da atividade, indicando a primeira 
ação executada da atividade, obrigatório 
ter um nó inicial. d) Nó Final: representa o 
fim do fluxo de uma atividade, sendo que o 
diagrama pode ter um ou mais nós finais. e) 
Nó de Decisão: representa uma escolha entre 
dois ou mais fluxos, a partir de uma entrada 
e duas ou mais saídas. Um nó de decisão 
é acompanhado obrigatoriamente por 
condições de guarda que indicam a condição 
para que um fluxo possa ser escolhido. f) Nó 
de Objeto: representa uma instância de uma 
classe gerada ou acessada pela atividade, 
a partir de um fluxo de objeto. g) Fluxo 
de Controle: representa um conector com 
direcionamento que liga dois nós, enviando 
sinais de controle do fluxo sequencial de 
execução da atividade. h) Fluxo de Objeto: 
representa um conector com direcionamento, 
indicando objetos ou dados enviados através 
dele, ou seja, entre o nó de ação e o nó de 
objeto.
34
Diagrama de Máquina 
de Estados: demonstra 
o comportamento 
dinâmico de um 
elemento por meio 
de um conjunto de 
transições de estados 
realizadas entre 
os estados finitos 
de objetos de uma 
classe com estados 
relevantes.
a) Estado: representa uma situação durante a 
manipulação de um objeto, por um instante 
finito de tempo, o qual ele satisfaz alguma 
condição ou realiza alguma atividade. b) 
Transição: representa um relacionamento 
entre dois estados, indicando a mudança de 
estado, a partir da ocorrência de um evento. 
c) Estado Inicial: representa o estado inicial da 
máquina de estados, sendo único. d) Estado 
Final: representa o fim do ciclo dos estados 
que compõem a máquina de estados. Este 
estado é opcional e pode conter mais de 
um estado final em um mesmo diagrama. 
e) Pseudoestado de Escolha: representa uma 
decisão com a indicação dos estados que 
podem ser gerados, a partir de uma condição 
de guarda. f) Estado Composto: indica que 
um estado contém internamente dois ou 
mais estados com suas transições, gerados 
independentemente ou não.
35
Diagrama de 
Sequência: representa 
a ordem temporal em 
que as mensagens são 
trocadas para darem 
suporte à realização de 
um caso de uso.
a) Linha de Vida: representa a existência de 
um elemento (objeto ou ator) participante 
da realização do caso de uso em um período 
de tempo. b) Ator: são os mesmos já criados 
no Diagrama de Casos de Uso. c) Objeto: 
representa os objetos que participam da 
realização do caso de uso. d) Foco de Controle: 
representa o período de tempo durante 
o qual um elemento executa uma ação, 
diretamente ou não. e) Mensagemou Estímulo: 
representa a solicitação que um elemento 
envia para o outro com o objetivo de executar 
uma ação, demonstrando a ocorrência de 
eventos. f) Mensagem síncrona: a mensagem é 
síncrona quando o emissor aguarda o retorno 
para continuar com a interação. g) Mensagem 
assíncrona: a mensagem é assíncrona quando 
o emissor continua enviando mensagens sem 
aguardar o retorno.
Fonte: elaborado pela autora.
Referências bibliográficas
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. 2. 
ed. Rio de Janeiro: Campus, 2006. 
GUEDES, G. T. A. UML: uma abordagem prática. 3. ed. São Paulo: 
Novatec, 2018. 
36
PARA SABER MAIS
Independentemente do modelo de processo de engenharia de 
software – tradicionais ou ágeis, que indica um fluxo de trabalho 
organizado para o desenvolvimento de sistemas de software, toda 
definição de o que, quando e como será desenvolvido um sistema 
faz parte de cada metodologia que uma empresa ou equipe 
de desenvolvimento estabelece, em consonância com as boas 
práticas da engenharia de software, para atender os diferentes 
domínios de aplicações e soluções computacionais.
Diante da evolução das Tecnologias da Informação e Comunicação 
(TIC) e da alta demanda por sistemas de softwares modernos, 
no ambiente organizacional, em 2001, Kent Beck e outros 16 
renomados desenvolvedores, autores e consultores da área de 
software assinaram o Manifesto para o Desenvolvimento Ágil de 
Software (Manifesto for Agile Software Development). A engenharia 
de software ágil enfatiza a simplicidade no desenvolvimento, 
defendendo a satisfação do cliente, a entrega incremental 
antecipada, equipes de projeto pequenas e altamente motivadas, 
métodos informais, artefatos de engenharia de software 
mínimos, além de priorizar como princípios de desenvolvimento 
a comunicação ativa e contínua entre desenvolvedores e clientes, 
a documentação de análise e projeto simplificada e a ênfase na 
implementação (PRESSMAN; MAXIM, 2016). Nesse contexto, os 
modelos de processos devem fornecer um mecanismo realista 
e flexível que estimule a disciplina necessária para garantir os 
princípios do desenvolvimento ágil. 
Alguns modelos de processo de desenvolvimento ágil que se 
destacam no mercado são:
37
• eXtreme Programming (XP): é o modelo mais amplamente 
utilizado para desenvolvimento de software ágil, focado no 
desenvolvimento de softwares que tem três pilares como 
base: agilidade no desenvolvimento da solução, economia 
de recursos e qualidade do produto final. A equipe XP 
garante a integração e a sinergia necessárias para um bom 
desempenho.
• Scrum: modelo ágil mais utilizado atualmente. Aplica-se 
não só ao desenvolvimento de softwares como a qualquer 
ambiente de trabalho. Focado na gestão do projeto e tem 
como base o planejamento iterativo e incremental. Segundo 
Pressman e Maxim (2016, p. 78), “os princípios do Scrum são 
coerentes com o manifesto ágil e são usados para orientar 
as atividades de desenvolvimento dentro de um processo 
que incorpora as seguintes atividades metodológicas: 
requisitos, análise, projeto, evolução e entrega”.
• Feature Driven Development (FDD): modelo focado em 
funcionalidades, permitindo à equipe do projeto realizar 
um planejamento incremental por fases com integração 
contínua das funcionalidades. Aplica-se controle de 
qualidade e gerenciamento de configurações em todas as 
fases do projeto e o planejamento é incremental com testes 
de software.
• Microsoft Solutions Framework (MSF): modelo que enfatiza 
o desenvolvimento de soluções tecnológicas por equipes 
reduzidas, focando na diminuição de riscos para o negócio 
e no aumento da qualidade do produto final. O MSF prioriza 
mais a gestão do projeto do que o desenvolvimento da 
solução em si e considera as premissas de alinhamento da 
tecnologia desenvolvida aos objetivos de negócio do cliente, 
o escopo bem estruturado e detalhado, o desenvolvimento 
38
iterativo, o gerenciamento de riscos e agilidade na resposta a 
mudanças.
• Processo Unificado Ágil (AUP - Agile Unified Process): 
adota as atividades em fases clássicas do Processo 
Unificado – Concepção, Elaboração, Construção e Transição, 
fornecendo uma camada serial, ou seja, uma sequência 
linear de atividades de engenharia de software que permite 
à equipe visualizar o fluxo do processo geral de um projeto 
de software. Entretanto, em cada atividade, a equipe 
itera para alcançar a agilidade e entregar incrementos 
de software significativos para os usuários o mais rápido 
possível. Cada iteração AUP contempla as atividades de: 
modelagem, implementação, testes, entrega, configuração e 
gerenciamento de projeto e gerenciamento do ambiente. De 
acordo com Pressman e Maxim (2016, p. 78), “embora o AUP 
tenha conexões históricas e técnicas com a linguagem de 
modelagem unificada, é importante notar que a modelagem 
UML pode ser usada com qualquer modelo de processo 
ágil”.
Referências bibliográficas
PRESSMAN, R.; MAXIM, B. Engenharia de software: uma 
abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016.
TEORIA EM PRÁTICA
Considere a necessidade de desenvolver um sistema de 
informação para uma empresa que atua no segmento de 
organização e realização de eventos científicos.
39
O sistema deve controlar a submissão e avaliação de trabalhos 
para eventos científicos. Um autor pode realizar muitas 
submissões, com o envio de seu trabalho, respeitando o deadline 
do evento. Existem três tipos válidos de submissão de trabalhos: 
artigos curtos ou longos, cursos ou palestras. Um autor ou 
avaliador deve se cadastrar no sistema, criando o seu login e 
senha. Uma submissão pode ser elaborada por mais de um autor, 
totalizando cinco autores, no máximo, com a indicação de um 
autor responsável pela submissão. Toda submissão é avaliada por 
uma comissão de três avaliadores, considerando a atribuição de 
uma nota para diferentes quesitos de qualidade do trabalho. É de 
responsabilidade do coordenador do evento notificar os autores 
sobre a aceitação ou não de suas submissões no evento. 
Com base no Diagrama de Casos de Uso já especificado, elabore o 
Diagrama de Sequência correspondente ao cenário principal do 
caso de uso “Submeter Trabalho” e o Diagrama de Máquina de 
Estados correspondente aos objetos do tipo “evento”.
Para conhecer a resolução comentada proposta pelo 
professor, acesse a videoaula deste Teoria em Prática no 
ambiente de aprendizagem.
LEITURA FUNDAMENTAL
Indicação 1
O Capítulo 4 – Diagrama de Atividades e Descrição dos Casos de 
Uso tem como objetivo reforçar a compreensão do Diagrama de 
Atividades e compreender alguns formatos de documentação de 
casos de uso, que complementam a documentação de cada caso 
Indicações de leitura
40
de uso representado no diagrama. Para realizar a leitura, acesse 
a plataforma Biblioteca Virtual da Kroton/Biblioteca Virtual 3.0/
Acessar Portal e busque pelo título da obra.
MEDEIROS, E. S. de. Desenvolvendo software com UML 2.0: 
definitivo. São Paulo: Pearson, 2004.
Indicação 2
O artigo Comprehensibility of system models during test design: a 
controlled experiment comparing UML activity diagrams and state 
machines, tem o objetivo de reforçar a aplicabilidade e diferenças 
entre o Diagrama de Atividades e o Diagrama de Máquina de 
Estados. Para realizar a leitura, acesse a plataforma Biblioteca 
Virtual da Kroton/EBSCO HOST/Buscar por artigos e busque pelo 
título do artigo.
FELDERER, M.; HERRMANN, A. Comprehensibility of system models 
during test design: a controlled experiment comparing UML 
activity diagrams and state machines. Software Quality Journal, 
[s. l.], v. 27, n. 1, p. 125–147, 2019. 
QUIZ
Prezado aluno, as questões do Quiz têm como propósito a 
verificação de leitura dos itens Direto ao Ponto, Para Saber 
Mais, Teoria em Prática e Leitura Fundamental, presentes 
neste Aprendizagem em Foco.
Para as avaliações virtuais e presenciais, as questões serão 
elaboradas a partir de todos os itens do Aprendizagem em 
41
Foco e dos slides usadospara a gravação das videoaulas, 
além de questões de interpretação com embasamento no 
cabeçalho da questão.
1. O Diagrama de Atividades pode ser utilizado para modelar 
uma sequência de atividades, que pode ser um método ou um 
algoritmo, ou mesmo um processo completo. 
 
Assinale a alternativa correta que descreve alguns elementos 
básicos do Diagrama de Atividades. 
a. Atividade, Nó de Ação, Estado Inicial, Estado Final, Nó de 
Objeto, Nó de Decisão, Relacionamento.
b. Atividade, Nó de Ação, Nó Inicial, Nó Final, Nó de Objeto, Nó 
de Decisão, Fluxo de Controle.
c. Atividade, Caso de Uso, Nó Inicial, Nó Final, Objeto, Classe, 
Relacionamento.
d. Caso de Uso, Nó de Ação, Fluxo de Controle, Nó de 
Bifurcação, Nó de União.
e. Nó de Ação, Nó de Objeto, Swinlanes, Ator, Fragmento de 
Interação, Objeto.. 
2. As técnicas comportamentais da Linguagem de 
Modelagem Unificada (UML) enfatizam a perspectiva da 
visão dinâmica do sistema. 
 
Assinale a alternativa correta que indica o diagrama 
aplicado à modelagem correspondente à definição dos 
requisitos funcionais do sistema.
a. Diagrama de Casos de Uso.
42
b. Diagrama de Atividades.
c. Diagrama de Sequência.
d. Diagrama de Comunicação.
e. Diagrama de Máquina de Estados. 
GABARITO
Questão 1 - Resposta B
Resolução: Os elementos básicos do Diagrama de Atividades 
são: Atividade, Nó de Ação, Nó Inicial, Nó Final, Nó de Objeto, 
Nó de Decisão, Fluxo de Controle, Fluxo de Objeto, Nó de 
Bifurcação, Nó de União e Swinlanes. 
Questão 2 - Resposta A
Resolução: O Diagrama de Casos de Uso pode ser 
adotado para documentar a modelagem de negócio do 
sistema, a modelagem conceitual de análise de requisitos e 
principalmente a modelagem lógica e funcional da fase de 
análise, representando um refinamento da especificação 
dos requisitos funcionais do sistema com o objetivo de 
representar os serviços, tarefas ou funcionalidades do 
software. 
TEMA 4
Modelagem estrutural da análise 
com a Linguagem de Modelagem 
Unificada (UML)
______________________________________________________________
Autoria: Iolanda Cláudia Sanches Catarino
Leitura crítica: Rogério Colpani
44
DIRETO AO PONTO
As técnicas de modelagem estruturais da Linguagem de 
Modelagem Unificada (UML) representam a perspectiva da visão 
estática dos objetos do sistema, enfatizando a estrutura das 
classes e do software. Na análise, com base na compreensão 
do domínio do problema, é fundamental delimitar o escopo 
do projeto de software e, com isso, dimensionar as partes que 
integram o sistema.
A partir da especificação dos casos de uso, inicia-se a identificação 
e definição das classes de objetos e a elaboração do modelo de 
classes para demonstrar o aspecto estático das colaborações 
que permitem compreender como o sistema está estruturado 
internamente. O modelo de classes abrange um conjunto de 
Diagramas de Classes, que é considerado a principal técnica de 
modelagem estrutural da UML e é utilizado durante a maior parte 
do desenvolvimento iterativo de um software orientado a objetos, 
podendo ser incrementado com novos detalhes de notação, 
refinando-o até a atividade de implementação. Desta forma, o 
modelo de classes pode apresentar vários níveis de abstração ou 
versões.
Para organizar e dimensionar a quantidade de casos de uso 
e classes de um sistema, recomenda-se adotar a técnica de 
modelagem estrutural – Diagrama de Pacotes, que demostra 
os elementos do sistema agrupados e organizados em pacotes 
lógicos ou físicos, com o objetivo de representar os componentes 
ou módulos que integram um sistema e suas dependências. 
Assim, o Diagrama de Pacotes pode ser utilizado para compor 
outros diagramas da UML em modelos, como por exemplo, o 
Diagrama de Casos de Uso e o Diagrama de Classes. A notação 
do Diagrama de Pacotes consiste na representação dos pacotes 
45
e suas ligações, que é demonstrado pelo relacionamento do 
tipo dependência, sendo uma linha tracejada com direção. Cada 
pacote deve ser identificado por um nome único e um pacote 
pode agrupar outros pacotes. 
Os elementos básicos da notação do Diagrama de Classes são as 
classes e os relacionamentos. Uma classe representa um grupo de 
objetos do mundo real que compartilham os mesmos atributos, 
operações e semântica. Uma classe é representada graficamente 
por um retângulo com três partes, no máximo, sendo que na 
primeira parte exibe-se o nome da classe, na segunda parte a 
relação dos atributos e, na última, as operações. Na representação 
dos atributos e operações de uma classe, indica-se também 
à esquerda do nome destes, o símbolo da visibilidade, que 
determina o nível de acessibilidade de um atributo ou operação 
por outros objetos. Os quatro tipos de visibilidade são: privada, 
pública, protegida e do tipo pacote. 
No Diagrama de Classes, além da representação das classes, 
estabelece-se os relacionamentos entre as classes, os quais 
indicam o compartilhamento de informações entre os objetos 
das classes, por meio da troca de mensagens entre os objetos, 
em tempo de execução do sistema. Existem quatro tipos de 
relacionamentos que são os mais importantes, demonstrados no 
Quadro 1. O relacionamento do tipo associação conecta objetos 
das classes, podendo ser do tipo: Reflexiva, Binária, Ternária, 
Classe Associativa e Agregação.
46
Quadro 1 – Tipos de relacionamentos
Relacionamento e Notação Descrição
1. Associação Reflexiva 
 
Também denominada de auto-
associação. Ocorre quando existe 
um relacionamento entre objetos 
da mesma classe, sendo que 
cada objeto assume um papel na 
associação.
1. Associação Binária 
 
São relacionamentos estruturais 
que conectam os objetos entre 
duas classes. Na representação 
da associação binária também se 
pode indicar a navegabilidade da 
associação, a qual representa o 
sentido em que as informações 
são transmitidas entre os objetos.
1. Associação Ternária Ocorre quando relacionam objetos 
de mais de duas classes.
1. Associação Classe Associativa Também denominada de classe 
de associação. É uma classe 
que é conectada diretamente 
na associação entre as classes 
relacionadas. Normalmente, a 
classe associativa é representada 
para demostrar os atributos 
específicos do relacionamento 
estabelecido entre as classes 
associadas.
47
1. Associação Agregação Conhecida como associação 
“Todo-Parte”. Demonstra 
que as informações de um 
objeto (objeto-todo) precisam 
ser complementadas pelas 
informações contidas nos objetos 
da outra classe (objetos-partes) 
relacionada, representando 
que ambos os objetos das 
classes podem “viver” de forma 
independente.
1. Associação Composição Um tipo especial da agregação é a 
chamada Composição, que é uma 
variação da agregação, na qual é 
apresentado um vínculo mais forte 
entre o “objeto-todo” e os “objetos-
partes”, demonstrando que os 
objetos-partes integram um único 
“objeto-todo”.
2. Generalização Relacionamento entre classes 
generalizadas, chamada de 
superclasse ou classe-mãe, a 
outras mais especializadas, 
chamadas de subclasse ou classe-
filha, ou seja, conectam classes 
generalizadas a outras mais 
especializadas, caracterizando a 
herança entre classes.
3. Dependência Relacionamento de utilização entre 
casos de uso, classes, pacotes e 
anotações, indicando que uma 
alteração na especificação de 
um elemento pode afetar outro 
elemento que a utilize.
48
4. Realização Relacionamento que modela 
a conexão existente entre 
uma interface e uma classe ou 
componente, ou entre um caso 
de uso e uma colaboração, no 
qual um dos elementos especifica 
um contrato de uso com o outro 
elemento.
Fonte: elaborado pela autora.
Na representação das associações indica-se também a notação 
de multiplicidade, que determina o número mínimo e máximo 
de objetos envolvidos em uma associação. A definição da 
multiplicidade em uma associação depende de pressupostos e das 
regras de negócio, em conformidade com o contexto do domínio 
do sistema.
Referências bibliográficas
BOOCH, G.; RUMBAUGH, J.; JACOBSON,I. UML: guia do usuário. 2. 
ed. Rio de Janeiro: Campus, 2006. 
GUEDES, G. T. A. UML: uma abordagem prática. 3. ed. São Paulo: 
Novatec, 2018. 
PARA SABER MAIS
Evoluindo com a modelagem de análise de um sistema, é indicado 
refinar e especificar novas versões do Diagrama de Classes ou já 
consistir o Diagrama de Classes com o Diagrama de Casos de Uso, 
analisando as principais colaborações entre as funcionalidades 
do sistema, e iniciar a modelagem dos Diagramas de Estrutura 
49
Composta, contudo ainda priorizando os aspectos estáticos dos 
objetos do sistema.
O Diagrama de Estrutura Composta, lançado a partir da UML 2.0, 
é utilizado principalmente para representar as colaborações que 
demonstram o relacionamento entre os elementos que colaboram 
na execução de uma funcionalidade. Segundo Guedes (2018), o 
Diagrama de Estrutura Composta é utilizado para a modelagem 
de colaborações que descrevem uma visão de um conjunto de 
entidades cooperativas, que representam instâncias cooperando 
entre si para executarem uma função específica, sendo que uma 
estrutura refere-se à composição de elementos que se conectam, 
os quais representam instâncias executadas para atenderem um 
objetivo específico.
A notação básica do Diagrama de Estrutura Composta consiste na 
representação dos elementos colaboração, instâncias das classes 
e conector. Uma colaboração pode representar a estrutura de 
elementos conectados que representam instâncias cooperando 
entre si na execução de um único caso de uso ou mais, sendo 
representada graficamente por meio de uma elipse tracejada com 
o seu descritivo. As instâncias das classes correspondem aos 
objetos das classes já especificadas no Diagrama de Classes. Os 
relacionamentos entre as instâncias são representados por meio 
da utilização de retas, ligando uma instância a outra, denominadas 
de conectores. 
A Figura 1 exemplifica um Diagrama de Estrutura Composta, 
correspondente à colaboração Realizar Locação de Veículo.
50
Figura 1 – Exemplo de Diagrama de Estrutura Composta
Fonte: elaborada pela autora.
Na representação da colaboração Realizar Locação de Veículo 
foram utilizadas as instâncias das classes Pessoa (no papel de 
cliente), Reserva, Veiculo e LocacaoDevolucao, que demonstram a 
cooperação entre si para executarem a tarefa correspondente 
ao processo de locação de um veículo, contudo não demonstra 
o comportamento detalhado de como a funcionalidade é 
executada, pois o objetivo do Diagrama de Estrutura Composta é 
demonstrar apenas os aspectos essenciais que participam de cada 
colaboração, enfatizando sua estrutura estática.
Referências bibliográficas
GUEDES, G. T. A. UML: uma abordagem prática. 3. ed. São Paulo: 
Novatec, 2018.
51
TEORIA EM PRÁTICA
Considere a necessidade de desenvolver um sistema de 
informação para uma empresa que atua no segmento de 
organização e realização de eventos científicos.
O sistema deve controlar a submissão e avaliação de trabalhos 
para eventos científicos. Um autor pode realizar muitas 
submissões, a partir do envio de seu trabalho, respeitando o 
deadline do evento. Existem três tipos válidos de submissão de 
trabalhos: artigos curtos ou longos, cursos ou palestras. Um autor 
ou avaliador deve se cadastrar no sistema, criando o seu login e 
senha. Uma submissão pode ser elaborada por mais de um autor, 
totalizando cinco autores, no máximo, com a indicação de um 
autor responsável pela submissão. Toda submissão é avaliada por 
uma comissão de três avaliadores, considerando a atribuição de 
uma nota para diferentes quesitos de qualidade do trabalho. É de 
responsabilidade do coordenador do evento notificar os autores 
sobre a aceitação ou não de suas submissões no evento.
Para conhecer a resolução comentada proposta pelo 
professor, acesse a videoaula deste Teoria em Prática no 
ambiente de aprendizagem.
LEITURA FUNDAMENTAL
Indicação 1
O Capítulo 5 – Teoria de Classes e o Capítulo 6 – O Diagrama de 
Classes, têm como objetivo reforçar a compreensão dos conceitos, 
Indicações de leitura
52
notação e elementos do Diagrama de Classes, demonstrando 
exemplos de especificação do importante Diagrama de Classes. 
Para realizar a leitura, acesse a plataforma Biblioteca Virtual da 
Kroton/Biblioteca Virtual 3.0/Acessar Portal e busque pelo título 
da obra.
MEDEIROS, E. S. de. Desenvolvendo software com UML 2.0: 
definitivo. São Paulo: Pearson, 2004.
Indicação 2
O artigo Desenvolvimento e avaliação de um perfil UML para 
modelagem de jogos educacionais digitais, tem o objetivo de 
apresentar o desenvolvimento e a avaliação do UP4EG, um perfil 
UML para modelagem de JEDs, por meio de diagramas de classes 
UML. Para realizar a leitura, acesse a plataforma Biblioteca Virtual 
da Kroton/EBSCO HOST/Buscar por artigos e busque pelo título 
do artigo.
OLIVEIRA, L. R. de et al. Desenvolvimento e avaliação de um perfil 
UML para modelagem de jogos educacionais digitais. Revista 
Brasileira de Informática na Educação, [s. l.], v. 26, n. 2, p. 124–
143, 2018. 
QUIZ
Prezado aluno, as questões do Quiz têm como propósito a 
verificação de leitura dos itens Direto ao Ponto, Para Saber 
Mais, Teoria em Prática e Leitura Fundamental, presentes 
neste Aprendizagem em Foco.
53
Para as avaliações virtuais e presenciais, as questões serão 
elaboradas a partir de todos os itens do Aprendizagem em 
Foco e dos slides usados para a gravação das videoaulas, 
além de questões de interpretação com embasamento no 
cabeçalho da questão.
1. Os elementos básicos da notação do Diagrama de Classes são 
as classes e os relacionamentos. 
a. Dependência, Classe Associativa, Agregação e Composição.
b. Dependência, Associação, Multiplicidade e Navegabilidade.
c. Associação, Herança, Especialização e Generalização.
d. Associação, Generalização, Dependência e Realização.
e. Associação, Dependência, Agregação e Composição. 
2. Os relacionamentos entre as classes indicam o 
compartilhamento de informações entre os objetos das 
classes, por meio da troca de mensagens entre os objetos, 
em tempo de execução do sistema. 
 
Assinale a alternativa correta que indica o tipo de 
associação conhecida como associação “Todo-Parte”, 
o qual demonstra que as informações de um objeto 
precisam ser complementadas pelas informações contidas 
nos objetos da outra classe relacionada, representando 
que ambos os objetos das classes mantêm um vínculo de 
forma independente.
a. Reflexiva.
b. Binária.
c. Ternária.
54
d. Classe Associativa.
e. Agregação. 
GABARITO
Questão 1 - Resposta D
Resolução: Os relacionamentos entre as classes indicam 
o compartilhamento de informações entre os objetos 
das classes, por meio da troca de mensagens entre os 
objetos, em tempo de execução do sistema. São quatro 
tipos de relacionamentos mais importantes: Associação, 
Generalização, Dependência e Realização. O relacionamento 
do tipo associação conecta objetos das classes, podendo 
ser do tipo: Reflexiva, Binária, Ternária, Classe Associativa e 
Agregação. 
Questão 2 - Resposta E
Resolução: A associação do tipo agregação é conhecida como 
associação “Todo-Parte”. Demonstra que as informações de 
um objeto (objeto-todo) precisam ser complementadas pelas 
informações contidas nos objetos da outra classe (objetos-
partes) relacionada, representando que ambos os objetos das 
classes podem “viver” de forma independente. 
BONS ESTUDOS!
	Apresentação da disciplina
	Introdução
	TEMA 1
	Direto ao ponto
	Para saber mais
	Teoria em prática
	Leitura fundamental
	Quiz
	Gabarito
	TEMA 2
	Direto ao ponto
	TEMA 3
	Direto ao ponto
	TEMA 4
	Direto ao ponto
	Botão TEMA 5: 
	TEMA 2: 
	Botão 158: 
	Botão TEMA4: 
	Inicio 2: 
	Botão TEMA 6: 
	TEMA 3: 
	Botão 159: 
	Botão TEMA5: 
	Inicio 3: 
	Botão TEMA 7: 
	TEMA 4: 
	Botão 160: 
	Botão TEMA6: 
	Inicio 4: 
	Botão TEMA 8: 
	TEMA 5: 
	Botão 161: 
	Botão TEMA7: 
	Inicio 5: