Modelagem de Sistemas em UML

Prévia do material em texto

Modelagem de Sistemas em UML 
Marcio Quirino - 1 
 
SUMÁRIO 
Caminho do Brilho: Saiba Quais Conteúdos Você Irá Aprender Conosco........................................... 9 
Onboarding ......................................................................................................................................... 9 
Conceitos Básicos de Modelagem de Sistemas ................................................................................. 10 
Descrição .......................................................................................................................................... 10 
Propósito ........................................................................................................................................... 10 
Preparação ....................................................................................................................................... 10 
Introdução ......................................................................................................................................... 10 
Conceitos .......................................................................................................................................... 10 
O que são modelos e para que eles servem ................................................................................... 11 
Comunicação entre as pessoas envolvidas ............................................................................................. 12 
Redução nos custos do desenvolvimento ................................................................................................ 13 
Facilidade para alterações do sistema ..................................................................................................... 13 
Documentação do sistema ....................................................................................................................... 13 
Delimitar o escopo do sistema ................................................................................................................. 13 
Modelagem de sistemas .................................................................................................................. 13 
O processo de desenvolvimento de sistemas em fases ................................................................. 14 
Fases comuns e mais relevantes do processo de desenvolvimento .............................................. 15 
Explorando ferramentas e técnicas de levantamento de requisitos ............................................... 15 
Identificação dos requisitos ...................................................................................................................... 15 
Análise ..................................................................................................................................................... 15 
Projeto ...................................................................................................................................................... 15 
Implementação ......................................................................................................................................... 15 
Modelos como elementos de comunicação..................................................................................... 15 
Equipe levantando dados junto aos usuários ....................................................................................... 16 
Equipe construindo os modelos. .......................................................................................................... 16 
Equipe validando dados junto aos usuários. ........................................................................................ 16 
Conceitos .......................................................................................................................................... 17 
Paradigma orientado a objetos ........................................................................................................ 17 
Conceitos fundamentais da orientação a objetos ............................................................................ 18 
Objetos e classes ..................................................................................................................................... 18 
Operação, mensagem e estado ............................................................................................................... 19 
Operação.............................................................................................................................................. 19 
Mensagem ............................................................................................................................................ 19 
Estado .................................................................................................................................................. 20 
Objeto ....................................................................................................................................................... 20 
Os pilares da orientação a objetos .................................................................................................. 20 
Abstração ................................................................................................................................................. 20 
Encapsulamento ....................................................................................................................................... 20 
Modelagem de Sistemas em UML 
Marcio Quirino - 2 
 
Herança .................................................................................................................................................... 21 
Polimorfismo............................................................................................................................................. 21 
Exemplificando herança e polimorfismo ................................................................................................... 21 
Orientação a objetos como elemento de reusabilidade e extensibilidade ...................................... 22 
Análise de sistemas orientada a objetos ......................................................................................... 22 
Levantamento de requisitos ..................................................................................................................... 23 
Análise de requisitos ................................................................................................................................ 24 
Análise do domínio (ou do negócio) ..................................................................................................... 24 
Análise da aplicação ............................................................................................................................ 24 
Projeto (desenho) de sistemas orientado a objetos ........................................................................ 24 
Projeto da arquitetura ............................................................................................................................... 25 
Projeto detalhado ..................................................................................................................................... 25 
Desenvolvimento de sistemas em camadas ................................................................................... 25 
Vantagens ............................................................................................................................................ 26 
Desvantagens ...................................................................................................................................... 26 
Conceitos .......................................................................................................................................... 26 
O que é UML, afinal? .......................................................................................................................26 
Visões da UML ................................................................................................................................. 28 
Visão de casos de uso ............................................................................................................................. 28 
Visão de projeto (ou lógica) ...................................................................................................................... 28 
Visão de implementação (ou de desenvolvimento) .................................................................................. 28 
Visão de implantação (ou física) .............................................................................................................. 28 
Visão de processo .................................................................................................................................... 28 
UML e integração com processos de desenvolvimento .................................................................. 29 
Em cascata............................................................................................................................................... 29 
Iterativo .................................................................................................................................................... 29 
Ágil ........................................................................................................................................................... 29 
RUP (Rational Unified Process) ............................................................................................................... 29 
Visão geral dos diagramas UML ...................................................................................................... 29 
Diagramas UML e sua utilização nas fases..................................................................................... 31 
Considerações finais ........................................................................................................................ 32 
Referências....................................................................................................................................... 32 
Explore+ ........................................................................................................................................... 32 
UML para modelagem do domínio ...................................................................................................... 33 
Descrição .......................................................................................................................................... 33 
Propósito ........................................................................................................................................... 33 
Preparação ....................................................................................................................................... 33 
Introdução ......................................................................................................................................... 33 
Requisitos funcionais e não funcionais ............................................................................................ 34 
Modelagem de Sistemas em UML 
Marcio Quirino - 3 
 
Diagrama de casos de uso .............................................................................................................. 35 
Atores ............................................................................................................................................... 36 
Caso de uso ..................................................................................................................................... 38 
Casos de uso primários ............................................................................................................................ 38 
Casos de uso secundários ....................................................................................................................... 38 
Relacionamentos .............................................................................................................................. 38 
Relacionamento de comunicação ............................................................................................................ 39 
Relacionamento de inclusão .................................................................................................................... 39 
Relacionamento de extensão ................................................................................................................... 39 
Relacionamento de generalização ........................................................................................................... 40 
Especificação e formatos de casos de uso ..................................................................................... 41 
Formato contínuo ..................................................................................................................................... 41 
Formato numerado ................................................................................................................................... 41 
Formato tabular ........................................................................................................................................ 42 
Cenário principal e cenários alternativos ......................................................................................... 42 
Estrutura de especificação de casos de uso ................................................................................... 43 
Especificação de casos de uso com inclusão e extensão .............................................................. 44 
Conceito e elementos de uma classe .............................................................................................. 44 
Visão geral do diagrama de classes ................................................................................................ 46 
Modelo de classes de análise .................................................................................................................. 47 
Modelo de classes de projeto ................................................................................................................... 47 
Modelo de classes de implementação ..................................................................................................... 48 
Relacionamentos no diagrama de classes ...................................................................................... 48 
Nome ........................................................................................................................................................ 49 
Multiplicidades .......................................................................................................................................... 49 
Tipo de participação ................................................................................................................................. 50 
Direção da leitura ..................................................................................................................................... 50 
Papéis ...................................................................................................................................................... 50 
Classes associativas ........................................................................................................................ 50 
Autoassociação ........................................................................................................................................ 50 
Todo-parte ................................................................................................................................................ 51 
Herança ............................................................................................................................................52 
Visão geral do diagrama de objetos ................................................................................................ 52 
Visão geral do diagrama de pacotes ............................................................................................... 55 
Desdobramentos dos diagramas no pacote .................................................................................... 56 
Considerações finais ........................................................................................................................ 58 
Referências....................................................................................................................................... 58 
Explore+ ........................................................................................................................................... 59 
Utilizando UML Para Projetar o Software ............................................................................................ 60 
Modelagem de Sistemas em UML 
Marcio Quirino - 4 
 
Descrição .......................................................................................................................................... 60 
Propósito ........................................................................................................................................... 60 
Preparação ....................................................................................................................................... 60 
Introdução ......................................................................................................................................... 60 
Atividades do desenvolvimento de software.................................................................................... 61 
Diagramas de interação ................................................................................................................... 61 
Diagrama de sequência ................................................................................................................... 63 
Elementos do diagrama de sequência ..................................................................................................... 63 
Objetos ................................................................................................................................................. 63 
Linha da Vida ....................................................................................................................................... 65 
Mensagens ........................................................................................................................................... 66 
Mensagens de iteração ........................................................................................................................ 66 
Condições de guarda ........................................................................................................................... 67 
Autochamada ....................................................................................................................................... 67 
Ocorrência de interação ....................................................................................................................... 68 
Opt ....................................................................................................................................................... 68 
Loop ..................................................................................................................................................... 69 
Alt ......................................................................................................................................................... 69 
Diagrama de comunicação .............................................................................................................. 70 
Como construir um diagrama de interação...................................................................................... 71 
Em que momento construir o modelo de interações ....................................................................... 72 
Modelo de casos de uso ➔ Modelo de interações ................................................................................... 72 
Modelo de classes de análise ➔ Modelo de interações ........................................................................... 72 
Modelo de interações ➔ Modelo de casos de uso ................................................................................... 72 
Modelo de interações ➔ Modelo de classes ............................................................................................ 72 
Diagrama de classes de projeto....................................................................................................... 73 
Definição .................................................................................................................................................. 73 
Especificação de atributos ....................................................................................................................... 73 
Especificação de operações/métodos ...................................................................................................... 75 
Especificação de associações.................................................................................................................. 75 
Transformação de associações em dependências ......................................................................... 77 
Classes persistentes e transientes ........................................................................................................... 77 
Classes de interface ................................................................................................................................. 77 
Navegabilidade de associações ...................................................................................................... 78 
Transição entre estados ................................................................................................................... 79 
Diagrama de transição de estados .................................................................................................. 80 
Transições ................................................................................................................................................ 81 
Identificação dos elementos de um diagrama de estados ........................................................................ 82 
Construção de diagramas de transições de estados ...................................................................... 83 
Modelagem de Sistemas em UML 
Marcio Quirino - 5 
 
Diagrama de atividades.................................................................................................................... 84 
Fluxo de controle sequencial .................................................................................................................... 85 
Fluxo de controle paralelo ........................................................................................................................ 85 
Raias ........................................................................................................................................................ 86 
Modelagem da lógica de uma operação complexa ......................................................................... 86 
Diagrama de componentes .............................................................................................................. 87 
Componente ............................................................................................................................................. 87 
Interfaces ................................................................................................................................................. 88 
Conectores ...............................................................................................................................................88 
Camadas .................................................................................................................................................. 89 
Diagrama de implantação ................................................................................................................ 89 
Nós do diagrama de implantação ............................................................................................................. 90 
Considerações finais ........................................................................................................................ 92 
Referências....................................................................................................................................... 92 
Explore+ ........................................................................................................................................... 92 
Estudo de Caso de Modelagem de Sistemas em UML ...................................................................... 93 
Descrição .......................................................................................................................................... 93 
Propósito ........................................................................................................................................... 93 
Preparação ....................................................................................................................................... 93 
Introdução ......................................................................................................................................... 93 
UML (Unified Modeling Language) .................................................................................................. 94 
Levantamento de requisitos ............................................................................................................. 95 
Minimundo do estudo de caso ......................................................................................................... 96 
Descrição do Minimundo .......................................................................................................................... 96 
Requisitos funcionais (RF) ....................................................................................................................... 96 
Requisitos não funcionais (RNF) .............................................................................................................. 97 
Requisitos de domínio ...................................................................................................................... 97 
Modelo de casos de uso .................................................................................................................. 98 
Estudo de caso – Diagrama de casos de uso ................................................................................. 98 
Diagrama de Casos de Uso aplicando todos RF.................................................................................... 100 
Estudo de caso – descrições de casos de uso....................................................................................... 101 
Modelo de classes .......................................................................................................................... 103 
Estudo de caso – Modelo de classes ............................................................................................ 104 
Modelo de atividades ..................................................................................................................... 107 
Modelagem de processo de negócio ...................................................................................................... 107 
Modelagem da lógica de um caso de uso .............................................................................................. 107 
Modelagem da lógica de uma operação ................................................................................................ 107 
Estudo de caso ‒ Modelo de atividades ........................................................................................ 107 
Modelo de estados ......................................................................................................................... 109 
Modelagem de Sistemas em UML 
Marcio Quirino - 6 
 
Estudo de caso ‒ Modelo de estados ............................................................................................ 110 
Modelo de classes de análise ................................................................................................................ 111 
Modelo de atividades ............................................................................................................................. 111 
Modelo de estados ................................................................................................................................. 111 
Modelo de interação ....................................................................................................................... 111 
Diagrama de sequência ......................................................................................................................... 111 
Diagrama de comunicação ..................................................................................................................... 111 
Estudo de caso – Modelo de interação ......................................................................................... 112 
Diagrama de sequência ......................................................................................................................... 112 
Diagrama de comunicação ..................................................................................................................... 115 
Modelo de classes de projeto ........................................................................................................ 116 
Estudo de caso ‒ Modelo de classes de projeto ........................................................................... 116 
Modelo de implementação ............................................................................................................. 118 
Estudo de caso ‒ Modelo de implementação ................................................................................ 118 
Modelo de implantação .................................................................................................................. 118 
Estudo de caso ‒ Modelo de implantação ..................................................................................... 119 
Modelo de interação ............................................................................................................................... 119 
Modelo de classes de projeto ................................................................................................................. 119 
Modelo de implementação ..................................................................................................................... 119 
Modelo de implantação .......................................................................................................................... 119 
Considerações finais ...................................................................................................................... 119 
Referências..................................................................................................................................... 120 
Explore+ ......................................................................................................................................... 120 
Introdução a Padrões de Projeto - Design Patterns .......................................................................... 121 
Descrição ........................................................................................................................................ 121 
Propósito .........................................................................................................................................121 
Preparação ..................................................................................................................................... 121 
Introdução ....................................................................................................................................... 121 
O que é um padrão de projeto................................................................................................................ 123 
Vantagens e desvantagens do uso de padrões de projeto .................................................................... 124 
Principais padrões em linhas gerais ....................................................................................................... 125 
Especialista..................................................................................................................................... 125 
Problema: ............................................................................................................................................... 125 
Solução: ................................................................................................................................................. 126 
Consequências:...................................................................................................................................... 127 
Criador ............................................................................................................................................ 127 
Problema ................................................................................................................................................ 127 
Solução .................................................................................................................................................. 128 
Consequências....................................................................................................................................... 128 
Modelagem de Sistemas em UML 
Marcio Quirino - 7 
 
Baixo acoplamento ......................................................................................................................... 128 
Problema ................................................................................................................................................ 128 
Solução .................................................................................................................................................. 129 
Consequências....................................................................................................................................... 129 
Alta coesão ..................................................................................................................................... 130 
Problema ................................................................................................................................................ 130 
Solução .................................................................................................................................................. 130 
Consequências....................................................................................................................................... 131 
Controlador ..................................................................................................................................... 131 
Problema ................................................................................................................................................ 131 
Solução .................................................................................................................................................. 131 
Consequências....................................................................................................................................... 132 
Polimorfismo ................................................................................................................................... 132 
Problema ................................................................................................................................................ 132 
Solução .................................................................................................................................................. 133 
Consequências....................................................................................................................................... 133 
Princípios SOLID ............................................................................................................................ 134 
Princípio da Responsabilidade Única (SRP) .......................................................................................... 134 
Princípio Aberto Fechado (OCP) ............................................................................................................ 135 
Violação do princípio OCP (clonagem)............................................................................................... 135 
Reestruturação adequada ao princípio OCP. ..................................................................................... 137 
Princípio da Substituição de Liskov (LSP) .............................................................................................. 138 
Princípio LSP (Quadrado) .................................................................................................................. 138 
Violação do princípio LSP .................................................................................................................. 139 
Princípio da Segregação de Interfaces (ISP) ......................................................................................... 139 
Violação do princípio ISP ................................................................................................................... 140 
Segregação das interfaces ................................................................................................................. 140 
Princípio da Inversão de Dependências (DIP)........................................................................................ 140 
Violação do princípio da Inversão de Dependências .......................................................................... 141 
Por que essa dependência é inadequada? ........................................................................................ 141 
Factory Method ............................................................................................................................... 142 
Problema ................................................................................................................................................ 142 
Por que este padrão é importante? ........................................................................................................ 142 
Solução .................................................................................................................................................. 143 
Consequências....................................................................................................................................... 144 
Adapter ........................................................................................................................................... 144 
Problema ................................................................................................................................................ 144 
Solução .................................................................................................................................................. 145 
Consequências....................................................................................................................................... 146 
Facade ............................................................................................................................................146 
Modelagem de Sistemas em UML 
Marcio Quirino - 8 
 
Problema ................................................................................................................................................ 146 
Solução .................................................................................................................................................. 147 
Consequências....................................................................................................................................... 147 
Strategy .......................................................................................................................................... 147 
Problema ................................................................................................................................................ 147 
Solução .................................................................................................................................................. 147 
Consequências....................................................................................................................................... 148 
Template Method............................................................................................................................ 149 
Problema ................................................................................................................................................ 149 
Solução .................................................................................................................................................. 149 
Consequências....................................................................................................................................... 150 
Considerações Finais ..................................................................................................................... 150 
Referências..................................................................................................................................... 151 
Explore+ ......................................................................................................................................... 151 
Modelagem de Sistemas em UML 
Marcio Quirino - 9 
 
Modelagem de Sistemas em UML 
Caminho do Brilho: Saiba Quais Conteúdos Você Irá 
Aprender Conosco 
Onboarding 
Caro aluno, seja bem-vindo ao universo da Modelagem de Sistemas em UML, uma viagem fascinante 
pelo coração da Tecnologia da Informação, onde cada diagrama e modelo é um passo em direção à 
excelência profissional. 
Ao mergulhar nos Conceitos Básicos de Modelagem de Sistemas, você está se munindo de uma 
linguagem universal em TI, algo que transcende as fronteiras do código e entra no reino da abstração lógica. 
Aqui, é como se estivéssemos aprendendo o alfabeto de uma nova língua, uma que irá permitir que você 
converse sobre complexidades de sistemas com clareza cristalina. 
Quando você emprega a UML para Modelagem do Domínio, começa a ver além do óbvio; os objetos 
e entidades do mundo real transformam-se em blocos construtivos nas suas mãos. É mais do que desenhar 
diagramas; é sobre entender a essência dos sistemas que você irá criar e melhorar, uma competência 
inestimável que elevará suas condições de trabalho e reconhecimento profissional. 
À medida que você Utiliza a UML para Projetar o Software, você está, de fato, orquestrando a 
comunicação entre os diversos atores do desenvolvimento de sistemas. Com essa habilidade, seu perfil se 
destaca não apenas como um desenvolvedor, mas como um visionário capaz de antecipar necessidades e 
integrar soluções eficazes, tornando-se um candidato diferenciado no mercado de trabalho. 
E não apenas isso, ao analisar um Estudo de Caso de Modelagem de Sistemas em UML, você não 
apenas testemunha a teoria ganhando vida; você vivencia o processo, identifica os desafios e triunfa sobre 
eles. Cada caso é um conto de adaptação e sucesso, preparando-o para as nuances do mundo real da TI e 
reforçando sua competência. 
Por fim, ao se introduzir aos Padrões de Projeto – Design Patterns, você está decifrando o DNA de 
softwares eficientes. É como ter uma visão de raio-X das melhores práticas de programação e design, uma 
habilidade que te distingue como um profissional não só competente, mas inovador. 
Essa jornada de aprendizado, meu caro aluno, não é apenas sobre absorver conhecimento; é sobre 
transformar-se em um profissional que molda a própria realidade da TI. A Modelagem de Sistemas em UML 
é o seu pincel, e a vastidão da computação, a sua tela. 
Então, celebre cada nova descoberta, cada conexão que você faz, cada modelo que você aperfeiçoa, 
pois em cada um desses momentos, você está não só aprendendo - está evoluindo. E lembre-se sempre, a 
universidade é mais do que uma etapa; é o espaço onde suas aspirações tomam forma e seu futuro é 
forjado. Sinta-se especial, pois aqui, na graduação, você está não apenas estudando, mas construindo as 
fundações de um amanhã repleto de possibilidades. 
 
Modelagem de Sistemas em UML 
Marcio Quirino - 10 
 
Conceitos Básicos de Modelagem de Sistemas 
Descrição 
O desenvolvimento de sistemas orientado a objetos e a Linguagem Unificada de Modelagem (UML) 
para criação de modelos, sob a forma de diagramas, com representação dos requisitos e das soluções de 
análise e projeto de sistemas de qualquer porte e finalidade. 
Propósito 
Compreender a UML no contexto de desenvolvimento de sistemas orientado a objetos (ou não) como 
uma ferramenta de construção de diagramas padronizados para ajudar a equipe de desenvolvimento a 
entender o que o sistema deve fazer, num primeiro momento, e como o sistema deve fazer, num momento 
seguinte. Disponibilizar diagramas que permitam enxergar o sistema sob cinco diferentes perspectivas e 
usá-los da forma que convier, em consonância com qualquer processo de desenvolvimento de sistemas. 
Preparação 
Antes de iniciar este conteúdo, é indicado ter instalado em seu computador um programa que permita 
elaborar modelos sob a forma de diagramas da UML (Linguagem Unificada de Modelagem). Nossa sugestão 
inicial é o Astah Free Student License, e será necessário usar seu e-mail institucional para ativar a licença. 
Preencha os dados do formulário, envie e aguarde a liberação de sua licença em seu e-mail institucional. 
Ao receber a licença, siga as instruções do e-mail e instale o produto em seu computador. 
Sugestões de links adicionais de ferramentas livres para modelagem de sistemas em UML podem 
ser encontradas em buscas na internet. 
Introdução 
Aprenderemos os conceitos básicos de modelagem de sistemas para compreender a realidade do 
negócio inerente ao sistema e expor as soluções para atender às necessidades reais de seus usuários. 
Iniciaremos pelo conceito de modelo e mostraremos sua aplicabilidade no contexto de desenvolvimento de 
sistemas. Vamos compreender que existem diferentes modelos que devem ser aplicados, sob a forma de 
templates e diagramas, nas diferentes fases do processo de desenvolvimento do sistema. 
Focaremos no desenvolvimento de sistemas orientado a objetos, compreendendo suas bases 
conceituais e seus pilares de sustentação. Dentro desse contexto, conheceremos a Linguagem Unificada 
de Modelagem (UML, do inglês Unified Modeling Language) e suas visões integradas de modelos, sob 
diferentes perspectivas, para abarcar as diversas necessidades de modelagem para exposição dos 
requisitos, das soluções de análise e de projeto do sistema em construção. A UML é uma linguagem de 
modelagem independente de tecnologia, que pode ser aplicada em diferentes processos e metodologias de 
desenvolvimento de sistemas orientados a objetos. 
1. Modelos na exposição de requisitos e soluções sistêmicas 
Reconhecer a importância dos modelos na exposição de requisitos e soluções sistêmicas 
Conceitos 
Neste módulo, veremos por que são usados modelos,sob a forma de diagramas, durante o processo 
de desenvolvimento de sistemas computacionais para expor as necessidades dos usuários e as ideias dos 
desenvolvedores para a construção do novo sistema. Assim, vamos conceituar e compreender a relevância 
da modelagem de sistemas. 
Modelagem de Sistemas em UML 
Marcio Quirino - 11 
 
O que são modelos e para que eles servem 
Exemplo 
Uma família decide adquirir um imóvel na planta para moradia. Ela vai, então, a um lançamento imobiliário a 
convite de um corretor conhecido. Chegando lá, deparam-se com o terreno vazio e um stand de vendas. 
Imediatamente, vem a dúvida: como escolher o bloco e o apartamento para que não sejam devassados, considerando 
a vizinhança? 
O corretor então inicia seu trabalho e leva a todos para conhecerem a maquete do empreendimento − que 
nada mais é do que a representação do empreendimento em bloco único − e a infraestrutura do parque aquático. 
A maquete é uma representação, em miniatura, do condomínio real. É um modelo do empreendimento 
real. Ou seja, o empreendimento real será construído à imagem e semelhança da maquete construída. 
A maquete é, portanto, um modelo (a base) a partir do qual o empreendimento real será construído. 
É uma simplificação da realidade, de forma que decisões prévias possam ser tomadas antes de sua 
construção, sob a perspectiva da construtora, e de sua aquisição, sob a perspectiva do comprador. 
No exemplo a seguir, encontramos maquetes de um empreendimento imobiliário, mostrando a 
perspectiva externa, dando a visão clara da vizinhança, do posicionamento do imóvel, da piscina e área de 
lazer e da entrada. 
Podemos estabelecer, então, a primeira finalidade de um modelo: antecipar a existência de uma 
realidade para avaliar sua estrutura e seu comportamento. 
Voltando ao exemplo do imóvel: 
Analisando a maquete e o posicionamento do empreendimento no terreno, os integrantes da família 
verificam o bloco e a posição do imóvel que mais lhes interessam, avaliando as vizinhanças e respectivas 
distâncias entre eles. 
 
Maquete de um empreendimento 
Em seguida, eles se sentam à mesa com o corretor para escolher a unidade no bloco selecionado. 
O corretor então apresenta a tabela de preços de cada unidade do bloco selecionado, informando a 
metragem, o valor da unidade e as condições de pagamento. 
A família seleciona três unidades e pergunta sobre a disposição dos cômodos. O corretor então 
apresenta a planta baixa de cada unidade selecionada. A imagem a seguir mostra a planta de uma das 
unidades: 
Modelagem de Sistemas em UML 
Marcio Quirino - 12 
 
 
Planta de uma unidade de um empreendimento. 
A planta ilustrativa da unidade é um segundo exemplo de modelo usado no mercado imobiliário, que 
possibilita ao comprador avaliar o posicionamento e a dimensão de cada cômodo. 
A família decide-se pelo imóvel, fecha o negócio e recebe um pen drive contendo outras plantas da 
unidade: elétrica, hidráulica, dentre outras. Cada uma dessas plantas representa um modelo sob uma 
diferente perspectiva. 
Outro exemplo de modelo muito comum atualmente são os protótipos, usados para aumentar a 
chance de sucesso dos produtos. A partir de um protótipo inicial, outros modelos podem ser demandados e 
aprimoramentos podem ser desenvolvidos. Os setores automobilístico e o de desenvolvimento de sistemas 
usam com eficácia protótipos como modelos. 
Resumindo 
Modelo: 
✓ Representação abstrata e simplificada da realidade. 
✓ Uma realidade pode demandar diferentes modelos, dependendo da perspectiva com que precise ser 
observada. 
Finalidade principal: 
✓ Antecipar a existência de uma realidade de forma a avaliar sua estrutura e comportamento. 
Modelos se aplicam ao contexto de desenvolvimento de sistemas? 
Na construção ou desenvolvimento de sistemas computacionais, assim como na construção 
imobiliária, há uma gradação da complexidade no processo de construção, que depende de alguns fatores, 
sendo o tamanho (do sistema ou do empreendimento) um deles. 
Os modelos, além da finalidade inicial, funcionam também como instrumento de gerenciamento da 
complexidade, considerando a limitação humana em lidar com ela. Os sistemas grandes e complexos 
carecem de ser modelados para sua melhor compreensão em sua totalidade. 
Modelos são capazes de revelar as propriedades essenciais de um sistema, ajudando no processo de 
abstração (concentração nos pontos de interesse) e permitindo que foquem no que é relevante. 
Dentre os benefícios que podemos citar para o uso de modelos em desenvolvimento de sistemas 
computacionais, além de tentar prever o comportamento do sistema e gerenciar sua complexidade, 
destacam-se: 
Comunicação entre as pessoas envolvidas 
O modelo serve como elemento de comunicação ou difusão de informações entre as pessoas 
envolvidas em sua construção. 
Modelagem de Sistemas em UML 
Marcio Quirino - 13 
 
Redução nos custos do desenvolvimento 
A construção de modelos é bem mais barata que a construção do sistema em si. A descoberta de 
erros e falhas em modelos é bem menos onerosa e contribui para a redução dos custos finais do sistema 
computacional. Isso também vale para as eventuais necessidades de ajustes e melhorias no sistema. 
Facilidade para alterações do sistema 
Depois de pronto, seja ainda na fase de construção ou de manutenção, os sistemas carecem de 
ajustes e melhorias. A análise dessas melhorias tende a ser mais efetiva quando elaborada sobre os 
modelos construídos, aumentando a assertividade e diminuindo seus custos. Daí a relevância e a 
necessidade de manter os modelos sempre atualizados. 
Documentação do sistema 
Os modelos servem de consulta e orientação a toda a equipe na construção e na manutenção do 
sistema, incluindo pessoas que sejam integradas após o início do desenvolvimento do sistema. Servem 
ainda para documentar as decisões tomadas. 
Delimitar o escopo do sistema 
A modelagem ajuda na delimitação do escopo, ou seja, abrangência do sistema, definindo o que será 
ou não tratado pelo sistema. 
Modelagem de sistemas 
Assim como exemplificamos no mercado imobiliário, no contexto de desenvolvimento de sistemas 
computacionais podem ser usados diferentes modelos de um mesmo sistema, em que cada um apresenta 
uma perspectiva (uma visão). 
Exemplo 
Um sistema armazena e manipula dados através de funcionalidades e possui determinados controles. 
Poderíamos pensar então em três perspectivas e, dessa forma, construir modelos que representem os dados, as 
funcionalidades e os controles, cada um focando uma perspectiva diferente. 
Outra perspectiva seria a visão externa, a de um usuário, que enxerga as funcionalidades 
necessárias, mas desconhece o que ocorre internamente. Essa seria mais uma perspectiva e mais um 
modelo que ajudaria nessa compreensão. 
Outra forma de abordar os sistemas computacionais por meio de visões seria: 
A. Externa 
✓ modela-se o ambiente em que o sistema está inserido, mostrando sua relação com os usuários e 
demais sistemas com que interage. 
B. Comportamental 
✓ modela-se o comportamento dinâmico do sistema e como ele reage aos eventos que o afetam. 
C. Estrutural 
✓ modela-se sua estrutura organizacional ou os dados que o sistema processa. 
D. Interação 
✓ modela-se as interações de seus componentes ou ainda do sistema e seu ambiente externo. 
A construção dos diferentes modelos para um sistema compreende o que denominamos de 
Modelagem de Sistemas, onde: 
1. Os modelos são abstratos, deixando de lado os detalhes e concentrando-se nos aspectos 
de interesse que são relevantes. A esse processo chamamos de abstração. 
2. Cada modelo apresenta o sistema sob uma diferente visão ou perspectiva da realidade. 
Modelagem de Sistemas em UML 
Marcio Quirino - 14 
 
3. Os modelos são descritos em notações gráficas, que denominamos diagramas. 
Modelagem de sistema de software consiste na utilização de notações gráficas e textuais com o objetivo deconstruir modelos que representam as partes essenciais de um sistema, considerando-se várias perspectivas 
diferentes e complementares. (BEZERRA, 2015) 
Como veremos mais adiante, a UML é uma linguagem unificada de modelagem que permite a 
construção de um conjunto de modelos, na forma de diagramas, sob diferentes visões ou perspectivas que, 
em conjunto, integram a solução de modelagem do sistema quando desenvolvido usando o paradigma 
orientado a objetos. 
O processo de desenvolvimento de sistemas em fases 
O desenvolvimento de sistemas computacionais é um processo que envolve pessoas e a 
necessidade de compreensão de uma realidade muitas vezes complexa e obscura, principalmente no início 
do desenvolvimento (vide imagem a seguir), quando o nível de abstração é alto e pouco se conhece da 
realidade. 
Conforme as fases em que o processo de desenvolvimento é particionado se sucedem, o 
conhecimento sobre o sistema aumenta, diminuindo, consequentemente, o nível de abstração da realidade. 
Essa complexidade aumenta na medida em que o tamanho do sistema cresce, requerendo um maior 
planejamento dos recursos a serem usados. O principal recurso no desenvolvimento de um sistema são 
pessoas, profissionais capacitados. 
 
Realidade X Sistema 
Num primeiro momento, precisamos compreender com muita clareza as necessidades das pessoas que serão 
usuárias do sistema, o que elas precisam que o sistema faça para que possam cumprir suas funções. 
Esse entendimento passa, também, pela necessidade da confirmação dessa compreensão pelas pessoas que 
estão construindo o sistema (os profissionais especializados). 
Mas como entender e confirmar a compreensão numa linguagem ambígua como a nossa, tanto a 
falada como a escrita? 
Se construirmos o sistema diretamente na linguagem de programação, a partir de um suposto 
entendimento da realidade, certamente teremos problemas de interpretação inadequada, e o sistema tende 
a não atender às necessidades de seus usuários, sendo então abandonado. Para representar 
adequadamente a realidade e entender o que se passa no contexto do sistema a ser construído, precisamos 
traduzir a realidade em modelos. 
Modelagem de Sistemas em UML 
Marcio Quirino - 15 
 
Fases comuns e mais relevantes do processo de desenvolvimento 
Dentro desse raciocínio, os modelos nos ajudam a entender a realidade e discutir essa compreensão, 
reduzindo a complexidade e o nível de abstração. 
Os modelos são, portanto, uma representação simplificada da realidade, representando os elementos de 
interesse naquele momento, permitindo abstrair o que não interessa e concentrar naquilo que de fato é relevante para 
o desenvolvimento do sistema. 
Desde os anos 1960, muitos processos, métodos e diversas técnicas de desenvolvimento de 
sistemas foram criados e postos em prática, visando à construção de sistemas computacionais robustos, 
eficientes e de fácil manutenção. 
Objetivando um melhor gerenciamento da complexidade, os processos e as metodologias de 
desenvolvimento de sistemas costumam ser divididos em fases. 
Cada processo ou metodologia cria sua própria divisão, mas, de maneira geral, podemos citar que 
(haverá exceção, logicamente) compreendem as fases de: 
Explorando ferramentas e técnicas de levantamento de requisitos 
Identificação dos requisitos 
Requisitos podem ser entendidos como as necessidades que os usuários têm e que devem estar 
contidos nas funcionalidades e propriedades do sistema a ser construído. 
Análise 
Com base nos requisitos, compreende-se o que o sistema deve fazer em prol de seus usuários. 
Projeto 
Compreende a adequação dos requisitos a como eles serão implementados, usando a tecnologia 
adequada para tal, definindo sua arquitetura e seus componentes. Define-se ainda toda a infraestrutura do 
ambiente computacional que será usada na construção do sistema, como: redes de computadores, banco 
de dados, linguagem de programação, dentre outros elementos. 
Implementação 
Diz respeito à identificação dos programas necessários e sua codificação na linguagem de 
programação selecionada na fase de projeto, bem como o banco de dados que será usado. 
Modelos como elementos de comunicação 
Os modelos atuam em mão dupla enquanto elementos de comunicação no processo de 
desenvolvimento de sistemas, ajudando: 
1. No entendimento e na validação dos modelos junto aos usuários; e 
2. No entendimento do sistema por membros da equipe de desenvolvimento. 
Entendimento e validação dos modelos junto aos usuários 
A partir dos modelos, compreendemos e nos certificarmos do correto entendimento da realidade junto 
aos usuários, conforme ilustrado a seguir (Momento 1, Momento 2 e Momento 3): 
Modelagem de Sistemas em UML 
Marcio Quirino - 16 
 
 
Equipe levantando dados junto aos usuários 
• Momento 1: A equipe de desenvolvimento se reúne com os usuários e, usando técnicas de 
levantamento de dados, compreende a realidade e as necessidades que os usuários têm, visando 
a que sejam implementadas no sistema. Os dados levantados são registrados e usados na 
construção dos modelos. Esse momento acontece com maior intensidade na fase de requisitos, 
mas também se faz presente nas fases de análise e de projeto. 
 
Equipe construindo os modelos. 
• Momento 2: A equipe de desenvolvimento constrói os modelos que julga pertinentes para que se 
possa compreender e destacar os aspectos relevantes da realidade. Esse momento acontece 
nas fases de requisitos, análise e projeto. 
 
Equipe validando dados junto aos usuários. 
• Momento 3: A equipe de desenvolvimento se reúne com os usuários, apresentando e discutindo 
os modelos construídos, visando validá-los e responder à pergunta base: os modelos que 
construímos representam de fato a realidade dos usuários? Em caso positivo, prossegue-se no 
desenvolvimento; caso contrário, os modelos são ajustados e confirmados novamente junto aos 
usuários, até que estejam adequados. Esse momento acontece nas fases de requisitos, análise 
e projeto. 
Entendimento do sistema por membros da equipe de desenvolvimento 
Outra finalidade dos modelos no desenvolvimento de sistemas é orientar membros da equipe quanto 
a suas tarefas no processo. 
Exemplo 
Modelagem de Sistemas em UML 
Marcio Quirino - 17 
 
O programador deve construir os programas, mas não tem livre acesso aos usuários e nem precisa, pois os 
modelos servem como elementos de comunicação com todos da equipe. Os projetistas do software devem 
compreender a realidade dos requisitos para construir os modelos de projeto, por isso precisam ler os modelos das 
fases de requisitos e de análise. Os programadores consultam os modelos de seu interesse e conversam com os 
membros que fizeram o levantamento de dados e a modelagem para compreenderem melhor o contexto e 
desenvolverem com mais eficiência os programas necessários. 
Outro exemplo seria um projetista de interface, que precisa conhecer o funcionamento de 
determinado recurso para criar a interface necessária, então ele consulta o modelo que exibe a comunicação 
do usuário com o sistema para a referida funcionalidade. Esse momento acontece em todas as fases do 
projeto, pois sempre haverá desenvolvedores recebendo tarefas e consultando os respectivos modelos 
pertinentes. 
A imagem a seguir ilustra a consulta de diferentes pessoas da equipe aos modelos desenvolvidos. 
 
Equipe consultando os modelos 
2. Análise e projeto orientados a objetos 
Distinguir os conceitos e pilares de análise e projeto orientados a objetos 
Conceitos 
Neste módulo, compreenderemos os conceitos, pilares, princípios e as orientações do paradigma 
orientado a objetos. Veremos também as visões, os objetivos e as entregas dos momentos de análise, 
projeto e implementação (em camadas), independentemente de processo ou metodologia de 
desenvolvimento de software. 
Paradigma orientado a objetos 
Com o aumento do tamanho do código e da complexidade dos programas, o paradigma estruturado,que antecedeu o paradigma orientado a objetos, começou a apresentar limitações nos sistemas sob o ponto 
de vista da dificuldade de manutenção e reuso de programas e rotinas padronizadas. 
Vamos, inicialmente, definir o termo paradigma como a maneira de abordar um problema. 
A orientação a objetos surge como solução a esses problemas, permitindo − mediante propriedades 
como abstração, encapsulamento, herança e polimorfismo − maior organização, reaproveitamento e 
extensibilidade de código e, consequentemente, programas mais fáceis de serem escritos e mantidos. 
O principal foco do paradigma orientado a objetos é permitir o desenvolvimento de sistemas de forma 
mais rápida e confiável. 
Um dos criadores do paradigma orientado a objetos, Alan Kay, imaginou um sistema como um 
conjunto de agentes autônomos, os objetos, que interagem entre si. 
Ele definiu os princípios centrais da orientação a objetos: 
1. Qualquer coisa do mundo real é um objeto 
2. Objetos realizam tarefas requisitando serviços a outros objetos 
Modelagem de Sistemas em UML 
Marcio Quirino - 18 
 
3. Os objetos similares são agrupados em classes e cada objeto pertence a uma classe 
4. A classe determina o comportamento possível a um objeto 
5. Classes são organizadas em hierarquias 
O paradigma da orientação a objetos visualiza um sistema de software como uma coleção de agentes 
interconectados chamados objetos. Cada um deles é responsável por realizar tarefas específicas e, para cumprir com 
algumas das tarefas sob sua responsabilidade, um objeto pode ter que interagir com outros. É pela interação entre eles 
que uma tarefa computacional é executada. Um sistema de software orientado a objetos consiste, portanto, em objetos 
colaborando para realizar as funcionalidades desse sistema. É graças à cooperação entre os objetos que a computação 
do sistema se desenvolve. (BEZERRA, 2015) 
Atenção 
Observação: Ao longo do texto, abreviaremos o termo "orientação a objetos" como O.O. 
Conceitos fundamentais da orientação a objetos 
A orientação a objetos enfatiza a identificação, a representação e a organização dos objetos 
necessários ao funcionamento de um sistema. Tem por base os conceitos de objetos, classes, operação, 
mensagem e estado, e está calcada em quatro pilares fundamentais: abstração, encapsulamento, herança 
e polimorfismo, discutidos na sequência. 
Neste tópico, adentraremos nesses conceitos fundamentais da orientação a objetos. 
Objetos e classes 
Um objeto pode referenciar qualquer coisa do mundo real: um aluno, uma disciplina, um curso, um 
professor, entre outros, considerando um sistema acadêmico como contexto. Ou seja, um objeto é qualquer 
coisa do mundo real, de interesse no contexto em estudo. 
Quando analisamos os objetos pertinentes a um contexto, não estamos preocupados com um objeto específico 
como, por exemplo, o aluno “José Carlos Aragão”, e sim com todos os alunos envolvidos no estudo. Surge então o 
conceito de classe que, conceitualmente, reúne (agrupa) um conjunto de objetos com as mesmas propriedades. Ou 
seja, estamos interessados em todos os alunos e não apenas em “José Carlos Aragão”. Usando o princípio da 
abstração (que detalharemos mais adiante), temos que uma classe agrupa objetos com as mesmas características ou 
propriedades, que são seus dados (atributos) e seus procedimentos (métodos) que implementam os serviços que essa 
classe vai prestar. 
A classe ALUNO agrupa “José Carlos Aragão” e os demais alunos envolvidos. Um objeto é um 
elemento específico de uma classe, ou ainda uma instância de uma classe. 
As classes são, portanto, abstrações que definem uma estrutura que encapsula dados (chamados 
de atributos) e um conjunto de operações possíveis de serem usados, chamados métodos. Por exemplo, a 
classe ALUNO encapsula um conjunto de dados que identifique os alunos − matrícula, nome, endereço (rua, 
número, complemento, estado e CEP), CPF e Identidade − e um conjunto de métodos: Incluir Aluno, 
Matricular Aluno, Cancelar Matrícula, dentre outros. 
Resumindo 
A. Classe: 
✓ Abstração das características de um grupo de coisas do mundo real. 
B. Objeto: 
✓ Um elemento específico de uma classe ou uma instância de uma classe. 
A seguir, temos a representação de uma classe em três compartimentos: o nome da classe (ALUNO), 
seus atributos (Matrícula... Identidade) e métodos (Incluir Aluno... Cancelar Matrícula). 
Modelagem de Sistemas em UML 
Marcio Quirino - 19 
 
 
Classe ALUNO 
A seguir, temos a representação de dois objetos da classe ALUNO: 
 
Objeto - Aluno 1 da classe ALUNO. 
 
Objeto Aluno 2 da classe ALUNO 
Operação, mensagem e estado 
Um sistema orientado a objetos consiste na cooperação entre seus objetos. Cada um tem uma 
responsabilidade no sistema, correspondendo à parte das funcionalidades que lhes são atribuídas. Em 
outras palavras, uma tarefa computacional é realizada pela interação entre seus objetos, cada um executa 
parte da tarefa. 
Operação 
Operação é o nome dado a cada ação (função) que o objeto sabe realizar. Mas um objeto não realiza 
nenhuma ação sem uma motivação, sem um estímulo. 
Mensagem 
Chamamos esse estímulo de mensagem, que chega a um objeto e solicita que ele realize uma de 
suas operações. Uma operação, por sua vez, pode ser implementada por meio de pelo menos um método. 
Modelagem de Sistemas em UML 
Marcio Quirino - 20 
 
Em outras palavras, cada objeto presta um serviço. Quando um objeto precisa de um serviço da 
responsabilidade de outro, ele precisa enviar uma mensagem a ele. Cada mensagem ativa uma das 
operações do objeto. 
Estado 
Já sabemos que um objeto contém atributos, que são dados necessários para prestar os serviços 
que cabem a esse objeto. Por definição, chama-se estado do objeto o conjunto de valores de seus atributos 
em dado momento. Uma mensagem enviada a um objeto pode (ou não) alterar o seu estado, na medida em 
que pode alterar um ou mais valores de seus atributos. 
Objeto 
Imagine, por exemplo, que o objeto Notas_Aluno contenha as notas do aluno em determinada 
disciplina. Em dado momento, é recebida uma mensagem informando uma nova nota a ser armazenada. O 
estado desse objeto foi alterado, pois um de seus atributos recebeu a nova nota. Agora suponha que 
determinado objeto enviou uma mensagem a Notas_Aluno solicitando que seja exibida a média atual; nesse 
caso, não houve alteração de estado, pois as notas foram consultadas, e a média foi calculada (não fica 
armazenada) e exibida. 
 
Partes de um objeto 
Os pilares da orientação a objetos 
Dentre as principais características do paradigma orientado a objeto (O.O.), destacamos: 
Abstração 
É um processo mental que permeia toda a orientação a objetos, como um princípio básico que serve 
de base aos demais princípios. A abstração permite que, ao estudar algo, ponhamos nossa concentração 
nos aspectos relevantes e deixemos de lado os menos importantes. Permite, portanto, gerenciar a 
complexidade de um objeto para que possamos nos ater às suas propriedades essenciais. E os aspectos 
essenciais de um objeto dependem, claro, do contexto no qual os analisamos, podendo variar. Ou seja, uma 
propriedade de um objeto pode ser relevante em um contexto e não ser em outro. 
Encapsulamento 
O objeto esconde (encapsula) seus dados (atributos) do acesso indevido por outros objetos e 
somente permite que eles sejam acessados por operações implementadas pelos seus próprios métodos 
(funcionalidades que implementam o comportamento do objeto). Com isso, o encapsulamento protege os 
dados do objeto do uso arbitrário ou não intencional, como pode ser visualizado na figura seguinte. O 
encapsulamento é uma técnica para minimizar a interdependência entre as classes, pois apenas os métodos 
da respectiva classe podem alterar seus dados (atributos), facilitando a identificação de erros e a alteração 
dos programas. Em outras palavras, garante que apenas os métodos da própria classe possam alteraro 
estado de um objeto. 
Modelagem de Sistemas em UML 
Marcio Quirino - 21 
 
 
Encapsulamento 
Herança 
Mecanismo para derivar novas classes a partir da definição de classes existentes, com base em um 
processo de refinamento. Uma classe derivada ou descendente herda os dados (atributos) e o 
comportamento (métodos) da classe base ou ancestral ou ascendente. A implementação da herança garante 
a reutilização de código, que, além de economizar tempo e dinheiro, propicia mais segurança ao processo 
de desenvolvimento, posto que as funcionalidades da classe base podem ter sido usadas e testadas. 
Polimorfismo 
A palavra polimorfismo deriva do grego e significa “muitas formas”. A partir do momento em que uma 
classe herda atributos e métodos de uma (herança simples) ou mais (herança múltipla) classes base, ela 
tem o poder de alterar o comportamento de cada um desses procedimentos (métodos). Isso amplia o poder 
do reaproveitamento de código promovido pela herança, permitindo que se aproveite alguns métodos e se 
altere (redefina) outros. Dessa forma, um método com mesmo nome em classes distintas pode ter diferentes 
comportamentos. 
Exemplificando herança e polimorfismo 
Acompanhe o exemplo da imagem a seguir, na qual identificamos uma herança: Pagamento em 
Dinheiro, Pagamento em CC (Cartão de crédito) e Pagamento em Cheque herdam da classe Pagamento, o 
atributo Valor e o método Pagar. 
 
Herança e polimorfismo 
Observe que, em cada classe filha (Pagamento em Dinheiro, Pagamento em Cartão e Pagamento 
em Cheque), o método PagarConta é escrito de forma diferente, com distintos parâmetros e códigos 
Modelagem de Sistemas em UML 
Marcio Quirino - 22 
 
internos, conforme exige a respectiva forma de pagamento. Essa possibilidade ocorre pelo princípio do 
polimorfismo. 
Orientação a objetos como elemento de reusabilidade e 
extensibilidade 
A orientação a objetos minimiza a gestão da complexidade na medida em que permite uma 
organização mais adequada de seus componentes, além de seu reaproveitamento. Um dos principais 
motivos para a baixa produtividade na construção de sistemas computacionais é a dificuldade de reutilização 
de código. 
As hierarquias de classes (herança) são estruturas que permitem o seu reaproveitamento entre aplicações que, 
se bem projetadas, podem ser reutilizadas em vários sistemas, otimizando tempo e dinheiro. 
Além disso, tais estruturas podem ser estendidas (usando o princípio do polimorfismo) sem 
corromper o que já existe. Dessa forma, pode-se concluir que a orientação a objetos traz em si os seguintes 
benefícios: 
A. Reusabilidade 
✓ O uso de componentes já escritos pode ser a base para outros softwares (através da herança). 
B. Extensibilidade 
✓ Novos componentes podem ser desenvolvidos a partir de outros, já desenvolvidos, sem afetar o 
comportamento do componente de origem (mediante o princípio do polimorfismo) e permitindo que 
esse comportamento seja alterado, estendido para um novo contexto. 
Análise de sistemas orientada a objetos 
Antes de adentramos no universo da análise sob o enfoque do paradigma orientado a objetos, vamos 
tecer rápidos comentários acerca do que seja a atividade de análise no contexto do desenvolvimento de 
software. 
De forma simples, pode-se dizer que a atividade de análise visa identificar o que os usuários e os demais 
interessados (que juntos formam os stakeholders) precisam que o sistema faça. 
Análise de sistemas implica numa investigação dos problemas e dos requisitos (necessidades dos 
usuários) de um contexto, em particular, visando a construção de um sistema automatizado. 
Atenção 
O foco da atividade de análise é estudar e entender o funcionamento de um sistema sob pelo menos alguns 
pontos de vista: da estrutura que sustenta o sistema (os dados); dos procedimentos e processos intervenientes no 
sistema; da dinâmica de funcionamento do fluxo de informações e dados, dentre outros aspectos que podem ser 
adicionados, dependendo da especificidade do sistema em construção. 
A atividade de análise, por ser muito abrangente, costuma ser dividida em: levantamento de 
requisitos (investigação dos requisitos) e análise dos requisitos. 
1. Inicialmente, entendemos a realidade, identificamos a abrangência do sistema e capturamos 
as necessidades dos usuários desse sistema, usando técnicas específicas (levantamento 
de requisitos). 
2. Posteriormente, analisamos e entendemos essas necessidades e o funcionamento e a 
dinâmica da organização (análise dos requisitos), visando à construção de modelos que 
representem o sistema a ser desenvolvido, em sua concepção lógica, sem preocupação 
com qualquer recurso tecnológico que venha sustentar o seu funcionamento. 
Modelagem de Sistemas em UML 
Marcio Quirino - 23 
 
A atividade de análise não leva em consideração nenhum recurso tecnológico que possa ser utilizado 
pelo sistema em construção. A ideia é construir uma estratégia de solução sem considerar como (com que 
tecnologia) essa estratégia será construída. 
A preocupação da atividade de análise é identificar: O QUE o sistema deve fazer para atender às necessidades 
de seus usuários. 
A sua finalidade é construir a melhor solução, que possa ser implementada em qualquer tecnologia 
(plataforma operacional, linguagem de programação e banco de dados), de acordo com as disponíveis no 
mercado, naquele momento. 
No contexto da orientação a objetos, foca-se na identificação, no entendimento e na definição dos 
objetos de software e em como eles irão colaborar para que os requisitos dos usuários sejam respondidos 
satisfatoriamente. 
Levantamento de requisitos 
Nesta fase, o foco é conversar com as pessoas envolvidas com o sistema (patrocinadores, gestores, 
usuários atuais e futuros e demais envolvidos) e compreender as necessidades e desejos de cada um. O 
foco, portanto, é na compreensão do problema. 
As necessidades e os desejos que os usuários têm são, tecnicamente, chamados de requisitos. Os 
desenvolvedores e as demais pessoas envolvidas se reúnem, visando à identificação dos requisitos do sistema, 
considerando o contexto específico e o domínio do problema (área do conhecimento ou atividade específica) a que o 
sistema se aplica. 
Requisitos 
Requisito pode ser definido como sendo uma condição ou capacidade que deve ser alcançada por um sistema 
para satisfazer uma necessidade. 
Para que os desenvolvedores possam identificar as necessidades dos usuários do sistema, é usado 
um conjunto de técnicas de levantamento de dados, desde as tradicionais entrevistas, reuniões, observação 
do ambiente do usuário e questionários até técnicas mais sofisticadas como brainstorm. 
O produto gerado por essa fase é o documento de requisitos, que contém todos os requisitos 
necessários ao sistema, classificados em: 
1. Requisitos funcionais 
✓ Declaram as funcionalidades necessárias ao sistema. 
2. Requisitos não funcionais 
✓ Apresentam algumas características associadas a uma, algumas ou todas as 
funcionalidades, e dizem respeito a aspectos de qualidade, confiabilidade, desempenho, 
portabilidade, segurança e usabilidade do sistema. 
Exemplo 
Imagine um sistema financeiro, no qual haja a necessidade das seguintes funcionalidades: Cadastramento 
dos pagamentos, Quitação dos pagamentos, Cadastramento das receitas, Quitação das receitas e Emissão das 
faturas. 
Cada uma das cinco funcionalidades anteriores representa um requisito funcional do sistema. Imagine, então, 
que o sistema precise ser touch screen. Tal característica da funcionalidade Emissão das faturas é um requisito não 
funcional de usabilidade (relacionada com uma interface de qualidade). Outro requisito não funcional de segurança 
seria a necessidade de um backup diário da base de dados. 
A correta identificação e seu registro no documento de requisitos são cruciais para a precisão e a 
qualidade do processo de desenvolvimento do sistema. Um requisito faltante ou outro mal definidopode ser 
fatal para seu sucesso. 
 
Modelagem de Sistemas em UML 
Marcio Quirino - 24 
 
Dica 
O documento de requisitos seguirá como base da comunicação entre os desenvolvedores e os usuários, 
devendo ser validado por estes, uma vez que servirá de norte para as atividades subsequentes do desenvolvimento 
do sistema. É, portanto, fundamental a participação ativa e efetiva dos usuários do sistema na fase de levantamento 
de requisitos. 
No documento de requisitos estará definido, também, o escopo do sistema. 
O principal ponto da fase de levantamento de requisitos é compreender profundamente no sistema 
antes de iniciar a sua construção. 
Análise de requisitos 
A fase de análise de requisitos é a transposição dos registros dos requisitos funcionais e não 
funcionais para os modelos que a equipe pretende usar. 
A principal atividade é desdobrar os requisitos funcionais em funcionalidades do sistema, uma vez 
que não necessariamente há uma relação de 1 para 1, ou seja, um requisito funcional pode demandar mais 
de uma funcionalidade e uma funcionalidade pode agregar mais de um requisito funcional. 
A análise de requisitos tem, minimamente, duas perspectivas ou visões: 
Análise do domínio (ou do negócio) 
✓ Visa a identificar ou modelar os objetos que serão usados na aplicação. Por exemplo, Pagamento 
é um objeto no contexto do sistema financeiro, usado para exemplificar os requisitos funcionais. 
Logo, Pagamento é um objeto do domínio, assim como Recebimento e Fatura. 
Análise da aplicação 
✓ Em geral, sucede a análise do domínio. Nela, são identificados os objetos de análise que não 
fazem sentido para os analistas de domínio, mas que são fundamentais para atender às 
funcionalidades necessárias ao sistema, a aplicação em si (daí seu nome). Por exemplo, uma 
interface de cadastramento de pagamentos é um objeto de aplicação do sistema de controle 
financeiro. Nesse momento, o foco é apenas a identificação desse objeto, sem especificar sua 
implementação, o que será detalhado na fase de Projeto (descrita adiante). 
Análise do domínio 
Objetos do domínio (relacionado ao problema) 
 
Análise da aplicação 
Objetos da aplicação (relacionado a aspectos computacionais de alto nível) 
Os principais diagramas UML usados nas fases de análise são: diagramas de casos de uso e 
diagrama de classes. Além desses, ajudam também diagramas de interação e de estados, em alguns casos. 
Análise pode ser traduzida em “faça a coisa certa”. 
Projeto (desenho) de sistemas orientado a objetos 
A atividade de projeto denota uma solução, voltada a atender aos requisitos identificados na fase de 
análise, considerando os recursos tecnológicos necessários para implementar os objetos do domínio e os 
objetos da aplicação. 
O objetivo é decidir “como o sistema funcionará” para atender aos requisitos. Em geral, o projeto enfoca a 
definição da arquitetura do sistema, determinando suas partes e a relação entre elas, o padrão de interface gráfica, o 
Modelagem de Sistemas em UML 
Marcio Quirino - 25 
 
ambiente computacional (sistema operacional e computacional), a linguagem de programação o gerenciamento do 
banco de dados. 
O projeto, portanto, deriva da análise e produz uma descrição dos recursos computacionais e de 
como o sistema deve executar no dia a dia. Muitas vezes algumas restrições tecnológicas podem ser 
impostas como, por exemplo, desenvolver na linguagem X, pelo fato de os sistemas da organização estarem 
nessa linguagem (claro, se ainda existir no mercado), ou usar o sistema gerenciador de banco de dados Y, 
pelo fato de a base corporativa da organização estar nele. 
A fase de projeto pode ser dividida em: 
Projeto da arquitetura 
Ato de distribuir as classes de análise em subsistemas com seus componentes, bem como distribuir 
os componentes pelos recursos de hardware disponíveis. Dentre os diagramas da UML, usamos aqui os 
diagramas de pacotes, componentes e implantação. 
Projeto detalhado 
Compreende atividades como modelagem das colaborações entre os objetos, projeto da interface, 
projeto do banco de dados e aspectos computacionais de alto nível (concorrência e distribuição de 
processamento e dados). O projeto de algoritmos pode ser considerado aqui também, detalhando aspectos 
do que for relevante para o projeto. Dentre os diagramas UML usados aqui, destacam-se: diagrama de 
interação (sequência ou comunicação), atividades (se demandar detalhamento de um método ou método 
com processamento paralelo), detalhamento do diagrama de classes, de estados, dentre outros detalhados 
adiante. 
Observação: Projeto pode ser traduzido em “faça certo a coisa”. 
Desenvolvimento de sistemas em camadas 
Abordaremos, inicialmente, a arquitetura de projeto de software em camadas de uma forma geral, 
sem nos atermos a um modelo em especial. O foco é separar o desenvolvimento do código em camadas, 
diminuindo sua complexidade e facilitando a sua manutenção. Camadas separam as responsabilidades e 
gerenciam as dependências. 
1. No início da computação, os sistemas eram monolíticos, ou seja, todo o código ficava 
confinado numa única camada, onde misturavam-se comandos de processamento, de 
construção e manipulação de interface, bem como de acesso e persistência de dados em 
SGBD. “Tudo junto e misturado”. 
2. Quando era preciso fazer manutenção no código, havia dificuldade no entendimento e na 
separação do que de fato precisava ser alterado, sem contar a interferência em uma parte 
do código quando se alterava outra, em princípio sem relação entre si. 
3. À medida que os sistemas cresceram e se tornaram complexos, a manutenção ficou mais 
difícil e a divisão em camadas foi uma das soluções encontradas para o projeto de 
arquitetura de um software. 
Num primeiro momento, a rede cliente-servidor, naturalmente, dividiu o software em duas camadas: 
a camada de código que roda no cliente (camada de interface com usuário) e a camada servidor (camadas 
de lógica do negócio e persistência dos dados). Posteriormente, com o advento da web, separou-se em três 
e depois em quatro camadas. Atualmente, pode-se criar tantas camadas quantas sejam necessárias, em 
função do tipo de aplicação. 
As camadas em geral: 
✓ Possuem alta coesão e baixo acoplamento, ou seja, concentram atividades afins (coesão) e são 
independentes umas das outras. 
Modelagem de Sistemas em UML 
Marcio Quirino - 26 
 
✓ Possuem propósito bem definido. 
✓ A camada superior tem conhecimento apenas da imediatamente inferior, que fornece os serviços, por 
uma interface. 
No caso da orientação a objetos, as classes são organizadas em módulos maiores, as chamadas 
camadas. Uma camada somente pode usar serviço (de outras classes) da camada imediatamente inferior. 
A seguir, as vantagens e desvantagens do desenvolvimento de software em camadas: 
Vantagens 
• Torna o código mais organizado e legível. 
• Permite o desenvolvimento, o teste e a manutenção das camadas isoladamente. 
• Permite melhor reuso do código ou dos objetos. 
• Pode substituir uma tecnologia que implemente uma camada, de forma simples, sem interferir 
nas demais. Por exemplo, para trocar o SGBD de SQL Server para PostgreSQL, basta alterar 
a camada de persistência. As demais permanecem como estavam. 
• Disciplina as dependências entre as camadas. 
• Mais adaptável a uma quantidade maior de usuários. 
Desvantagens 
• Aumenta o número de classes do sistema. 
• A adição de camadas torna o sistema mais complexo. 
• Potencialmente, reduz o desempenho do software. 
Como exemplo, podemos citar o modelo de camadas mais usado nos últimos anos, o de três 
camadas, que engloba as camadas de: 
A. Apresentação 
✓ Compreende as classes do sistema que permitem a interação com o usuário, as chamadas 
classes de fronteira. 
B. Negócio 
✓ Compreende as classes responsáveis pelos serviços e pelas regras do negócio, ou seja, 
reúne as classes de controle e negócio. 
C. Dados 
✓ Responsável pelo armazenamentoe pela recuperação dos dados persistentes do sistema, 
ou seja, as classes de persistência de dados. 
3. Síntese geral e os diagramas da UML 
Descrever as visões, a síntese geral e os diagramas da UML 
Conceitos 
Neste módulo, conheceremos a UML (Unified Modeling Language ou Linguagem Unificada de 
Modelagem). Essa linguagem padronizada oferece um conjunto de diagramas, sob diferentes visões, que 
permitem a modelagem de sistemas orientada a objetos, independente de tecnologia e de processos e 
metodologias de desenvolvimento de sistemas, cabendo seu uso em qualquer contexto de desenvolvimento 
orientado a objetos. 
O que é UML, afinal? 
No final dos anos 1990, as linguagens de programação orientadas a objeto já eram uma realidade, e 
cada profissional que desenvolvia atividade de análise e projeto de sistemas criava seus próprios modelos, 
Modelagem de Sistemas em UML 
Marcio Quirino - 27 
 
baseados em suas necessidades e realidade. Ou seja, não havia consenso no mercado sobre os modelos 
a serem usados para modelagem de sistemas desenvolvidos sob a tecnologia de orientação a objetos. 
Três competentes profissionais despontavam com seus modelos naquele momento: 
✓ Ivar Jacobson, idealizador do método OOSE (Object-Oriented Software Engineering). 
✓ James Rumbaugh, criador do método OMT (Object, Modeling Technique). 
✓ Grady Booch, criador do método que leva seu nome. 
A UML foi então adotada pela OMG (Object Management Group), em 1997, oriunda da integração 
dos três métodos anteriormente descritos, como uma linguagem de modelagem padrão para sistemas 
desenvolvidos sob o paradigma orientado a objetos. 
UML tornou-se o padrão para modelagem gráfica, não apenas para objetos e, de fato, faz sentido essa 
afirmativa, pois a UML pode ser a linguagem de modelagem para diagramar sistemas concorrentes e distribuídos. 
(FOWLER, 2005.) 
Desde sua versão inicial, a UML sofreu mudanças substanciais e atualmente encontra-se em sua 
versão 2.5.1, de dezembro de 2017. 
A UML é, portanto, uma linguagem padrão para construção de projetos de sistemas, voltada para a 
visualização, a especificação, a construção e a documentação de artefatos de um sistema. Foi projetada para ser 
independente do método ou processo de desenvolvimento utilizado. 
A UML é uma linguagem de modelagem, não é um método de desenvolvimento nem tampouco uma 
metodologia ou um processo de desenvolvimento de sistemas, uma vez que não determina a ordem e nem 
como os diagramas devem ser usados. Simplesmente disponibiliza os diagramas, sob as várias visões 
necessárias ao desenvolvimento de sistemas, e cada empresa (ou equipe de desenvolvimento) a utiliza da 
forma como lhe convenha, ou seja, adequando a UML ao seu processo ou metodologia de desenvolvimento 
de sistemas. 
A UML é uma linguagem destinada a: 
A. Visualização 
• A modelagem gráfica facilita a compreensão do sistema e das decisões tomadas em análise 
e projeto, além de melhorar a comunicação entre a equipe, permitindo sua interpretação sem 
ambiguidades. 
B. Especificação 
• Permite a construção de modelos precisos, não ambíguos e completos sob diferentes visões 
e atendendo às necessidades de modelagem das diferentes fases do processo de 
desenvolvimento de software, independentemente do processo ou modelo usado. 
C. Construção 
• Os diagramas UML podem ser integrados às principais e mais populares linguagens de 
programação do mercado, tais como Java e C++. Mas, para isso, terá que buscar uma 
solução integrada de ferramenta CASE (Computer-Aided Software Engineering) que gere 
código fonte (para linguagens específicas) a partir de alguns diagramas UML. 
Resumindo 
1. A UML é uma linguagem de modelagem padronizada. 
2. A UML é independente de tecnologia, adequando-se a todo método, metodologia ou processo de 
desenvolvimento. 
3. A UML não diz quais diagramas usar e nem em que ordem, pois a metodologia de desenvolvimento 
ditará essa ordem. 
4. A UML disponibiliza diagramas sob diferentes visões ou perspectivas. 
A UML se tornou não somente a notação gráfica dominante dentro do mundo orientado a objetos, como 
também uma técnica popular nos círculos não orientado a objetos. (FOWLER, 2005) 
Modelagem de Sistemas em UML 
Marcio Quirino - 28 
 
Visões da UML 
Assim como vimos nos exemplos do empreendimento imobiliário, as plantas das unidades, a planta 
elétrica, a planta hidráulica, dentre outras, cada modelo tinha uma perspectiva de compreensão da mesma 
realidade (unidades residenciais em um empreendimento). No mundo de sistemas computacionais, o 
mesmo acontece com relação à modelagem de sistemas com UML. Os autores da UML entendem que um 
sistema deve ser visto sob cinco diferentes perspectivas ou visões, descritas a seguir: 
Visão de casos de uso 
• Assim como a maquete permite uma perspectiva geral do empreendimento imobiliário, sob o 
ponto de vista externo (visão do comprador), a visão de caso de uso permite olhar o sistema sob 
o ponto de vista externo, do usuário, descrevendo seu comportamento por conjunto de interações 
usuário-sistema. Tal qual a maquete, é a primeira perspectiva de um empreendimento; a visão 
de caso de uso é criada no estágio inicial do desenvolvimento e guia todas as demais visões, na 
medida em que captura os requisitos funcionais que definem o sistema. 
Visão de projeto (ou lógica) 
• Permite visualizar o sistema sob o ponto de vista de sua estrutura interna e seu comportamento, 
em resposta às funcionalidades externamente percebidas por seus usuários. Enfatiza os pacotes, 
as classes, as interfaces, os subsistemas (pacotes) e as colaborações. 
Visão de implementação (ou de desenvolvimento) 
• Compreende o gerenciamento das versões do sistema, ou seja, de suas implementações 
utilizáveis por seus usuários. Compreendem os componentes, subsistemas e arquivos que 
compõem fisicamente o sistema. 
Visão de implantação (ou física) 
• Enfatiza a distribuição física do sistema em suas partes (subsistemas e componentes) e as 
respectivas conexões entre elas. Enfatiza também a organização física dos computadores e as 
conexões entre eles (a rede de computadores). 
Visão de processo 
• Enfatiza aspectos físicos mais peculiares como concorrência, sincronismo entre sistemas e 
desempenho (performance, confiabilidade, tolerância a falhas e outros aspectos) do sistema, 
considerando os processos e os processadores. 
A UML implementa diagramas que atuam nas cinco visões descritas anteriormente, permitindo ampla 
modelagem sobre todos os aspectos (visões) relevantes do sistema. 
Nem todas as perspectivas ou visões são úteis em todo desenvolvimento, pois dependem das 
características, tipo e complexidade do sistema. A imagem a seguir mostra a ideia central da visão de casos 
de uso, influenciando todas as demais. 
 
Visões da UML 
Modelagem de Sistemas em UML 
Marcio Quirino - 29 
 
UML e integração com processos de desenvolvimento 
A UML é independente de metodologia e processo de desenvolvimento. Isso é positivo para os 
fabricantes de software que implementam UML, pois não limita seu mercado. 
Sendo assim, cabe a cada empresa ou equipe de desenvolvimento a integração da UML com sua 
metodologia de desenvolvimento de sistemas computacionais, permitindo uma modelagem eficiente. 
A UML pode ser usada de diversas formas, desde esboços manuais para interação com usuários ou equipe, 
passando pelo uso de ferramentas de diagramação UML até sofisticadas ferramentas CASE, que integram os modelos 
e geram código em linguagens específicas. 
A UML então pode ser adaptada em qualquer processo, seja ele: 
Em cascata 
• Com e sem retroalimentação, onde as fases se sucedem, a seguinte inicia quando a anterior 
termina. A desvantagem é que, se for sem retroalimentação, não há opção de retorno à fase 
anterior. Por exemplo, se na fase de projeto identificamos novos requisitos, estes não podem ser 
considerados, pois a fase de análise congelou os requisitos identificados.Se a retroalimentação 
for permitida, esse problema pode ser minimizado, mas não solucionado. O grande problema é 
que o usuário interage com a equipe de desenvolvimento no início do processo e ao final, quando 
o sistema é entregue. 
Iterativo 
• Onde o sistema é dividido em subconjuntos de funcionalidades (com mínimo de dependência 
com os demais conjuntos), e as atividades de análise, projeto, implementação, teste e 
implantação são realizadas a cada subconjunto. Isso significa que a cada subconjunto haverá a 
implantação de uma parte do sistema, permitindo que ajustes das partes encerradas ocorram em 
paralelo com o novo subconjunto de funcionalidades que está sendo construído. 
Ágil 
• Os processos são ditos ágeis porque compartilham um conjunto de valores e princípios definido 
pelo manifesto ágil. O foco aqui é permitir modificação sempre que preciso e no desenvolvimento 
de código. A modelagem existe, mas em menor escala e com ênfase na comunicação com 
usuário e equipe de desenvolvimento. Visa a pouca formalidade nos processos ágeis. Mais 
usados: Extreme Programming (XP), Scrum, FDD (Feature Driven Development). 
RUP (Rational Unified Process) 
• O mercado muito fala da integração UML e RUP, mas, como os demais processos, o RUP é 
independente da UML. O RUP, na verdade, é uma estrutura de processo, que vai usar casos de 
desenvolvimentos (processo a ser usado), a maioria deles iterativos. O RUP não se adapta a 
processo em cascata. 
Visão geral dos diagramas UML 
Vamos nos ater aqui à versão mais recente da UML, a 2.5.1, que traz 14 diagramas divididos em 
estruturais e comportamentais, conforme imagem a seguir. 
A. Os diagramas estruturais 
✓ Dizem respeito às estruturas estáticas necessárias ao sistema, como os pacotes, as classes, 
os objetos, os componentes e a estrutura de nós (estruturas computacionais). Também são 
chamados de estruturas estáticas. 
 
 
 
Modelagem de Sistemas em UML 
Marcio Quirino - 30 
 
B. Os diagramas comportamentais 
✓ Evidenciam o comportamento (funcionamento) de parte de um sistema ou processo de 
negócio relacionado ao sistema, segundo determinada perspectiva. Dizem respeito às 
funcionalidades do sistema, aos estados de um objeto em seu ciclo de vida, às interações 
entre os objetos, dentre outros aspectos. Também são chamados de diagramas dinâmicos. 
 
Diagramas da UML 
A seguir, uma breve descrição de cada diagrama da UML: 
Diagrama Especificação 
Diagrama de perfil 
Permite a definição de tipos padronizados, como estereótipos, restrições e valores 
rotulados. O foco é a adequação aos modelos UML para diferentes plataformas, por 
exemplo. 
Diagrama de classes 
Descreve, para cada classe, suas propriedades (atributos e métodos) e seus 
relacionamentos com as demais classes. Classe é a base estrutural dos sistemas 
orientados a objetos. 
Diagrama de estruturas compostas 
Possibilita a descrição de colaborações internas de classes, interfaces ou componentes, 
visando a especificação de uma funcionalidade. 
Diagrama de componentes Apresenta a estrutura e as conexões entre os componentes de um sistema. 
Diagrama de implantação 
Especifica o ambiente computacional sobre o qual o sistema vai operar, além de distribuir 
os artefatos (pacotes, classes e componentes) nos nós (elementos computacionais). 
Diagrama de objetos 
É um diagrama de classes instanciado, ou seja, mostra exemplos de instâncias de 
classes. 
Diagrama de pacotes 
Descreve estruturas hierárquicas que englobam outros elementos, como outros pacotes, 
casos de uso, classes. Usado para modularizar logicamente um sistema em suas partes 
relevantes (subsistemas). 
Diagrama de atividades 
Descreve o comportamento de procedimentos, processos de negócios e fluxos de 
trabalho, suportando processamento sequencial e paralelo. 
Diagrama de casos de uso 
Mostra como os usuários (atores) interagem com o sistema, do ponto de vista externo, 
evidenciando as funcionalidades com as quais interagem. 
Diagrama de estados 
Mostra como os eventos que afetam o sistema alteram o estado dos objetos ao longo de 
seus ciclos de vida. 
Diagrama de sequência 
Mostra como os objetos interagem, evidenciando a linha de tempo (a sequência das 
interações). 
Diagrama de comunicação Mostra como os objetos interagem, evidenciando as conexões e colaborações entre eles. 
Diagrama de visão geral de 
interação 
Um mix de diagrama de sequência e de atividades. Uma especialização do diagrama de 
atividades para interações. 
Diagrama de tempo 
Diagrama de interação, com foco nas restrições de temporização, como, por exemplo, 
para evidenciar as mudanças no estado de um objeto ao longo do tempo. 
Tabela: Marcelo Vasques de Oliveira 
Modelagem de Sistemas em UML 
Marcio Quirino - 31 
 
Diagramas UML e sua utilização nas fases 
O descrito a seguir não é recomendado ou estipulado pela UML, pois a UML não determina quais 
diagramas devem ser usados e tampouco em que ordem devem ser elaborados. São dicas práticas. 
Dificilmente usamos todos os diagramas da UML em um único sistema. Há um conjunto de 4 a 8 
diagramas que são os mais usados: pacotes, casos de uso, classes, sequência (ou comunicação), estados, 
atividades, componentes e implantação. Todos os mencionados são relevantes, mas os em negrito são os 
essenciais. 
No módulo 1, descrevemos as atividades das fases de análise (levantamento e análise de requisitos) 
e projeto independentemente do processo de desenvolvimento por entender que ambas estarão presentes 
em qualquer processo que usemos. Agora, partindo desse mesmo pressuposto, vamos descrever os 
diagramas UML que podem ser usados em cada uma dessas três fases. Citaremos apenas os diagramas 
mais usados. 
Diagramas UML na atividade de análise: 
Levantamento de requisitos Análise de requisitos 
Esboço inicial do diagrama de pacotes, para grandes 
sistemas, evidenciando a necessidade de particionamento 
Detalhamento e aprofundamento do diagrama de pacotes 
Esboço inicial do diagrama de casos de uso Detalhamento e aprofundamento do diagrama de casos de uso 
Esboço inicial do diagrama conceitual de classes, em alto 
nível (sem detalhes) 
Detalhamento e aprofundamento do diagrama conceitual de classes 
 Diagrama de estados, para os objetos mais complexos durante seu 
ciclo de vida 
 
Diagrama de atividades, para elucidar um processo ou fluxo de 
trabalho relevante ou ainda para elucidar um caso de uso mais 
complexo 
Tabela: Marcelo Vasques de Oliveira 
Nota: o diagrama conceitual de classes evidencia as classes (com principais atributos e inicialmente sem 
métodos) e os principais relacionamentos (em geral apenas associações, que são os relacionamentos de classes mais 
elementares). 
Os diagramas usados no levantamento de requisitos são, em geral, esboços para a própria pessoa 
ou para debater com colegas da equipe. Já na fase de análise de requisitos, alguns diagramas, em geral 
pacotes e casos de uso, são usados para conversas com usuários. 
Diagramas UML na atividade de projeto: 
1. Adição de detalhes ao diagrama conceitual de classes, que passa a ser o diagrama de 
classes de projeto. 
2. Diagrama de sequência ou diagrama de comunicação, para cenários de uso mais 
relevantes, o que ajuda a identificar métodos das classes envolvidas na interação. 
3. Detalhamento dos diagramas de estados elaborados na atividade de análise, podendo 
modelar de outros objetos percebidos. 
4. Diagrama de componentes, caso o software use algum já pronto ou a ser construído. 
5. Diagrama de implantação, evidenciando as unidades computacionais e alocando os 
componentes nelas. 
6. Diagrama de atividades, esclarecendo métodos de classes mais complexos ou que usem 
processamento paralelo. 
Nota: o diagrama de classes de projeto deriva do diagrama conceitual de classes, agregando novos atributos, 
todos os métodos necessários, identificando os corretos relacionamentos entre as classes (e não apenas associações), 
adicionando as multiplicidades eoutros elementos relevantes da UML. 
Modelagem de Sistemas em UML 
Marcio Quirino - 32 
 
Considerações finais 
Vimos que o desenvolvimento de sistemas é uma atividade complexa, que envolve pessoas 
estudando um sistema que também será usado por outras pessoas. Ou seja, existe muita subjetividade 
envolvida nesse processo. Para minimizar essa subjetividade, o processo de desenvolvimento de um 
software é divido em fases, de forma que inicialmente tenhamos uma visão geral do sistema e, à medida 
que nos aprofundamos, conhecemos mais detalhes da estrutura e do funcionamento desse sistema. 
Vimos ainda que os processos de desenvolvimento usam diagramas, que são modelos que 
expressam a realidade sob determinada perspectiva, para melhorar a comunicação com os usuários e entre 
os membros da equipe de desenvolvimento. 
Conforme apresentado, os sistemas foram crescendo em tamanho e complexidade, e as técnicas 
usadas passaram a não atender às demandas. Percebeu-se, então, uma nova forma de visualizar os 
sistemas, com objetos do mundo real que interagem. Nasceu, assim, um novo paradigma de 
desenvolvimento: o paradigma orientado a objetos. 
Esse novo paradigma, porém, precisou de modelos compatíveis, pois os modelos dos paradigmas 
anteriores não atendiam à nova forma de ver e de construir sistemas. Os melhores profissionais do mercado 
produziram seus próprios modelos e, em 1997, criaram uma linguagem unificada, em padrão relativamente 
aberto: a UML (em português, Linguagem Unificada de Modelagem), que vem evoluindo substancialmente 
desde sua criação, estando em sua versão 2.5.1, de 2017. 
A UML é uma linguagem de modelagem independente de tecnologia, que se aplica a qualquer 
processo de desenvolvimento (orientado a objetos ou não). Ela especifica um conjunto de diagramas sob 
cinco diferentes visões que podemos ter sobre um sistema: visão de casos de uso (central), visão de projeto 
ou lógica, visão de implementação (ou desenvolvimento), visão de implantação (ou física) e visão de 
processo. Os diagramas de cada versão da UML atendem a uma ou mais dessas perspectivas e são usados 
nas diferentes fases de um processo de desenvolvimento. 
Referências 
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. 3. ed. Rio de Janeiro: Elsevier, 
2015. 
BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML: guia do usuário. 2. ed. Rio de Janeiro: Elsevier, 
2005. 
FOWLER, M. UML essencial: um breve guia para a linguagem-padrão de modelagem de objetos. 
Trad. João Tortello. 3. ed. Porto Alegre: Bookman, 2005. 
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos 
e ao processo unificado. 3. ed. Porto Alegre: Artmed, 2007. 
Explore+ 
Visão geral do desenvolvimento em camadas: trabalhando com desenvolvimento em camadas 
utilizando C#. 
Desenvolvimento em três camadas: conceitos. 
Modelagem de sistemas através da UML: uma visão geral. 
UML (Unified Modeling Language) e Unified Software Development Process (Unified Process). 
Pesquise na internet: 
O diagrama da arquitetura em camadas, publicado no cogle.it, sob forma de infográfico de domínio 
público. 
 
Modelagem de Sistemas em UML 
Marcio Quirino - 33 
 
UML para modelagem do domínio 
Descrição 
Visão geral da modelagem do domínio da aplicação com a UML, por meio de modelo de Casos de 
Uso, modelo de Classes, Diagrama de Objetos e Diagrama de Pacotes. 
Propósito 
Aprender as ferramentas básicas de modelagem conceitual de um sistema usando a UML é 
fundamental para a construção e a especificação sólida dos requisitos de um sistema, bem como o 
entendimento profundo sobre o domínio do negócio em que esse sistema esteja inserido. 
Preparação 
Antes de iniciar este conteúdo, instale em seu computador um programa que o permita elaborar 
modelos sob a forma de diagramas da UML (Linguagem Unificada de Modelagem). Nossa sugestão inicial 
é o Astah Free Student License, e será necessário usar seu e-mail institucional para ativar a licença. 
Preencha os dados do formulário, envie e aguarde a liberação de sua licença em seu e-mail institucional. 
Ao receber a licença, siga as instruções do e-mail e instale o produto em seu computador. 
Sugestões de links adicionais de programas livres para modelagem de sistemas em UML podem ser 
encontradas em buscas na internet. 
Introdução 
Aprenderemos técnicas e notação para modelagem de requisitos e conceitos de domínio de 
sistemas. A Unified Modeling Language (UML) ou Linguagem de Modelagem Unificada é uma linguagem ou 
notação visual para especificação de sistemas orientados a objetos. Essa notação vem sendo adotada como 
padrão para modelagem em organizações, pois tem como objetivo principal prover um conjunto de 
ferramentas poderosas para análise e projeto de sistemas. 
O foco deste conteúdo são os Diagramas de Casos de Uso, Diagrama de Classes e Objetos e 
Diagrama de Pacotes, com seus respectivos conceitos e elementos, muito úteis para arquitetos, analistas e 
projetistas de software na fase inicial do processo de desenvolvimento: a especificação de requisitos e 
modelagem conceitual do domínio. 
Em Engenharia de Software, a palavra domínio denota ou agrupa um conjunto de sistemas ou de 
áreas com funcionalidades similares dentro dos sistemas. Assim, é possível definir domínio aplicacional 
como uma coleção de aplicações de software com determinadas características em comum. Logo, domínio 
é um conjunto de características de uma família de problemas que determinada aplicação pretende 
solucionar. 
Atenção 
Como se observará ao longo do conteúdo, essa definição de domínio não deve ser confundida com o domínio 
de um atributo de classe, que é o conjunto de valores possíveis que esse atributo pode assumir. 
1. Requisitos funcionais de um sistema com uso de 
Diagrama de Casos de Uso 
Identificar requisitos funcionais de um sistema com uso de Diagrama de Casos de Uso 
Modelagem de Sistemas em UML 
Marcio Quirino - 34 
 
Requisitos funcionais e não funcionais 
O desenvolvimento de um sistema começa pelo entendimento do problema de negócio e o 
levantamento de quais requisitos esse sistema de software deve satisfazer para resolvê-lo. Não existe uma 
definição padronizada para requisito na literatura de Engenharia de Software. A norma ISO/IEC/IEEE (IEEE, 
1990) apresenta os seguintes enunciados para explicar o que é requisito: 
1. Uma condição ou capacidade do sistema solicitada por um usuário, para resolver um 
problema ou atingir um objetivo. 
2. Uma condição ou capacidade que deve ser atendida por uma solução para satisfazer um 
contrato, uma especificação, um padrão ou quaisquer outros documentos formais impostos. 
3. Documentação da representação das condições ou capacidades apresentadas nos dois 
anteriores. 
4. Necessidades quantificadas e documentadas, desejos e expectativas do patrocinador, 
clientes e outras partes interessadas. 
Os requisitos são o ponto de partida para todo o processo de desenvolvimento, sendo a base para 
as atividades de análise e projeto, bem como implementação e testes. De acordo com Sommerville (2011), 
a área de Engenharia de Software faz uma distinção, em termos de nível de detalhamento de requisitos, 
entre requisitos de usuário e requisitos de sistema. O primeiro expressa os requisitos abstratos de alto nível, 
e o segundo revela uma descrição detalhada do que o sistema deve fazer. 
Requisitos de usuário são declarações, em uma linguagem natural com diagramas, de quais serviços o sistema 
deverá fornecer a seus usuários e as restrições com as quais este deve operar. SOMMERVILLE, 2011 
Requisitos de sistema são descrições mais detalhadas das funções, serviços e restrições operacionais do 
sistema de software. SOMMERVILLE, 2011 
Em uma perspectiva mais técnica, os requisitos de software são normalmente classificados como 
requisitos funcionais e requisitos não funcionais. 
Requisitos funcionais são declarações de serviços que o sistemadeve fornecer, de como o sistema deve reagir 
a entradas específicas e de como o sistema deve se comportar em determinadas situações. SOMMERVILLE, 2011 
Atenção 
Requisito funcional é uma funcionalidade do sistema, é algo que o sistema deve realizar para prover um 
resultado para o usuário. Requisitos funcionais pressupõem interação do sistema com usuários. 
Veja uma lista com alguns exemplos de enunciados dos chamados requisitos funcionais: 
1. O usuário deve ser capaz de pesquisar por nome na base de dados disponível. 
2. O sistema deve designar um identificador único (NUMERO_PEDIDO) para cada pedido do 
usuário. 
3. O sistema deve apresentar o documento selecionado para leitura do usuário. 
Perceba que, em todos os exemplos, estamos definindo atividades que o sistema deve realizar, e, 
em todas essas atividades, o usuário está envolvido, seja fornecendo entradas ou recebendo saídas 
(resultados). 
A especificação de um sistema precisa considerar também como esses requisitos serão entregues. 
Ou seja, quais características de qualidade e quais restrições desejamos impor ao sistema. Assim, definimos 
os chamados requisitos não funcionais. 
Modelagem de Sistemas em UML 
Marcio Quirino - 35 
 
Requisitos não funcionais são restrições aos serviços ou funções oferecidos pelo sistema. Incluem restrições 
de timing, restrições no processo de desenvolvimento e restrições impostas pelas normas. Ao contrário das 
características individuais ou serviços do sistema, os requisitos não funcionais, muitas vezes, aplicam-se ao sistema 
como um todo. SOMMERVILLE, 2011 
Requisitos não funcionais (RNF) são frequentemente mais críticos do que os requisitos funcionais 
(RF). Deixar de atender a um RNF pode significar a inutilização de todo o sistema. Os RNF podem afetar a 
arquitetura geral de um sistema em vez de apenas componentes individuais. No caso de um website, um 
único RNF pode originar uma série de RF relacionados, que, por sua vez, definem os serviços necessários. 
Existem diversas classificações que visam a organizar e prover melhor entendimento sobre os RNF. 
Um exemplo desse tipo de classificação é apresentado na lista a seguir. 
1. Requisitos de produto: usabilidade, eficiência, desempenho, confiança, proteção. 
2. Requisitos organizacionais: ambientais, operacionais, processo de desenvolvimento. 
3. Requisitos externos: reguladores, éticos, legais, contábeis. 
Exemplo 
Aqui estão alguns exemplos de enunciados de requisitos não funcionais: 
✓ O sistema deve estar disponível durante todas as horas normais de trabalho (2ª a 6ª, 8h30 às 17h). 
Períodos de não operação dentro desses intervalos não podem ultrapassar 2 segundos em um dia. 
✓ O sistema deve requerer autenticação dos usuários para permitir acesso. 
✓ O sistema deve implementar disposições de privacidade dos usuários de acordo com a Lei Geral de 
Proteção de Dados. 
Você pode perceber, nesses exemplos, que esses requisitos não indicam o que o sistema realiza, mas como 
ele entrega uma ou mais de suas funcionalidades. 
Diagrama de casos de uso 
A visão de casos de uso da UML apresenta o conjunto de funções (ou usos) que o sistema deve 
executar para atender às necessidades dos usuários. No modelo de casos de uso, o sistema é visto sob a 
perspectiva do usuário. A documentação dos requisitos funcionais em um Diagrama de Casos de Uso dá 
início ao processo de análise do sistema e permite entender sua abrangência e complexidade. 
O objetivo do Diagrama de Casos de Uso é apresentar uma visão geral dos requisitos funcionais do sistema e, 
portanto, ele é o digrama mais abstrato, flexível e simples da UML. 
Esse diagrama é composto pelos seguintes elementos: casos de uso, atores e relacionamentos. A 
figura 1 mostra um exemplo de Diagrama de Casos de Uso para um sistema bancário. 
 
Figura 1 – Exemplo de Diagrama de Casos de Uso, elaborado com ferramenta ASTAH (2021). 
Modelagem de Sistemas em UML 
Marcio Quirino - 36 
 
Os possíveis usos de um sistema são representados pelos casos de uso no diagrama. Um Caso de 
Uso pode estar diretamente associado a um ou mais requisitos funcionais, identificados na etapa de 
levantamento de requisitos do processo de desenvolvimento. 
Conforme observado na figura 1, o caso de uso assume a forma gráfica de uma elipse contendo o 
seu nome no interior; nela, podemos observar quatro casos de usos representados: 
1. Abrir conta corrente 
2. Depositar dinheiro 
3. Sacar dinheiro 
4. Consultar saldo 
O caso de uso é o elemento fundamental do Modelo de Casos de Uso. 
Atenção 
Embora não exista um padrão para nomear casos de uso, a boa prática recomenda utilizar uma frase verbal 
iniciando com verbo no infinitivo, denotando a ação prevista na funcionalidade representada pelo Caso de Uso. 
O segundo elemento do Diagrama de Casos de Uso é o Ator, que é representado no Diagrama de 
Casos de Uso por um boneco palito, com o nome na parte inferior. 
O ator é quem utiliza ou interage em um caso de uso, ou seja, é uma entidade externa que interage com o 
sistema, mas que não faz parte dele. 
Interagir significa trocar informações com o sistema, seja fornecendo ou recebendo essas 
informações. Na figura 1, temos a representação do ator Cliente, que interage com os quatro casos de uso. 
Por exemplo, no caso de uso Consultar Saldo, o ator Cliente informa os dados de sua conta e recebe como 
resposta do sistema o valor de seu saldo. 
O terceiro elemento do Diagrama de Casos de Uso são os Relacionamentos, que permitem associar: 
✓ Casos de uso com seus atores 
✓ Casos de uso com outros casos de uso 
✓ Atores com outros atores 
Saiba mais 
A forma mais comum e obrigatória dos relacionamentos é entre atores e casos de uso, que assume a 
representação gráfica de segmento de reta (uma linha cheia) ligando o ator ao Caso de Uso no qual ele interage. 
Na figura 1, observamos que o ator Cliente interage com os quatro casos de uso presentes nesse 
modelo, portanto, esses elementos gráficos estão ligados por uma reta. 
A seguir, vamos detalhar cada um desses elementos. 
Atores 
Medeiros (2004) explica que atores atuam em casos de uso realizando atividades. O ator não é uma 
entidade específica, mas representa um papel ou aspecto particular de uma entidade. O ator pode 
representar papéis executados por usuários humanos, um componente de hardware, outros sistemas com 
os quais o sistema em desenvolvimento se comunica. Desse modo, o nome do ator deve expressar esse 
papel de forma clara. No exemplo da figura 1, o ator é o papel de cliente do banco. Esse papel pode ser 
assumido pelos diversos clientes do banco. 
Resumindo 
Durante a execução de uma funcionalidade do sistema (um ou mais requisitos funcionais), o ator precisa prover 
entradas (informações) para o sistema e deve receber respostas dele. 
Modelagem de Sistemas em UML 
Marcio Quirino - 37 
 
O ator não é uma entidade específica, mas representa um papel ou aspecto particular de uma 
entidade. O ator pode representar papéis executados por usuários humanos, um componente de hardware, 
outros sistemas com os quais o sistema em desenvolvimento se comunica. Desse modo, o nome do ator 
deve expressar esse papel de forma clara. No exemplo da figura 1, o ator é o papel de cliente do banco. 
Esse papel pode ser assumido pelos diversos clientes do banco. 
Tipos de atores que geralmente aparecem nos sistemas são: 
A. Cargos 
• Por exemplo: empregado, cliente, gerente, vendedor, comprador etc. 
B. Organizações e suas divisões 
• Por exemplo: fornecedor, agência reguladora, administradora de cartões, setor de vendas etc. 
C. Outros sistemas 
• Por exemplo: sistema de vendas, sistema de cobrança, sistema de pagamento etc. 
D. Hardware 
• Por exemplo: sensor de temperatura, leitora de código de barras etc. 
O relacionamento de generalização entre atores indica que uma instância do primeiro ator interage 
com os mesmos tipos de instância de casos de uso do segundo. Porém, o contrárionão é verdade. Os casos 
de uso associados ao ator mais específico nesse relacionamento são exclusivos desse ator, que herda os 
casos de uso associados ao ator mais genérico. A figura 2 mostra um exemplo desse tipo de relacionamento, 
no qual percebemos que tanto o ator Vendedor quanto o ator Supervisor interagem com o caso de uso Fazer 
pedido. No entanto, apenas o Supervisor participa do caso de uso Aprovar crédito. 
 
Figura 2 – Exemplo do relacionamento de generalização entre atores, elaborado com ferramenta ASTAH (2021). Imagem: Flavia 
Maria Santoro. 
Normalmente, o ator inicia a sequência de interações em um caso de uso. Portanto, a forma mais fácil de 
começar a construir um modelo de casos de uso é identificar todos os atores. 
O analista de sistemas pode observar as fontes que devem fornecer informações a serem 
processadas pelo sistema e para quem os resultados do processamento devam ser fornecidos. 
Bezerra (2015) sugere algumas perguntas úteis para guiar os analistas de sistemas: 
1. Que órgãos, empresas ou pessoas utilizarão o sistema? 
2. Que sistemas ou equipamentos vão se comunicar com o sistema a ser construído? 
3. Alguém deve ser informado de alguma ocorrência no sistema? 
4. Quem está interessado em certo requisito funcional do sistema? 
Modelagem de Sistemas em UML 
Marcio Quirino - 38 
 
A partir daí, durante a identificação dos casos de uso, o analista poderá perceber a existência de 
outros atores não identificados nessa etapa. 
Caso de uso 
Caso de Uso é a descrição de uma sequência de interações entre um sistema e um ou mais atores 
externos a esse sistema. De acordo com Bezerra (2015), os casos de usos permitem a um observador 
externo ao sistema entender quais são as funcionalidades fornecidas pelo sistema e quais são os resultados 
externos produzidos por elas. Porém, não é possível saber como o sistema trabalha internamente para 
produzir esses resultados. Um modelo de casos de uso pode conter vários casos de uso, dependendo do 
tamanho e da complexidade do sistema. 
Atenção 
Casos de uso não se limitam à sua representação gráfica; tão importante quanto isso é a sua descrição textual. 
As descrições devem explicar de forma clara, simples e de fácil entendimento, o que o sistema faz, sem entrar nos 
detalhes de como ele deve fazê-lo. Casos de uso facilitam o processo de comunicação com usuários e são utilizados 
para documentar a interação do sistema com eles. Desse modo, casos de uso são úteis, tanto para os profissionais 
envolvidos no desenvolvimento do sistema (analistas, projetistas, programadores, testadores) quanto para seus 
usuários e clientes. A descrição textual de um caso de uso é uma espécie de história por meio da qual contamos como 
um usuário realiza uma ação utilizando o sistema. 
Casos de uso podem relatar as diversas formas de utilização de uma funcionalidade do sistema. 
Assim, podemos definir cada uma dessas formas por meio de cenários. 
Cenário pode ser entendido como a instância de execução de um caso de uso. Portanto, diversos 
cenários para o mesmo caso de uso podem ser escritos. Os cenários podem ser usados para a especificação 
dos casos de testes do sistema. 
Para identificar os casos de uso, podemos pensar em dois tipos que sempre estarão presentes nos 
sistemas: primário e secundário. 
Casos de uso primários 
Estão relacionados diretamente aos objetivos dos atores, ou seja, são as funcionalidades que 
agregam valor aos usuários. Bezerra (2015) sugere uma lista de perguntas para auxiliar os analistas de 
sistemas na descoberta dos casos de uso primários de um sistema: 
✓ Quais são as necessidades e os objetivos de cada ator em relação ao sistema? 
✓ Que informações o sistema deve produzir? 
✓ O sistema deve realizar alguma ação que ocorre regularmente no tempo? 
✓ Para cada requisito funcional, existe um caso de uso (ou mais) para atendê-lo? 
Alguns casos de uso são iniciados não por um ator, mas por um evento temporal. Desse modo, 
normalmente o ator é o tipo de entidade que recebe a informação resultante (por exemplo, um cliente que 
receba uma notificação do sistema). 
Casos de uso secundários 
Esses casos não apresentam uma relação direta de valor para os atores, mas são imprescindíveis 
para o funcionamento do sistema. Por exemplo, a manutenção de cadastros (inclusão, alteração, consulta 
e exclusão das diversas informações que alimentam o sistema). Um sistema bancário precisa cadastrar as 
informações sobre os clientes. 
Relacionamentos 
Os relacionamentos são responsáveis por estabelecer as associações entre atores e casos de uso. 
Modelagem de Sistemas em UML 
Marcio Quirino - 39 
 
Todos os atores devem estar associados explicitamente aos casos de uso com os quais interagem. 
Além disso, podemos estabelecer relacionamentos entre os casos de uso ou entre os atores do sistema. O 
Modelo de Casos de uso permite os seguintes tipos de relacionamentos: comunicação, inclusão, extensão 
e generalização. 
Relacionamento de comunicação 
É uma linha simples que mostra a que caso de uso determinado ator está associado, ou seja, esse 
ator interage com o sistema por meio do caso de uso. Um ator pode se relacionar com mais de um caso de 
uso, e todos os atores devem estar associados a pelo menos um caso de uso. Esse relacionamento foi 
mostrado na figura 1. 
Atenção 
Um erro comum na elaboração de diagramas de casos de uso é estabelecer relacionamentos de comunicação 
entre casos de uso. Não existe troca de informações entre casos de uso, uma vez que são funcionalidades 
independentes entre si. 
Os relacionamentos de inclusão (include), extensão (extend) e generalização são estabelecidos entre casos 
de uso. 
Relacionamento de inclusão 
Tem como objetivo principal a reutilização. Suponha que uma parte dos passos de execução de um 
caso de uso se repita em diversos outros casos de uso. Podemos criar um caso de uso separado e “incluí-
lo” nos demais. A inclusão funciona de forma semelhante à chamada de uma função em um programa. A 
representação gráfica do relacionamento de inclusão é uma linha pontilhada com o estereótipo <<include>> 
apontando do caso de uso inclusor para o incluído. 
A figura 3 mostra um exemplo desse tipo de relacionamento. 
 
Figura 3 – Exemplo do relacionamento de inclusão entre casos de uso, elaborado com ferramenta ASTAH (2021) 
No exemplo da figura 3, o ator Médico participa de dois casos de uso: Fazer pedido de exame e 
Fazer pedido de consulta. Em ambos os casos de uso, é necessário realizar os passos do caso de uso 
Solicitar prontuário. Portanto, este caso de uso é incluído nos dois primeiros. 
Relacionamento de extensão 
Tem como objetivo representar situações em que diferentes sequências de passos possam ser 
inseridas no mesmo caso de uso. Ou seja, dependendo de uma condição, o caso de uso segue um caminho 
diferente. Desse modo, um caso de uso estende outro, permitindo um comportamento eventual. Note que a 
existência do caso de uso estendido deve ser independente da existência de quaisquer casos de uso que o 
estendam. 
A figura 4 mostra um exemplo do relacionamento de extensão. 
Modelagem de Sistemas em UML 
Marcio Quirino - 40 
 
 
Figura 4 – Exemplo do relacionamento de extensão entre casos de uso, elaborado com ferramenta ASTAH (2021) 
Observe no exemplo da figura 4, em que o ator Cliente interage com o caso de uso Realizar compra. 
O caso de uso Validar limite de crédito pode ser necessário nesse contexto, portanto, é estendido para 
Realizar compra. Ambos os casos de uso representam funcionalidades independentes no sistema. 
Relacionamento de generalização 
Pode existir entre dois casos de uso ou entre dois atores (conforme vimos em Ator). Esse 
relacionamento permite que um caso de uso (mais específico) herde características de outro (mais genérico). 
Na generalização entre casos de uso, quando um caso de uso herda de outro, significa que as 
sequências de passos de execução do caso de usomais genérico (pai) valem também para o mais 
específico (filho). Além disso, o caso de uso herdeiro participa de qualquer associação do qual o caso de 
uso mais genérico participe. Isso significa que um ator que interage com o caso de uso pai pode também 
interagir em qualquer caso de uso filho. 
A figura 5 mostra um exemplo do relacionamento de generalização: 
 
Figura 5 – Exemplo do relacionamento de generalização entre casos de uso, elaborado com ferramenta ASTAH (2021) 
Como podemos observar na figura 5, o caso de uso Cadastrar empregado executa uma sequência 
de passos de cadastro para qualquer funcionário. Já os casos de uso mais específicos (Cadastrar vendedor 
e Cadastrar supervisor) herdam esses passos e ainda possuem passos específicos para os tipos de 
funcionários Vendedor e Supervisor, respectivamente. 
Os tipos de relacionamento entre casos de uso abordados permitem manter a descrição dos casos 
de uso mais simples e sem repetições. 
1. A inclusão deve ser usada quando um comportamento se repetir em mais de um caso de 
uso. 
2. A extensão é normalmente usada quando um comportamento que não é executado em 
todas as instâncias de um caso de uso deva ser descrito. 
3. A generalização deve ser aplicada em uma situação em que dois ou mais casos de uso 
possuam comportamentos comuns. 
Modelagem de Sistemas em UML 
Marcio Quirino - 41 
 
2. Especificações textuais 
Reconhecer casos de uso por meio de especificações textuais. 
Especificação e formatos de casos de uso 
Os casos de uso incluídos pelos analistas no Diagrama de Casos de Uso devem ser especificados 
em um formato de narrativa textual, para complementar a representação gráfica sob forma de diagramas. 
Desse modo, o Modelo de Casos de Uso é formado pelo diagrama e pelo conjunto de todas as descrições 
dos casos de uso. 
Atenção 
A descrição textual permite o entendimento mais preciso de qual funcionalidade do sistema trata aquele caso 
de uso. Ela serve como ponto de partida para construção de outros modelos, tais como, Modelo de Classes, ainda na 
fase de análise, e o Diagrama de Sequência, na fase de projeto do desenvolvimento do sistema. 
Comentário 
A UML não propõe uma descrição formal de casos de uso e não existe uma forma padronizada para a escrita 
dessa especificação. Os analistas e, muitas vezes, as empresas definem seus padrões com base em exemplos, boas 
práticas e necessidades particulares de cada projeto de desenvolvimento. As especificações podem ser bem simples, 
abstraindo os detalhes da execução do caso de uso, ou mais complexas, incluindo todo o passo a passo a ser seguido 
para obter os resultados esperados. 
Uma vez que não existe um padrão definido pela UML, a descrição textual de um caso de uso pode 
ser feita em diferentes formatos. O que há em comum em todos esses formatos é a forma de expressão 
narrativa. 
O texto de um caso de uso é uma história que conta as ações ou a sequência de passos de um ou 
mais atores e do sistema para atingir determinado objetivo. Essa narrativa pode ser escrita em um parágrafo 
contínuo, em passos numerados ou em uma tabela contendo uma coluna para cada ator e uma coluna para 
o sistema. 
Atenção 
A descrição de um caso de uso deve ser clara, livre de jargões e termos técnicos, portanto, de fácil 
entendimento não só para a equipe de desenvolvimento, mas para os usuários finais, pois o modelo de casos de uso 
é lido e validado por todos os envolvidos. 
Formato contínuo 
A narrativa é um texto livre. Como um exemplo, considere o caso de uso Consultar saldo na figura 
1. Uma especificação em formato contínuo para esse caso de uso seria: 
Este caso de uso inicia quando o Cliente chega ao caixa eletrônico e insere seu cartão. O Sistema 
requisita a senha do Cliente. Após o Cliente fornecer sua senha e esta ser validada, o Sistema exibe as 
opções de operações possíveis. O Cliente opta por consultar saldo. O Sistema exibe o saldo da conta e o 
caso de uso termina. 
Formato numerado 
Aqui, a descrição desse caso de uso seria: 
1. O Cliente insere cartão no caixa eletrônico. 
2. O Sistema solicita a senha. 
3. O Cliente digita senha. 
4. O Sistema valida a senha e exibe menu de operações disponíveis. 
5. O Cliente seleciona a opção consultar o saldo. 
6. O Sistema exibe o saldo da conta. 
Modelagem de Sistemas em UML 
Marcio Quirino - 42 
 
Formato tabular 
Cliente Sistema 
Insere cartão no caixa eletrônico. 
 Solicita a senha. 
Digita senha. 
 Valida a senha e exibe menu de operações disponíveis. 
Seleciona a opção consultar o saldo. 
 Exibe o saldo da conta. 
Cenário principal e cenários alternativos 
A especificação de um caso de uso descreve a sequência de passos de interação entre o sistema e 
seus atores. A descrição do exemplo do caso de uso Abrir conta corrente, na figura 1, mostra uma sequência, 
um fluxo ou passo a passo mais usual, ou seja, aquela em que acontece exatamente o que era esperado 
nessa interação. 
Saiba mais 
Essa sequência é chamada de cenário (ou fluxo) principal do caso de uso. Nesse cenário, o ator consegue 
atingir seu objetivo seguindo o caminho “feliz”; em outras palavras, nada de excepcional acontece. De acordo com 
Lima (2005), é o fluxo mais óbvio, no qual todas as ações são bem-sucedidas. 
Cada caso de uso possui apenas um cenário principal e ele deve ser descrito de forma clara e 
concisa, sem uso de jargão computacional. Não se esqueça: casos de uso devem ser escritos do ponto de 
vista do usuário e, sempre que possível, com os termos que os usuários possam compreender. 
Agora, imagine que, em nosso exemplo, o Cliente digitou a senha errada. O que aconteceria no fluxo descrito? 
Nada, pois esse problema não é previsto nesse cenário! 
Para essa situação e algumas outras, o modelo de casos de uso prevê a especificação dos cenários 
alternativos e cenários de exceção. 
A. Cenários alternativos 
✓ Nesta situação, o ator pode escolher formas diferentes para chegar ao seu objetivo. Portanto, deve ser 
possível, apesar de não obrigatório, especificar cenários alternativos. Em nosso exemplo da consulta 
de saldo, o Cliente poderia optar por imprimir o saldo em vez de consultá-lo diretamente. 
✓ Um cenário alternativo não é uma exceção, é outra forma de fazer a mesma coisa! 
B. Cenários de exceção 
✓ Devem ser explicitados exceções, problemas ou possíveis erros. Um cenário de exceção representa 
uma anomalia não prevista no cenário principal, como o Cliente digitar sua senha errada. 0 analista 
deve escrever cenários para tratar esse e outros desvios do curso normal de um caso de uso, ou 
mesmo cancelar a realização do caso de uso em questão. 
De acordo com Bezerra (2015), esses cenários possuem as seguintes características: 
✓ Representam erros de operação no cenário principal. 
✓ Não têm sentido fora do contexto do caso de uso no qual ocorre (ou seja, não são casos de 
uso em si). 
✓ Precisam indicar em que passo o caso de uso continua ou, conforme for, indicar que o caso 
de uso está finalizado. 
No exemplo do caso de uso Abrir conta corrente, um cenário de exceção para a situação em que o 
Cliente digitasse sua senha errada poderia ser especificado da seguinte forma: 
A. Cenário Principal 
✓ O Cliente insere cartão no caixa eletrônico. 
✓ O Sistema solicita a senha. 
✓ O Cliente digita senha. 
✓ O Sistema valida a senha e exibe menu de operações disponíveis. 
Modelagem de Sistemas em UML 
Marcio Quirino - 43 
 
✓ O Cliente seleciona a opção consultar o saldo. 
✓ O Sistema exibe o saldo da conta. 
B. Cenário de exceção “Senha incorreta” 
✓ No passo 4, caso a senha seja incorreta: 
o 4a. O Sistema informa que a senha está incorreta e solicita que o Cliente digite novamente. 
o 4b. O caso de uso retorna ao passo 3. 
Observe que o cenário de exceção indica o ponto do cenário principal no qual o problema pode 
ocorrer e o ponto exato para onde o fluxo deve retornar. O analista deve especificar todas as possíveis 
exceçõesou problemas usando esses tipos de cenários. 
Estrutura de especificação de casos de uso 
Como a UML não define um padrão para especificação de casos de uso, você já observou que 
existem algumas formas práticas de apresentar a narrativa ou o passo a passo de execução do caso de uso. 
No entanto, é comum as empresas ou as equipes de desenvolvimento definirem seus próprios padrões de 
estrutura e os tipos de informação a serem apresentados, de modo a manter a qualidade dos documentos 
de requisitos de software. Nesse sentido, você encontrará diversas sugestões de modelos em livros ou sites 
na internet. 
Um exemplo bastante útil é a estrutura descrita por Bezerra (2015). Veja, no quadro 1, uma 
adaptação dessa proposta, que destaca os campos que poderiam compor a descrição de um caso de uso. 
Você pode tomar como base essa proposta e criar um padrão para seus projetos. 
1. Identificador: código único para cada caso de uso que permite fazer a rastreabilidade com 
outros elementos e modelos. Por exemplo, com casos de teste e regras de negócio, UC01. 
2. Nome: cada caso de uso tem um nome único que o identifica; é o nome que aparece no 
Diagrama de Casos de Usos. O nome do caso de uso é uma frase verbal iniciada por verbo 
no infinitivo. É importante ter cuidado com coerência e clareza ao nomear um caso de uso. 
Por exemplo, o nome do caso de uso UC01 é “Criar conta corrente”. 
3. Objetivo: declaração sucinta do objetivo do ator no caso de uso. Para o caso de uso Criar 
conta corrente, o Objetivo seria: “O objetivo deste caso de uso é permitir que o Cliente do 
banco crie uma nova conta corrente”. 
4. Ator primário: nome do ator que inicia o caso de uso ou ator que recebe o resultado do 
caso de uso; um caso de uso possui apenas um ator primário. Para o caso de uso Criar 
conta corrente, o Ator primário seria: “Cliente”. 
5. Atores secundários: nomes dos demais atores que atuam no caso de uso. Para o caso de 
uso Criar conta corrente, um ator secundário seria: “Gerente da agência”. 
6. Pré-condições: condições assumidas como verdadeiras para que o caso de uso tenha 
início; um caso de uso pode conter zero ou mais pré-condições. Por exemplo, em um caso 
de uso Criar conta corrente, uma pré-condição poderia ser “Cliente cadastrado com CPF 
válido”. 
7. Cenário (ou fluxo) principal: sequência de passos que normalmente acontece quando o 
caso de uso é utilizado com sucesso; toda descrição de caso de uso deve ter um fluxo 
principal. 
8. Cenários (ou fluxos) alternativos e de exceção: sequência de passos que apresentam 
formas de execução diferentes da descrita no fluxo principal ou situações de exceções e 
erros que devem ser tratadas pelo sistema. Não há obrigatoriedade de existirem fluxos 
alternativos ou de exceção em um caso de uso. 
Modelagem de Sistemas em UML 
Marcio Quirino - 44 
 
9. Pós-condições: estado do sistema após o caso de uso ter sido executado; tipicamente, 
uma pós-condição descreve que uma informação foi alterada, excluída ou inserida no 
sistema. Uma boa prática é usar verbo no particípio passado para descrever pós-condições. 
Por exemplo, em um caso de uso Criar conta corrente, uma pós-condição seria “conta 
corrente criada”. 
10. Regras de negócio: a descrição de um caso de uso pode fazer referência a uma ou mais 
regras de negócio. Aprenda mais sobre Regras de Negócio em Explore +. 
Especificação de casos de uso com inclusão e extensão 
A UML também não define uma forma padrão para a escrita de casos de uso de inclusão ou extensão. 
No entanto, geralmente fazemos referência ao caso de uso incluído/estendido na descrição do caso de uso 
que o inclui/estende. 
A. Casos de uso com inclusão 
✓ Para a situação dos casos de uso de inclusão, a seguinte sintaxe pode ser usada: Include (nome do 
caso de uso incluso) no ponto da descrição da sequência de interações em que o caso de uso deve 
ser inserido. 
B. Casos de uso com extensão 
✓ Para a situação dos casos de uso de extensão, devemos lembrar que o caso de uso estendido existe 
independentemente de outros casos de uso que o estendam. Ele possui a descrição completa de sua 
sequência de passos. Se o ator escolhe acessar o caso de uso estendido, ele executa o fluxo de ações 
desse caso de uso e retorna para o ponto do cenário em que estava antes. 
A especificação dos pontos de extensão em um caso de uso é feita normalmente dentro da descrição 
textual do caso de uso extensor. A descrição de um ponto de extensão deve indicar em que ponto (ou 
pontos) do caso de uso estendido pode-se inserir o comportamento do extensor, e podem existir vários 
pontos no estendido em que o extensor pode ser ativado. 
Atenção 
Além da inclusão e extensão, um relacionamento de generalização requer uma forma de especificação, na 
descrição do caso de uso herdeiro, de quais passos do caso de uso pai estão sendo redefinidos. O analista pode criar 
marcadores no caso de uso pai. Esses marcadores podem, então, ser referenciados na descrição do caso de uso filho 
para especificar que passos estão sendo redefinidos ou onde está sendo definida uma extensão do comportamento do 
pai. 
3. Domínio de aplicação 
Identificar classes e seus relacionamentos em um domínio de aplicação com uso de Diagrama de 
Classes 
Conceito e elementos de uma classe 
A abordagem de desenvolvimento de sistemas orientada a objetos assume que um sistema é uma 
coleção de entidades – os objetos – que se comunicam e realizam ações. A interação entre objetos é a 
forma de execução de uma funcionalidade do software. 
Essa abordagem se baseia nos seguintes princípios listados por Bezerra (2015): 
✓ Qualquer coisa é um objeto. 
✓ Objetos realizam tarefas por meio da requisição de serviços a outros objetos. 
✓ Cada objeto pertence a uma classe, ou seja, classe é uma entidade que agrupa e abstrai 
objetos similares. 
✓ Uma classe funciona com repositório para comportamento associado aos objetos 
instanciados a partir dela. 
Modelagem de Sistemas em UML 
Marcio Quirino - 45 
 
✓ Classes são organizadas em hierarquias. 
Atenção 
A UML é a linguagem padrão que permite a elaboração dos diversos modelos e das perspectivas de um sistema 
na abordagem da orientação a objetos. Classes (e seus objetos) são os componentes básicos dessa abordagem. 
Objetos são entidades do mundo real que podemos observar. Por exemplo, um objeto pode ser um 
carro, uma fruta, uma empresa, um empregado da empresa, um concerto de música, um restaurante, um 
pedido de comida nesse restaurante, entre muitos outros. 
Quando pensamos nesses objetos em termos de grupos de coisas, por exemplo, cada pessoa que 
assiste a aulas em uma turma é um objeto diferente, mas, se abstrairmos esses objetos, observando suas 
características comuns, criamos o conceito de Aluno, o qual é denominado, então, de Classe. Uma classe 
de objetos com caraterísticas comuns, tais como: estão matriculados em uma turma e assistem a aulas. 
Uma classe pode ser definida como uma descrição de atributos (características) e serviços (ações) comuns a 
um grupo de objetos. 
Bezerra (2015) ressalta que uma classe pode ser entendida como uma espécie de molde, a partir do 
qual objetos podem ser construídos. Portanto, é comum afirmarmos que um objeto é uma instância de uma 
classe. Cada objeto do mundo real é único, uma classe abstrai o tipo de objeto e permite que novos objetos 
sejam criados a partir desse modelo. Se uma nova pessoa se matricula na turma, ela é um novo objeto 
instanciado a partir da classe Aluno. 
Quando estamos tratando da modelagem de um sistema, somente um subconjunto de características 
do grupo de objetos pode ser relevante. Portanto, uma classe representa uma abstração das características 
relevantes do mundo real para aquele conjunto de objetos. 
Exemplo 
Voltando aos nossos alunos, as características relevantes desses objetos, para um sistema acadêmico, 
poderiam ser número de matrícula, idade e estilo de aprendizagem; mas outras,tais como o esporte favorito ou número 
do calçado, talvez não façam parte do interesse desse sistema. 
A estrutura de uma classe é composta de atributos e de operações. 
Os atributos descrevem os dados que deverão ser armazenados pelos objetos dessa classe (suas 
características). Cada atributo de uma classe é de um tipo de dados e possui um conjunto de valores que 
esse atributo pode assumir, chamado de domínio. Veja um exemplo na figura 6. 
As operações apresentam as ações que os objetos de uma classe podem realizar. Como são ações, 
costumam ser nomeadas com uso de um verbo e um complemento, e terminam com um par de parênteses 
(funções em linguagens de programação). Ao contrário dos atributos, que para cada objeto têm o seu próprio 
valor, os objetos de mesma classe compartilham as suas operações. Em outras palavras, todos os objetos 
de uma classe realizam as mesmas ações. Veja o exemplo de uma operação da classe Aluno na figura 6. 
 
Figura 6: Exemplo de Classe e seus atributos e operações, elaborado com ferramenta ASTAH (2021) 
Modelagem de Sistemas em UML 
Marcio Quirino - 46 
 
Na figura 6, observamos que a representação de uma classe é feita por meio de um retângulo com 
três compartimentos: nome da classe, lista de atributos e lista de operações. Você também pode perceber 
a sintaxe de especificação dos atributos e operações. 
Um atributo é especificado no seguinte formato: 
[visibilidade] nome: tipo = valor_inicial 
Visibilidade de um atributo diz respeito ao seu nível de acesso, ou seja, permite definir quais atributos 
de um objeto são acessíveis por outros objetos. Essa propriedade serve para implementar o encapsulamento 
da estrutura interna da classe. A visibilidade de um atributo pode ser: 
 
Somente as propriedades que são realmente necessárias ao exterior da classe devem ser definidas 
com visibilidade pública. Todo o resto é escondido dentro da classe por meio das visibilidades protegida 
(visível para subclasses da classe em que o atributo foi definido) e privativa (invisível externamente à classe 
em que o atributo está definido). Com visibilidade de pacote, o atributo é visível a qualquer classe que 
pertença ao mesmo pacote no qual está definida a classe. Como veremos no módulo seguinte, um pacote 
é um agrupamento de diagramas UML. 
O elemento nome, única parte obrigatória na sintaxe do atributo, corresponde ao nome do atributo. 
O elemento tipo, que especifica o tipo do atributo, é dependente da linguagem de programação na qual a 
classe será implementada. Por exemplo: int, float, boolean. No exemplo da figura 6, o atributo matrícula é 
do tipo int. 
É possível declarar o valor inicial que o atributo assume quando um objeto daquela classe for 
instanciado. Desse modo, sempre que um objeto de uma classe é instanciado, o valor inicial declarado é 
automaticamente definido para o atributo. Em nosso exemplo, quando um novo aluno é inserido no sistema, 
assumimos que seu estiloAprendizagem é aula prática. 
Uma operação é especificada no seguinte formato: 
visibilidade nome(parâmetros): tipo-retorno {propriedades} 
O elemento nome corresponde ao nome dado à operação, em que normalmente usamos verbos que 
denotem a ação realizada por essa operação (no exemplo, assistirAula). Uma operação é ativada 
(executada) quando um objeto envia uma mensagem para outro, sendo essa mensagem o nome da 
operação. 
Do mesmo modo que os atributos, a visibilidade pode ser pública (+), privada (-), protegida (#) ou de pacote 
(~). 
Os parâmetros de uma operação são informações que ela recebe do objeto que envia a mensagem 
para requisitar a execução da operação. Uma operação pode ter zero ou mais parâmetros, que devem ser 
separados por vírgulas. Parâmetros têm seu tipo definido: tipo retorno representa o tipo de dados do valor 
retornado por uma operação. 
Visão geral do diagrama de classes 
O Diagrama de Classes da UML é o modelo em que representamos as classes de um sistema, 
incluindo os detalhes sobre seus atributos e suas operações, e como essas classes se relacionam. 
Modelagem de Sistemas em UML 
Marcio Quirino - 47 
 
Portanto, a elaboração do Diagrama de Classes é fundamental em todo o processo de 
desenvolvimento que segue a abordagem da orientação a objetos. 
Os diversos componentes de um Diagrama de Classes especificam as classes que serão realmente 
implementadas (ou seja, codificadas em uma linguagem de programação), sendo a base para a criação dos 
principais objetos e as interações entre eles. 
Atenção 
Góes (2014) explica que o Diagrama de Classes é o modelo mais importante da UML, pois permite a 
representação dos elementos da base de dados do sistema. Portanto, facilita a comunicação entre a equipe de 
desenvolvimento e com os usuários finais. 
O Diagrama de Classes também explicita as demandas de dados e informações dos atores, que são 
declaradas nos casos de uso. Diagramas de classes são usados para expressar graficamente os conceitos 
a serem manipulados por um sistema, bem como as ações esperadas, e para fornecer uma descrição 
independente de implementação dos tipos utilizados em um sistema, ou seja, os modelos de dados. 
Comentário 
Costumamos dizer que esse diagrama destaca um aspecto estrutural estático do sistema, pois representa a 
estrutura interna do sistema, mas não como os objetos do sistema interagem no decorrer do tempo. As operações 
mostram quais são as possíveis interações entre os objetos, mas não explicitam em que momento serão invocadas. 
O Diagrama de Classes é utilizado na construção do modelo de classes desde o nível de análise até 
o nível de especificação. O diagrama evolui à medida que o processo de desenvolvimento do sistema 
avança. 
O que queremos dizer com “evolui”? 
Resposta 
Significa que vamos acrescentando detalhes e refinando o diagrama, tanto em termos de atributos e operações 
quanto na forma como associamos as classes. 
É comum chamarmos esse diagrama que evolui sucessivamente de modelo de classes de análise, 
modelo de classes de projeto e modelo de classes de implementação, fazendo referência às etapas do 
processo de desenvolvimento. 
Modelo de classes de análise 
• É composto por elementos identificados na etapa de análise; é basicamente formado por classes 
relacionadas a conceitos do domínio da aplicação. Seu objetivo é descrever o problema 
representado pelo sistema a ser desenvolvido. É um modelo conceitual; com foco em o que o 
sistema deve tratar, não considera características técnicas da solução a ser utilizada. Em termos 
práticos, nesse modelo, incluímos as classes, a lista de atributos e a lista básica de operações, 
sem os detalhes de tipos de dados, ou parâmetros das funções, por exemplo. O modelo de casos 
de uso e o modelo de classes de análise são os dois principais modelos criados na fase de 
análise. 
Modelo de classes de projeto 
• É construído na atividade de projeto do desenvolvimento e considera alguns detalhes da solução 
de software a ser utilizada, mas ainda em um nível alto de abstração. Nessa etapa do processo 
de desenvolvimento, é comum percebermos a necessidade de criar novas classes, uma vez que 
o foco agora está em como o sistema deve funcionar. Ou seja, como o sistema vai entregar suas 
funcionalidades. Os detalhes incluídos são relacionados, por exemplo, com tipos e domínio dos 
atributos; parâmetros, entradas e saídas das operações etc. Novas classes criadas podem ser 
de interfaces do sistema, bancos de dados, entre outras. 
Modelagem de Sistemas em UML 
Marcio Quirino - 48 
 
Modelo de classes de implementação 
• É a codificação das classes definidas nas fases de análise e projeto em alguma linguagem de 
programação, normalmente uma linguagem orientada a objetos (por exemplo, C++, Java, C# 
etc.). O modelo de implementação é construído na atividade de codificação de um processo de 
desenvolvimento 
O exemplo da figura 7, extraído da obra de Bezerra (2015), ilustra a representaçãode uma classe 
em diferentes níveis de abstração. Observe que, em cada iteração do processo de desenvolvimento, são 
acrescentados mais detalhes sobre os atributos e operações. 
 
Figura 7 – Exemplo de Classe ContaBancária em diferentes níveis de abstração. 
Na especificação mais detalhada da classe ContaBancária do exemplo da figura 7, você pode 
observar a presença dos símbolos – e + antes dos nomes dos atributos e das operações, que representam 
sua visibilidade. Nessa mesma representação, temos as operações com seus parâmetros de entrada 
especificados (a Quantia em creditar e debitar). 
Relacionamentos no diagrama de classes 
Você já viu que especificar uma classe diz respeito a definir seus atributos e operações. Mas classes 
não existem isoladas, elas só fazem sentido quando se relacionam a outras, pois os objetos originados a 
partir delas trocam informações uns com os outros; e nisso reside a implementação de um sistema orientado 
a objetos. 
Dizemos que os objetos colaboram uns com os outros. O desenho do Diagrama de Classes mostra 
como os objetos instanciados a partir dessas classes podem se relacionar. Existem diferentes tipos de 
relacionamentos possíveis, bem como diversos detalhes que podem ser acrescentados no diagrama para 
melhorar sua semântica. Trataremos deles a seguir. 
A forma de relacionamento mais comum é chamada de associação e é representada no Diagrama 
de Classes por uma linha (normalmente um segmento de reta) ligando as classes às quais pertencem os 
objetos relacionados. 
A figura 8 ilustra associações entre classes: 
1. Cliente faz Pedido; 
2. Professor ministra Disciplina. 
Mas qual é o significado dessas associações? Quando ligamos as classes Cliente e Pedido significa 
que, durante a execução do sistema, haverá a possibilidade de troca de mensagens entre objetos dessas 
classes. 
Modelagem de Sistemas em UML 
Marcio Quirino - 49 
 
 
Figura 8 – Associações simples entre classes, elaborado com ferramenta ASTAH (2021) 
As associações possuem diversas características que podem ser representadas, por escolha do 
analista, para prover um melhor entendimento do modelo: nome, multiplicidades, tipo de participação, 
direção de leitura e papéis. 
Nome 
• Conforme a figura 8 mostra, os nomes das associações (ministra, faz) descrevem a relação que 
é estabelecida entre os objetos das classes associadas. Normalmente, são usados verbos ou 
expressões verbais para nomear associações. 
Multiplicidades 
• As associações permitem representar a informação dos limites inferior e superior da quantidade 
de objetos aos quais outro objeto pode estar associado: são as chamadas multiplicidades. Cada 
associação em um Diagrama de Classes possui duas multiplicidades, uma em cada extremo da 
linha que a representa. Os símbolos que representam uma multiplicidade são apresentados na 
tabela 1. 
Apenas 1 1..1 (ou 1) 
Zero ou Muitos 0..* (ou *) 
Um ou Muitos 1..* 
Zero ou Um 0..1 
Intervalo Específico li..ls 
Tabela 1 – Multiplicidades em um Diagrama de Classes. Tabela: Flavia Maria Santoro 
• Na figura 9, mostramos o exemplo com as multiplicidades correspondentes. Esses novos 
diagramas expressam mais do que o anterior. Eles informam que um professor pode ministrar 
nenhuma (zero) e no máximo três disciplinas (0..3). Uma disciplina precisa ser ministrada por 
pelo menos um professor, mas pode ser ministrada por muitos (1..*). Já um cliente pode fazer 
nenhum (zero) pedido, sem um limite máximo (0..*), e um pedido precisa ser feito por um cliente 
(1). 
 
Figura 9 – Associações simples entre classes com multiplicidades, elaborado com ferramenta ASTAH (2021) 
Modelagem de Sistemas em UML 
Marcio Quirino - 50 
 
Tipo de participação 
• Indica a necessidade ou não da existência dessa associação entre objetos. A participação pode 
ser obrigatória ou opcional. Se o valor mínimo da multiplicidade de uma associação é igual a 1 
(um), significa que a participação é obrigatória. Caso contrário, a participação é opcional. Por 
exemplo, a participação de Cliente e Professor nos exemplos da figura 9 é obrigatória, e a de 
Disciplina e Pedido é opcional. Isso significa que pode existir professores e clientes sem 
necessariamente estarem ministrando disciplinas ou fazendo pedidos. 
Direção da leitura 
• A direção de leitura indica como a associação deve ser lida. Essa direção é representada por um 
pequeno triângulo posicionado próximo a um dos lados do nome da associação (como nos 
exemplos da figura 9). 
Papéis 
• Quando um objeto participa de uma associação, ele tem um papel específico nela. Uma 
característica complementar à utilização de nomes e de direções de leitura é a indicação de 
papéis (roles) para cada uma das classes participantes em uma associação. 
Classes associativas 
São classes que estão ligadas a associações, em vez de estarem ligadas a outras classes. São 
também chamadas de classes de associação. Esse tipo de classe normalmente aparece quando duas ou 
mais classes estão associadas e seja necessário manter informações sobre a associação que existe entre 
elas. 
É muito comum a necessidade de classes associativas em relacionamentos muitos para muitos, ou 
seja 0..* 0..*. Uma classe associativa é representada pela mesma notação utilizada para uma classe comum. 
A diferença é que aquela é ligada por uma linha tracejada a uma associação. 
A figura 10 mostra um exemplo de classe associativa. Um professor ministra uma disciplina em 
determinada turma (que possui número, ano e semestre específicos). 
 
Figura 10 – Exemplo de classe associativa, elaborado com ferramenta ASTAH (2021) 
Autoassociação 
Tem como objetivo relacionar objetos da mesma classe, mas cada objeto tem um papel distinto nessa 
associação. Por exemplo, na figura 11, objetos da classe Empregado estão associados entre si, um 
empregado como supervisor, que supervisiona outros empregados. 
A figura 11 ilustra, também, o uso de papéis (roles) para distinguir o lado supervisor (multiplicidade 
1) do lado supervisionado (lado muitos) da autoassociação. 
Modelagem de Sistemas em UML 
Marcio Quirino - 51 
 
 
Figura 11 – Exemplo de autoassociação, elaborado com ferramenta ASTAH (2021) 
Todo-parte 
Existe uma categoria especial de relacionamento que possui uma semântica (significado) particular: 
todo-parte. 
Uma relação todo-parte entre dois objetos indica que um dos objetos está contido (é uma parte do) no outro, 
ou seja, o objeto do lado todo contém o do lado parte. 
A UML define dois tipos de relacionamentos todo-parte: a agregação e a composição. 
Atenção 
A agregação e a composição são casos especiais da associação, logo, todas as características válidas para 
uma associação valem para agregações e composições. Agregações/composições são assimétricas no sentido que, 
se um objeto A é parte de um objeto B, o objeto B não pode ser parte do objeto A. 
Agregações e composições propagam comportamento, pois um comportamento que se aplica a um 
todo, automaticamente se aplica às suas partes. Nas agregações/composições, as partes são normalmente 
criadas e destruídas pelo todo. 
Uma agregação é representada graficamente como uma linha que conecta as classes relacionadas, 
com um diamante (losango) branco perto da classe que representa o todo. Uma composição é representada 
por meio de um diamante negro. 
A figura 12 apresenta um exemplo de relacionamento de composição. Um pedido é composto de 
vários itens de pedidos. 
 
Figura 12 – Exemplo de relacionamento de composição, elaborado com ferramenta ASTAH (2021) 
A diferença entre agregação e composição é sutil, pois não é muito bem definida na UML. Ambas 
são relacionamentos todo-parte, mas pode-se dizer que, na agregação, a parte pode existir 
independentemente do todo; na composição, a existência da parte depende da existência do todo. 
No exemplo da figura 12, não faria sentido a existência de ItemPedido se não existisse Pedido. 
Exemplo 
Um exemplo de agregaçãoseria a associação entre Equipe e Jogador, em que este último é parte da Equipe; 
entretanto, um Jogador existe independentemente da existência da Equipe. Isso significa que a destruição de uma 
Equipe (todo) não implicaria na destruição do Jogador (parte), como ocorre na composição. 
Modelagem de Sistemas em UML 
Marcio Quirino - 52 
 
Herança 
Outro relacionamento com semântica específica é o de herança, ou relacionamento de 
generalização/especialização. Esse tipo de relacionamento, diferente dos que você estudou, significa um 
relacionamento de generalidade ou especialidade entre as classes envolvidas. Por exemplo, o conceito 
animais é mais genérico que o conceito mamífero, que, por sua vez, é mais genérico que o conceito macaco. 
Nesse tipo de relacionamento, as classes mais específicas herdam características das classes mais genéricas. 
Usamos o termo subclasse para denotar a classe que herda as propriedades de outra classe 
mediante uma generalização. A classe que possui propriedades herdadas por outras classes é chamada de 
superclasse. No Diagrama de Classes, a herança é representada por uma flecha partindo da subclasse em 
direção à superclasse. Um relacionamento de herança representa um conjunto de objetos que compartilham 
um conjunto comum de propriedades (atributos, operações, associações), características inerentes à 
superclasse, além de possuírem características próprias. 
A figura 13 mostra um exemplo do relacionamento de herança. 
 
Figura 13 – Exemplo de relacionamento de herança, elaborado com ferramenta ASTAH (2021) 
Nesse exemplo, um professor pode ser do tipo Tempo Integral ou Horista. Ambos possuem nome e 
matrícula, porém, o Professor Tempo Integral possui salário, e o Professor Horista possui valor de hora 
paga. Note que, além dos atributos da classe genérica (no exemplo, Professor), as classes especializadas 
herdam também as operações (não especificadas no exemplo), assim como os relacionamentos (no 
exemplo, a associação ministra) da classe genérica. 
4. Emprego de Diagramas de Objetos e de Pacotes 
Empregar Diagramas de Objetos e de Pacotes para apoiar a especificação de um sistema. 
Visão geral do diagrama de objetos 
Além do Diagrama de Classes, a UML define um segundo tipo de diagrama na perspectiva estática 
e estrutural do sistema: o Diagrama de Objetos. 
Assim como objetos são instâncias de classes, os Diagramas de objetos podem ser vistos como instâncias de 
Diagramas de Classes. 
Um Diagrama de Objetos UML representa uma instância específica de um Diagrama de Classes em 
determinado momento. Portanto, do ponto de vista gráfico, ele é bastante parecido com o Diagrama de 
Classes. 
 
 
Modelagem de Sistemas em UML 
Marcio Quirino - 53 
 
Saiba mais 
Bezerra (2015) afirma que um Diagrama de Objetos exibe uma “fotografia” do sistema em certo momento, 
mostrando as associações estabelecidas entre objetos, de acordo com suas interações e com os valores que seus 
atributos assumem. 
Um Diagrama de Objetos mostra os valores de atributos do conjunto de objetos que ele representa 
e como esses objetos se relacionam entre si. Um objeto, ou uma instância de uma classe, possui uma 
identificação única (não existem dois objetos iguais) e os seus atributos assumem determinados valores em 
um momento específico no tempo. 
Os valores dos atributos podem sofrer alterações e, nesse caso, dizemos que o objeto sofreu uma 
mudança de estado. 
Exemplo 
Por exemplo, o objeto Maria, criado a partir de uma classe Pessoa, possui como valor do atributo Endereço: 
Rua das Palmeiras. Quando Maria muda de endereço, o valor do atributo passa a ser o novo endereço: Avenida Vieira 
Souto. Assim, em um diagrama de estados, o objeto Maria seria representado com o valor do atributo Endereço quando 
o diagrama foi criado. 
No Diagrama de Objetos, não faz sentido falar em operações, que são as mesmas para todos os 
objetos de uma classe. Portanto, nesse diagrama, o elemento principal, o Objeto, possui apenas o nome e 
os atributos com seus valores. 
Em um Diagrama de Objetos, cada objeto é representado por um retângulo com dois 
compartimentos. O compartimento superior mostra a identificação do objeto na forma de texto sublinhado: 
:NomeClasse 
nomeObjeto: NomeClasse 
Lembre-se de que cada objeto é único e, portanto, esse nome identifica exclusivamente um objeto. 
A identificação do objeto pode ser omitida. 
Por exemplo: 
Marta: Professor 
:Professor 
No primeiro caso, o objeto da classe professor foi identificado com o nome Marta; no segundo, o 
analista optou por não caracterizar o objeto em si, significando que pode estar se referindo a qualquer objeto 
daquela classe. 
A segunda representação é frequentemente usada na etapa de projeto do processo de 
desenvolvimento de sistemas, quando se representa a interação entre objetos (instâncias de classes) nos 
diagramas de sequência ou de comunicação. 
No compartimento inferior (cuja utilização é opcional), aparecem os valores que os atributos definidos 
na classe assumem para este objeto. Dessa forma, deve mostrar uma lista de pares da forma: nome do 
atributo = valor do atributo. 
A figura 14 reproduz o exemplo de Diagrama de Objetos mostrado por Bezerra (2015). Nesse 
exemplo, uma instância de pedido é associada a três instâncias de ItemPedido. Cada item, por sua vez, está 
ligado a um produto. Os valores para cada atributo de cada objeto são apresentados nesse diagrama. 
Modelagem de Sistemas em UML 
Marcio Quirino - 54 
 
 
Figura 14 – Exemplo de Diagrama de Objetos (BEZERRA, 2015) 
Você pode observar também que não existem detalhes nos relacionamentos, tal como no Diagrama 
de Classes. Os relacionamentos no Diagrama de Objetos mostram uma situação específica em que aqueles 
objetos se encontram, não as possíveis relações entre eles. 
No diagrama da figura 14, temos um Pedido que possui 3 Itens associados a ele, e 1 Produto 
associado respectivamente a cada Item. 
A figura 15 mostra outro exemplo de Diagrama de Objetos, em que observamos que o Cliente Pablo 
está associado a 2 contratos de aluguel de carros diferentes. Cada contrato tem seu identificador e atributos 
próprios. Esse diagrama ajuda no entendimento da situação desse cliente. 
 
Figura 15 – Exemplo de Diagrama de Objetos 
Saiba mais 
De acordo com Bezerra (2015), Diagramas de Objetos não são muito utilizados na prática. Mas eles podem 
ser úteis na atividade de validação no processo de desenvolvimento, pois permitem ilustrar e esclarecer certos aspectos 
de um Diagrama de Classes. 
Mesmo antes de criar um Diagrama de Classes, você pode criar um Diagrama de Objetos para 
descobrir fatos sobre elementos específicos e suas associações ou para esclarecer dúvidas por meio de 
exemplos específicos. Além disso, ajuda na construção dos diagramas de interação (de sequência ou 
comunicação), pois estes utilizam a mesma notação. 
Em resumo, os Diagramas de Objetos podem ter as seguintes aplicações: 
✓ Ajudar na análise de uma interação específica. 
✓ Mostrar uma visão geral de alto nível do sistema. 
✓ Validar um Diagrama de Classes. 
Modelagem de Sistemas em UML 
Marcio Quirino - 55 
 
Os Diagramas de Objetos podem ser usados também para verificar se o sistema foi desenvolvido 
conforme os requisitos, e até mesmo para analisar se uma regra de negócio está sendo cumprida. 
Dica 
Para criar esses diagramas, procure exibir associações entre objetos somente com uma ligação (por exemplo, 
uma linha única juntando dois objetos, sem setas ou outros detalhes), pois um Diagrama de Objetos tem por objetivo 
mostrar somente a existência de associações e não os tipos de associações, como em um Diagrama de Classes. Além 
disso, evite representar todos os objetos em um único Diagrama de Objetos, pois ele apresenta apenas um estado do 
objeto. 
Visão geral do diagrama de pacotes 
Muitos sistemas possuem uma quantidade bastante grande de casos de uso e classes, portanto, 
representá-losem um único diagrama é inviável devido à sua complexidade para o entendimento. Para 
resolver esse problema, usamos o elemento da UML chamado de pacote (do inglês, package). 
Os pacotes servem para agrupar diagramas, tais como classes, casos de uso, ou mesmo outros 
pacotes. Normalmente, os grupos de classes são associados com módulos de programação do sistema. 
Uma classe só pode aparecer uma vez no mesmo pacote, mas pode estar presente em vários pacotes 
diferentes. 
Um pacote representa um grupo de elementos que pode se relacionar com outros pacotes por meio 
de uma relação de dependência. É possível definir a visibilidade (conforme estudamos no Módulo 3) de 
pacotes e dos elementos contidos nele. Pacotes são úteis para prover uma visão geral de um conjunto 
grande de objetos; para organizar um modelo grande e agrupar seus elementos. 
A representação gráfica de um pacote é um retângulo com uma aba no canto superior esquerdo, 
com o nome do pacote na aba ou no centro do retângulo. A figura 16 mostra um exemplo de pacotes que 
agrupam conjuntos de classes. O pacote Módulo Docente agrupa as classes relacionadas com professores, 
o Módulo Discente agrupa as classes relacionadas com alunos, e o Módulo Organização Curricular agrupa 
classes pertinentes à matriz curricular, em um sistema acadêmico. 
 
Figura 16 – Exemplo de representação de pacote, elaborado com ferramenta ASTAH (2021) 
Modelagem de Sistemas em UML 
Marcio Quirino - 56 
 
Desdobramentos dos diagramas no pacote 
As ligações entre pacotes são relacionamentos de dependência. Um pacote P1 depende de outro 
pacote P2, se algum elemento contido em P1 depende de algum elemento contido em P2. 
A figura 17 mostra o Diagrama de Pacotes do exemplo do sistema acadêmico sem os 
relacionamentos explícitos entre as classes internas; apenas com a representação de dependências 
existentes entre os próprios pacotes. Ou seja: 
Os pacotes se relacionam com outros pacotes por meio de um vínculo de dependência. 
 
Figura 17 – Exemplo de representação de dependências entre pacote, elaborado com ferramenta ASTAH (2021) 
As dependências entre pacotes mostram que um pacote depende ou influencia outro. As 
dependências podem ser divididas em dois tipos: acesso e importação. 
A. Dependência de acesso 
✓ Indica que um pacote requer assistência das funções de outro pacote. 
B. Dependência de importação 
✓ Indica que uma funcionalidade foi importada de um pacote para outro. 
Ambas são representadas por uma linha pontilhada com uma seta apontando para o pacote 
dependente. 
Pacotes também podem formar grupos de pacotes e hierarquias. A figura 18 (Bezerra, 2015) mostra 
como pacotes podem ser agrupados dentro de outros pacotes, formando uma hierarquia de contenção. 
 
Figura 18 - Agrupamento de pacotes (BEZERRA, 2015) 
Modelagem de Sistemas em UML 
Marcio Quirino - 57 
 
Além disso, como já vimos, existem três tipos de visibilidade de elementos dentro dos pacotes: 
A. + (público) 
✓ Visível por todos que importam ou acessam o pacote. 
B. # (protegido) 
✓ Visível só pelos pacotes filhos (por relação de generalização). 
C. – (privado) 
✓ Visível só por outros elementos do pacote. 
Atenção 
Note que aqui não se aplica a visibilidade de pacotes (~), que é aplicável tão somente a atributo de classe que 
seja visível a qualquer classe pertencente ao mesmo pacote no qual está definida a classe. 
No contexto da modelagem de casos de uso, os pacotes podem ser utilizados com diversos objetivos. 
Alguns desses objetivos são: estruturar o modelo de casos de uso com base nos grupos de usuários do 
sistema; definir a prioridade na qual os casos de uso serão desenvolvidos; e definir o grau de correlação 
entre os casos de uso. 
O critério para criar os pacotes é subjetivo e depende da visão e das necessidades do projetista. 
Comentário 
Normalmente, o projetista define uma semântica e aloca elementos similares em um pacote, pois esses 
elementos tendem a ser alterados em conjunto no mesmo pacote. 
Um pacote bem estruturado tem as seguintes características: 
1. É coeso em relação aos elementos incluídos. 
2. É fracamente acoplado em relação à exportação apenas dos elementos que os outros 
pacotes precisam enxergar. 
3. Não contém muitos alinhamentos, ou seja, possui um conjunto equilibrado de elementos. 
Ao especificar um pacote, é uma prática usar a forma simples de ícone retangular, obscurecendo o 
seu conteúdo. No caso da necessidade de apresentar o seu conteúdo interno (como nas figuras 16 e 17), 
deve-se mostrar apenas os elementos necessários para a compreensão do significado. 
Esse diagrama também é muito utilizado para ilustrar a arquitetura de um sistema, mostrando o 
agrupamento de suas classes. A figura 19 mostra um exemplo de Diagrama de Pacotes usado com o objetivo 
de organizar as classes de acordo com as camadas da arquitetura do sistema. Tipicamente, um sistema 
pode ser organizado conforme o padrão de projeto Model (Modelo), View (Visão) e Control (Controle). 
Modelagem de Sistemas em UML 
Marcio Quirino - 58 
 
 
Figura 19 – Exemplo de diagrama de pacotes 
O pacote tem uma grande similaridade com a agregação. O fato de um pacote ser composto de 
modelos de elementos cria uma espécie de agregação de composição, pois, se esse pacote for destruído, 
todo o seu conteúdo também será. 
Considerações finais 
Estudamos os conceitos básicos para você iniciar a modelagem de um sistema orientado a objetos 
usando a UML. Observamos que a representação de requisitos funcionais deve ser feita por meio de um 
Diagrama de Casos de Uso, em conjunto com suas descrições textuais. 
Você pode observar que a modelagem estrutural do sistema é feita com a identificação e 
representação de classes e seus objetos. Devemos definir seus atributos e operações e ficar atentos para 
os relacionamentos entre as classes, que podem ser associações simples, agregações e hierarquias. Vimos 
também que todos os elementos aprendidos podem ser agrupados em pacotes; além disso, podemos usar 
Diagramas de Objetos para apoiar no entendimento e análise de situações e interações específicas entre 
objetos. 
Vimos que os diagramas da UML abordados neste tema podem ser usados na modelagem do 
domínio da aplicação, produzindo artefatos que serão refinados ao longo do processo de desenvolvimento 
do sistema. Na prática, nem todos esses diagramas são necessários em todos os tipos de sistema, 
destacando-se a relevância do diagrama de classes, por ser a base para a construção do banco de dados 
do sistema. 
Referências 
ASTAH. Astah UML Modeling Tool. Consultado em meio eletrônico em: 31 jan. 2021. 
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. Rio de Janeiro: Elsevier, 2015. 
Modelagem de Sistemas em UML 
Marcio Quirino - 59 
 
GÓES, W.M. Aprenda UML por meio de estudos de caso. São Paulo: Novatec, 2014. 
IEEE STANDARD GLOSSARY of Software Engineering Terminology. In: IEEE Std. 610.12-1990, 31 
dez. 1990. 
LIMA, A. S. UML 2.0: Do Requisito à Solução. São Paulo: Érica, 2005. 
MEDEIROS, E.S. Desenvolvendo software com UML 2.0: definitivo. São Paulo: Pearson Markron 
Books, 2004. 
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall, 2011. 
Explore+ 
Busque o artigo Regras do Negócio, um fator chave de sucesso no processo de desenvolvimento de 
Sistemas de Informação, dos professores Silvia Inês Dallavalle e Edson Walmir Cazarini, e aprenda sobre a 
importância das regras de negócio no desenvolvimento de sistemas. 
 
Modelagem de Sistemas em UML 
Marcio Quirino - 60 
 
Utilizando UML Para Projetar o Software 
Descrição 
Uso de diagramas de Linguagem Unificada de Modelagem (UML) na fase de projeto de sistemas de 
informação. 
Propósito 
Compreender os modelos que fazem parte da UML, empregando os diagramas de interação, de 
classes de projeto, de atividades, de estado, de componentes e de implantação, durante a fase de projeto 
desoftware. 
Preparação 
Antes de iniciar o conteúdo, é indicado que seja instalado em seu computador um programa que lhe 
permita elaborar modelos, sob a forma de diagramas da UML (Linguagem Unificada de Modelagem). Nossa 
sugestão inicial é o Astah Free Student License e será necessário usar seu e-mail institucional para ativar a 
licença. Preencha os dados do formulário no site do software, envie e aguarde a liberação de sua licença 
em seu e-mail. Ao recebê-la, siga as instruções e instale o produto em seu computador. 
Sugestões de links adicionais de programas livres para modelagem de sistemas em UML (UML 
Tools) podem ser encontradas em buscas na internet. 
Introdução 
A modelagem de um software pode, de fato, determinar a quantidade de problemas que terão que 
ser tratados durante o desenvolvimento. Softwares de sucesso, que têm sua implantação quase sem 
nenhum tipo de erro, certamente contaram com um bom processo de modelagem durante seu 
desenvolvimento. Ou seja, um bom produto de software é sempre concebido por um bom processo de 
desenvolvimento, iniciado com a modelagem do sistema. 
O processo de desenvolvimento conta com diversos métodos e técnicas para que o produto tenha a 
melhor qualidade possível, sendo a modelagem uma das técnicas utilizadas. Modelar algo é construir uma 
representação abstrata de um artefato do mundo real. 
A modelagem conta com diversas regras e diretrizes que têm que ser respeitadas para se construir 
um modelo de qualidade para o software. Todas as funcionalidades implementadas pelo software, assim 
como todos os elementos de dados que utilize e as regras que devem ser seguidas, precisam ser pensadas, 
discutidas e estruturadas antes do início de sua construção, de modo que haja um completo entendimento 
de todo esse universo, não só por parte dos usuários, mas também dos desenvolvedores. Saber identificar 
cada característica do software durante seu projeto é importante para que venha de fato atender às 
necessidades dos usuários e cumprir com todas as regras a serem executadas por ele. 
Vamos entender como construir os diagramas ao longo da etapa de projeto (ou design) de software. 
Nesta parte do desenvolvimento, alguns outros diagramas já terão sido construídos e precisam ser 
respeitadas suas regras e definições. Para isso, vamos ver as técnicas de concepção e de modelagem 
desses diagramas, assim como seus atributos e modelos. Por fim, vamos apresentar e discutir como aplicá-
los. 
 
 
Modelagem de Sistemas em UML 
Marcio Quirino - 61 
 
1. Empregar os diagramas de interação no projeto de 
sistema 
Atividades do desenvolvimento de software 
As atividades típicas de um processo de desenvolvimento de software compreendem, de modo geral, 
independentemente do processo adotado, as seguintes etapas: 
• Levantamento de requisitos 
• Análise 
• Projeto (design) 
• Implementação 
• Testes 
• Implantação 
Como se percebe, essas atividades são realizadas por etapas ou fases, em que uma etapa depende 
dos artefatos resultantes das anteriores. Neste conteúdo, o foco é a etapa de projeto (ou design) do sistema, 
na qual existe uma dependência de seus artefatos em relação aos artefatos elaborados na fase de análise 
(ou modelagem). A figura a seguir ilustra os diagramas da UML que, usualmente, são construídos nos 
modelos de análise e de projeto. Trata-se de uma visão prática, uma vez que a especificação da linguagem 
UML não determina quais diagramas devam ser usados em quais etapas e tampouco em que ordem devem 
ser elaborados. 
 
Modelos da fase de análise X modelos da fase de projeto 
Diagramas de interação 
Em um sistema computacional orientado a objetos, as funcionalidades (casos de uso) são fornecidas 
através de serviços resultantes da colaboração de grupos de objetos. Estes interagem através de 
comunicações, de forma que juntos realizem os casos de uso. 
Modelagem de Sistemas em UML 
Marcio Quirino - 62 
 
As comunicações são explicitadas através da representação da interação durante as comunicações. 
Para tal, temos na UML os diagramas de interação, usados para mostrar o comportamento interativo de um 
sistema. Os diagramas de interação descrevem o fluxo de mensagens e fornecem contexto para uma ou 
mais linhas da vida de objetos dentro de um sistema. Além disso, os diagramas de interação podem ser 
usados para representar as sequências organizadas dentro de um sistema e servir como um meio para 
visualizar dados em tempo real. 
Engenharia reversa 
Engenharia reversa, no contexto da Engenharia de Software, significa obter o modelo a partir do sistema 
implementado. 
Os diagramas de interação podem ser implementados em diversos cenários para fornecer um 
conjunto exclusivo de informações. Eles podem ser usados para modelar um sistema, como uma sequência 
de eventos organizada por tempo; fazer a engenharia reversa ou avançada de um sistema ou processo; 
organizar a estrutura de vários eventos interativos; mostrar, de forma simples, o comportamento de 
mensagens e linhas da vida dentro de um sistema e até identificar possíveis conexões entre elementos de 
linhas da vida. Seus principais objetivos são: 
• Obter informações adicionais para completar e aprimorar outros modelos (modelo de casos 
de uso e de classes). 
• Fornecer aos programadores uma visão detalhada dos objetos e das mensagens envolvidos 
na realização dos casos de uso do sistema. 
Existem dois tipos de diagrama de interação: 
 
Cada tipo de diagrama aborda uma perspectiva diferente do comportamento de um sistema. Vamos 
ver a seguir os conceitos básicos de cada diagrama, como construí-los e utilizá-los. 
Num diagrama de interação, as mensagens trocadas entre objetos, em geral, serão métodos da 
classe a que pertence o objeto receptor da mensagem, com os mesmos elementos oriundos das 
mensagens. Isso será percebido ao estudarmos os Diagramas de Classe de Projeto. 
Os diagramas de interação servem para refinar o diagrama de classes na etapa de projeto, com o 
detalhamento dos métodos. 
Isso nos mostra que os diagramas da etapa de projeto apresentados na figura anterior estão 
relacionados entre si e com os diagramas da etapa de análise, de modo que a construção de um diagrama 
depende de outros. 
Modelagem de Sistemas em UML 
Marcio Quirino - 63 
 
Diagrama de sequência 
Diagramas de sequência recebem esse nome porque descrevem, ao longo de uma linha do tempo, 
a sequência de comunicações entre objetos de um sistema de informação. Em geral, são construídos logo 
após os diagramas de caso de uso e de classes, pois têm como principais objetivos: 
 
• Documentar casos de uso. 
• Mostrar como os objetos do sistema se comunicam através de mensagens em ordem 
temporal. 
• Validar se todas as operações das classes foram identificadas e declaradas. 
• Validar a existência de um objeto necessário ao funcionamento do sistema. 
Atenção 
Não é necessário construir diagramas de sequência para todos os casos de uso do sistema. Apenas os mais 
complexos, relacionados com o negócio da aplicação, são explorados por esse tipo de diagrama. Ele pode ser bastante 
trabalhoso e criá-lo para todas as partes do sistema pode não ser produtivo e nem ter benefícios compensatórios. 
Dependendo da complexidade ou do número de objetos envolvidos ou da presença de desvios 
condicionais no caso de uso, vários diagramas de sequência serão necessários para representar as 
interações do sistema. Assim, devemos construir um diagrama de sequência principal, descrevendo as 
sequências normais entre os objetos (fluxo normal) e diagramas complementares, descrevendo sequências 
alternativas (fluxos alternativos) e tratamento de situações de erro (fluxos de exceção). 
Atenção 
Diagramas de sequência são complementares aos diagramas de caso de uso. 
Os diagramas de caso de uso são bastante completos nas descrições textuais, porém não são 
capazes de mostrar como os objetos do sistema se comunicam por intermédiode mensagens em ordem 
temporal, nem verificar se todas as operações das classes foram validadas e declaradas. Essas funções 
são muito mais bem executadas pelos diagramas de sequência. 
 
Exemplo esquemático de diagrama de sequência. 
Elementos do diagrama de sequência 
O diagrama de sequência é composto de diversos tipos de elementos. Vamos aqui apresentar cada 
um deles. 
Objetos 
São apresentados na parte superior do diagrama (um ao lado do outro) na dimensão horizontal. 
Modelagem de Sistemas em UML 
Marcio Quirino - 64 
 
Não há uma ordem específica de apresentação obrigatória. Sua ordem é relevante somente como 
forma de tornar o diagrama mais legível. Ou seja, por exemplo, uma boa prática pode ser colocar os 
elementos que têm mais interação mais próximos. Já no centro e abaixo dos objetos temos sua linha da vida 
(linha reta tracejada). Todo e qualquer objeto ou classe nesse diagrama pode ser representado com um 
retângulo com o seu nome, mas existem notações específicas para tipos especiais de objetos. São quatro 
tipos especiais, a saber: 
 
A. Ator 
É uma entidade externa que interage com o sistema enviando ou recebendo dados. Um ator é 
representado pelo estereótipo de boneco magro (“palito”), como nos diagramas de casos de uso. 
Mensagens podem ser trocadas entre atores, ou entre atores e objetos ou classes de fronteira. 
 
Exemplo de Ator. Elaborado na ferramenta Astah UML. 
B. Fronteira 
É uma classe ou um objeto responsável pela interface entre o sistema de informação e seus 
usuários, ou pela comunicação entre dois ou mais sistemas. Em geral, são programas 
(formulários, interfaces, janelas) que capturam, processam dados e exibem informações. É 
através da classe de fronteira que os atores (usuários) terão seus requisitos atendidos pelo 
sistema. 
 
Exemplo de Fronteira. Elaborado na ferramenta Astah UML. 
C. Controle 
É uma classe ou um objeto usado quando os desenvolvedores optam por separar as regras de 
negócio, as manipulações de dados e o sequenciamento de tarefas da interface de comunicação 
do sistema com o usuário, seguindo um padrão de projeto conhecido como MVC (do inglês 
Model – View – Controller). Dessa forma, a classe de fronteira (View) só existe como interface 
Modelagem de Sistemas em UML 
Marcio Quirino - 65 
 
para receber e exibir dados. Todas as outras tarefas são executadas pela classe de controle 
(Controller). 
 
Exemplo de Controle. Elaborado na ferramenta Astah UML. 
D. Entidades 
São classes ou objetos responsáveis por armazenar e gerenciar os dados do sistema, bem como 
por mostrar a estrutura lógica e estática dos dados (Model no padrão MVC). 
 
Exemplo de Entidade. Elaborado na ferramenta Astah UML. 
Linha da Vida 
Compõe a dimensão vertical (tempo) de cada objeto do diagrama. As linhas de vida representam a 
sequência na qual a vida do objeto transcorre durante a interação. Podem apresentar criação ou destruição 
de objetos. Quando são criadas interações entre os objetos, um retângulo sobre a linha é colocado 
(automaticamente pelas ferramentas de desenho de diagrama), identificando a interação. Mais de um 
retângulo pode existir em um único objeto. Esse retângulo é chamado de tempo de vida da interação. 
 
Exemplos de linhas de vida (destacados em vermelho). Elaborado na ferramenta Astah UML. 
Modelagem de Sistemas em UML 
Marcio Quirino - 66 
 
Mensagens 
São os serviços solicitados de um objeto a outro ou a ele mesmo, e as respostas a essas solicitações. 
Uma mensagem é representada por um segmento de reta, contendo uma seta em uma das suas 
extremidades. As mensagens são acompanhadas de um rótulo contendo seu nome. Pode conter também 
parâmetros da mensagem. As mensagens podem ser síncronas, assíncronas, de retorno e de criação de 
objeto. Para cada uma delas, a linguagem usa notações diferentes. Na UML, o rótulo de uma mensagem 
deve seguir a seguinte sintaxe: 
[[expressão-sequência] controle:] [v :=] nome [(argumentos)] 
Atenção 
Os colchetes [ ] indicam que o elemento é opcional. Note que o único termo obrigatório corresponde ao nome 
da mensagem. 
Muitas vezes é necessário indicar que o termo controle está associado a uma expressão lógica. 
Nesse caso, a sintaxe para o termo controle pode ser uma condição ou uma iteração: 
‘*’ ‘[’ cláusulaiteração ‘]’ 
‘[’ cláusulacondição ‘]’ 
Onde o símbolo * significa repetições da cláusula iterativa. Nessa sintaxe, os elementos entre aspas 
simples ‘ ‘ significam que fazem parte da expressão. 
 
Tipos de setas X tipos de mensagens 
 
Exemplos de Mensagens (destacadas em vermelho). Elaborado na ferramenta Astah UML 
Mensagens de iteração 
São mensagens que podem ser enviadas repetidas vezes. São precedidas de um asterisco e 
representadas dentro de colchetes. 
Modelagem de Sistemas em UML 
Marcio Quirino - 67 
 
 
Exemplo de Mensagens de iteração. Elaborado na ferramenta Astah UML 
Condições de guarda 
São mensagens que tem indicada uma condição para seu envio. 
 
Exemplo de condições de guarda. Elaborado na ferramenta Astah UML. 
Autochamada 
São mensagens que partem do objeto de origem e atingem a linha de vida dele mesmo disparando 
operações. 
Modelagem de Sistemas em UML 
Marcio Quirino - 68 
 
 
Exemplo de autochamada. Elaborado na ferramenta Astah UML. 
Ocorrência de interação 
São elementos de modelagem úteis quando se deseja simplificar um diagrama e extrair uma porção 
para outro, ou quando existe uma porção de ocorrência que se possa fazer reuso em outro diagrama. É 
representado por uma moldura com a etiqueta “ref” que se refere a outro diagrama de sequência. 
 
Exemplo de ocorrência de interação. Elaborado na ferramenta Astah UML. 
Opt 
São elementos que permitem tornar um trecho da interação opcional. 
Modelagem de Sistemas em UML 
Marcio Quirino - 69 
 
 
Exemplo de interação opcional “opt”. Elaborado na ferramenta Astah UML. 
Loop 
São elementos que permitem repetir um trecho da interação até “n” vezes. 
 
Exemplo de interação repetida “loop”. Elaborado na ferramenta Astah UML. 
Alt 
São elementos que permitem que um trecho da interação seja alternativo. 
Modelagem de Sistemas em UML 
Marcio Quirino - 70 
 
 
Exemplo de interação alternativa “alt”. Elaborado na ferramenta Astah UML. 
Diagrama de comunicação 
Diagramas de comunicação servem para mostrar como os objetos interagem para executar o 
comportamento de um caso de uso ou de parte dele, para determinar interfaces e responsabilidades de 
classes e definir os papéis dos objetos que executam determinado fluxo de eventos. Mostram a 
comunicação, ou seja, o fluxo de mensagens que ocorre entre os objetos de um sistema de informação, 
assim como o diagrama de sequência. Os dois expressam informações semelhantes, mas numa forma de 
exibição diferente. 
Então, qual diagrama usar? 
A. Diagrama de Sequência 
Se o objetivo for apresentar o fluxo de mensagens no decorrer do tempo, utilize o diagrama de 
sequência. 
B. Diagrama de comunicação 
Se a intenção for de dar ênfase a como os objetos estão vinculados e quais mensagens trocam 
entre si, use o diagrama de comunicação. 
No diagrama de comunicação, um vínculo é uma associação que identifica a ligação entre dois 
objetos envolvidos em um processo e é caracterizado pelo envio ou recebimento de uma mensagem ou de 
ambos. As mensagens enviadas de um objeto para outro são representadas por segmentos de retas com 
uma seta em uma das extremidades, indicando sua direção. 
Mensagens devem ter nome, parâmetros (opcional) e a sequência que é expressa por números, 
assim como no diagrama de sequência. 
Modelagem de Sistemas em UML 
Marcio Quirino - 71 
 
 
Exemplo esquemático de diagrama de comunicação correspondente ao diagrama de sequência, anteriormente apresentado. 
O exemplo esquemático acima ilustra a correspondência que existe entre o diagrama de sequência 
e o diagrama de comunicação. Os mesmos objetos são envolvidos, trocandoas mesmas mensagens. O 
fluxo de execução das mensagens, que no diagrama de sequência é determinado pela ordem temporal de 
cima para baixo, aqui no diagrama de comunicação é determinado pela numeração ordenada das 
mensagens. 
Como construir um diagrama de interação 
Para criação de um diagrama de interação (sequência ou comunicação), você pode seguir os 
seguintes passos (em geral): 
1. Determine o caso de uso que será modelado e identifique suas operações 
2. Para cada operação, identifique os objetos que farão parte de sua interação. 
3. Identifique as conexões e os relacionamentos entre eles e, em seguida, categorize-os. 
4. Identifique a sequência de fluxos de mensagens na interação entre os objetos. 
5. Identifique os tipos de mensagens, bem como sua sequência. 
6. Em seu software de diagramas UML, selecione as formas apropriadas para criar o diagrama. 
7. Insira um rótulo para todas as formas para representar cada evento, interação e mensagem em 
seu sistema. 
8. Dê nome ao seu diagrama usando algo que realmente o identifique. Com o volume, pode ficar 
complexa a busca pelo diagrama, caso use nomes sem muita semântica. 
Dica 
Não se recomenda incluir o ator nem o objeto de fronteira primeiramente, porque isso dificulta o entendimento. 
É mais recomendado iniciar a modelagem da interação com a representação do recebimento da mensagem para 
ativação da operação de sistema, no caso de uso. Essa recomendação ajuda a separar a lógica do domínio e a lógica 
da interface com o usuário. 
As classes conceituais identificadas, que participam em cada caso de uso, correspondem às 
entidades do mundo real envolvidas na tarefa do caso do uso, como se este fosse executado manualmente. 
Durante a modelagem de interações, objetos dessas classes participam da realização de um ou mais casos 
de uso. Por outro lado, durante a modelagem de interações, o projetista pode ter a necessidade de adicionar 
classes de software (ou seja, classes da aplicação que não têm correspondência no mundo real) que ajudem 
a organizar as tarefas a serem executadas. Essas classes de software normalmente são necessárias para 
manter a coesão e o acoplamento das demais classes em um nível adequado. 
Durante a aplicação do procedimento descrito acima, o projetista deve procurar construir diagramas 
de interação o mais inteligíveis possível. Por exemplo, é possível utilizar notas explicativas para esclarecer 
algumas partes do diagrama de interação. Essas notas podem conter texto livre ou pseudocódigo para 
orientar a programação. Outra estratégia que ajuda a construir um modelo de interações mais inteligível é 
utilizar os recursos de modularização (alt, loop, opt). 
Modelagem de Sistemas em UML 
Marcio Quirino - 72 
 
Atenção 
Sempre que for adequado, o projetista deve fazer, com base nos princípios de projeto, com que as classes de 
domínio enviem mensagens entre si. Dessa forma, o controlador envia uma mensagem para um objeto do domínio e 
este, por sua vez, dispara o envio de mensagens para outros objetos do domínio, o que evita que o controlador precise 
ter conhecimento desses últimos. 
Em que momento construir o modelo de interações 
Alguns textos sobre modelagem de sistemas orientados a objetos indicam o início da modelagem de 
interações já na atividade de análise. Outros defendem o início de sua construção somente na etapa de 
projeto. O fato é que a distinção entre essas duas fases não é tão nítida na modelagem orientada a objetos 
e a modelagem de interações pode ser realizada em ambas as fases. 
Na análise, podemos começar a construir o modelo de interações logo depois que uma primeira 
versão do modelo de casos de uso estiver pronta. Inicialmente, o modelo de interações pode ser utilizado 
para representar apenas os objetos participantes em cada caso de uso e com mensagens exibindo somente 
o nome da operação. Posteriormente (na etapa de projeto), esse modelo deve ser refinado, incluindo criação 
e destruição de objetos, detalhes sobre o tipo e assinatura completa de cada mensagem etc. 
No caso do processo incremental e interativo de desenvolvimento, onde os modelos evoluem em 
conjunto durante o desenvolvimento do sistema, embora esses modelos representem visões distintas do 
sistema, eles são interdependentes. Os itens a seguir demonstram como o modelo de interações se 
relaciona aos de casos de uso e de classes. 
Modelo de casos de uso ➔ Modelo de interações 
Utilizamos os cenários extraídos do modelo de casos de uso como fonte de identificação de 
mensagens na modelagem de interações. É adequado que se verifique se cada cenário relevante para todos 
os casos de uso foi considerado na modelagem de interações. 
Modelo de classes de análise ➔ Modelo de interações 
Utilizamos informações provenientes do modelo de classes para construir modelos de interações. 
Em particular, algumas responsabilidades já podem ter sido definidas durante a modelagem de classes de 
análise. A notação do diagrama de interações não precisa ser totalmente utilizada na fase de análise. Em 
particular, podemos definir diagramas de interação que apresentam as mensagens apenas com os seus 
nomes. Essa definição inicial deve ser refinada posteriormente com a utilização da sintaxe mais avançada. 
Modelo de interações ➔ Modelo de casos de uso 
A partir do conhecimento adquirido com a construção do modelo de interações, podemos aperfeiçoar 
e validar os cenários do modelo de casos de uso. 
Modelo de interações ➔ Modelo de classes 
É pela construção de modelos de interações que informações necessárias para a alocação e o 
detalhamento de operações (métodos) para classes surgem. Durante a construção de um diagrama de 
interação, pode ser que algumas informações necessárias em certa classe de análise ainda não existam, 
em virtude de não terem sido identificadas anteriormente. Portanto, além da identificação de operações, é 
provável que novos atributos sejam identificados durante a modelagem de interações. Outro elemento do 
modelo de classes que é comumente identificado ou validado pela construção do modelo de interações são 
as associações: uma mensagem entre objetos implica a existência de uma associação entre as classes 
envolvidas. Também é comum a situação em que identificamos novas classes durante a modelagem de 
interações, principalmente aquelas relacionadas ao domínio da solução do problema. 
Modelagem de Sistemas em UML 
Marcio Quirino - 73 
 
2. Revisar o diagrama de classes da análise no projeto de 
sistema 
Diagrama de classes de projeto 
Vamos tratar agora do diagrama de classes de projeto. Esse diagrama é um refinamento do diagrama 
de classes construído na fase de análise. Nesse refinamento, algumas classes sofrem alterações de suas 
propriedades com o objetivo de transformar o modelo de classes de análise no modelo de classes de projeto, 
assim como suas notações adicionais, transformações sobre atributos, operações e associações. 
Além disso, vamos abordar também os relacionamentos entre classes, apresentando outros 
elementos de notação e princípios de modelagem que não são usados na análise, mas que são importantes 
na construção do modelo de classes de projeto. 
Definição 
O diagrama de classes de projeto apresenta os dados que serão necessários para a construção do 
sistema de informação. Esse é o diagrama que possui o maior número de símbolos para sua diagramação. 
O seu principal objetivo é permitir a visualização dos componentes das bases de dados do sistema, 
ou seja, as classes e seus objetos, relações entre elas, suas operações, seus métodos, suas interfaces e 
seus pacotes. 
Também é papel desse diagrama atender às demandas dos casos de uso, armazenando as 
estruturas de dados projetadas para o sistema. 
Na fase de análise, o diagrama de classes pode ser usado para produzir o modelo conceitual por 
meio do qual representamos as classes e seus atributos e não levamos em consideração aspectos 
relacionados ao software. Apenasestamos interessados no domínio do problema, ou seja, na representação 
das informações necessárias ao sistema e nos conceitos e características observados no ambiente. Já na 
fase de projeto, definimos a solução do problema, ou seja, damos importância ao software por meio do qual 
as classes serão programadas, evidenciamos detalhes da implementação, como, por exemplo, os tipos de 
dados dos atributos (varchar, integer, date etc.) e suas operações e métodos. 
Especificação de atributos 
No modelo de classes de análise, os atributos são definidos somente pelo nome. No entanto, a 
sintaxe completa da UML para definição de um atributo é bem mais detalhada. Essa sintaxe, usada na fase 
de especificação do modelo de classes de projeto, é a seguinte: 
<atributo> ::= [/] [visibilidade] nome[: tipo] [= valor_inicial] 
Default 
O termo default diz respeito a um parâmetro configurado de forma automática sem intervenção do usuário, ou 
seja, um parâmetro utilizado como padrão pelo sistema. 
A visibilidade de um atributo indica seu nível de acesso. Ou seja, ela permite definir quais atributos 
de um objeto são acessíveis por outros objetos. A visibilidade de um atributo pode ser pública, protegida, 
privativa ou de pacote. A primeira é o que chamamos de default (se nenhuma visibilidade for especificada, 
essa é assumida). 
A propriedade de visibilidade serve para implementar o encapsulamento da estrutura interna da 
classe. Somente as propriedades realmente necessárias ao exterior da classe devem ser definidas com 
visibilidade pública. Todo o resto deve ser definido através das visibilidades protegida e privativa. Abaixo 
temos a lista de tipos de visibilidades, seus símbolos e significados: 
 
Modelagem de Sistemas em UML 
Marcio Quirino - 74 
 
A. Publica (+) 
Qualquer objeto externo pode obter acesso ao elemento, desde que tenha uma referência para 
a classe em que o atributo está definido. 
B. Protegida (#) 
O elemento protegido é visível para subclasses da classe em que este foi definido. 
C. Privativa (-) 
O elemento privativo é invisível externamente para a classe em que este está definido. 
D. Pacote (~) 
O elemento é visível a qualquer classe que pertence ao mesmo pacote no qual está definida a 
classe. 
O elemento nome na sintaxe do atributo corresponde ao nome do atributo. Na verdade, somente 
esse elemento é obrigatório na sintaxe de declaração de um atributo, visto que os demais são opcionais. 
O elemento tipo especifica o tipo do atributo. Esse elemento é dependente da linguagem de 
programação na qual a classe deve ser implementada. O tipo de um atributo pode ser definido pela utilização 
de um tipo primitivo da linguagem de programação a ser utilizada na implementação. 
Exemplo 
Se estamos utilizando a linguagem Java, temos, dentre outros, os seguintes tipos primitivos: int, float e boolean. 
Um valor inicial também pode ser declarado para o atributo. Dessa forma, sempre que um objeto de 
uma classe é instanciado, o valor inicial declarado é automaticamente definido para o atributo. Assim como 
o tipo, o valor inicial de um atributo também é dependente da linguagem de programação. 
Pode-se definir um atributo derivado em uma classe. Um atributo é derivado quando o seu valor pode 
ser obtido a partir do valor de outro(s) atributo(s). Por exemplo, o valor da idade de uma pessoa pode ser 
obtido a partir de sua data de nascimento. Um atributo derivado é representado com uma barra inclinada à 
esquerda (/). Atributos derivados normalmente são definidos por questões de desempenho. 
Os atributos também têm multiplicidade. Esta determina o número mínimo e máximo de valores que 
um atributo pode conter. Abaixo podemos ver as multiplicidades e seus significados, que são similares às 
multiplicidades dos relacionamentos entre classes: 
A. 0..1 
Indica que o atributo tem no mínimo zero (e opcional) e no máximo um valor. 
B. 1..1 
Indica que o atributo tem no mínimo um (e obrigatório) e no máximo um valor. 
C. 0..* 
Indica que o atributo tem no minimo zero (e opcional) e no máximo muitos valores. 
D. * 
Indica que o atributo tem muitos valores e equivale a 0..* (e opcional). 
E. 1..* 
Indica que o atributo tem no minimo um (e obrigatório) e no máximo muitos valores. 
F. 2..6 
Indica que o atributo tem no mínimo dois e no máximo seis valores. 
Modelagem de Sistemas em UML 
Marcio Quirino - 75 
 
Especificação de operações/métodos 
Na descrição do modelo de interações, declaramos que as operações de uma classe são 
identificadas em consequência da identificação de mensagens enviadas de um objeto a outro. No 
detalhamento dessas operações, devemos considerar diversos aspectos: seu nome, lista de parâmetros, 
tipo de cada parâmetro, tipo de retorno. As operações de uma classe correspondem a algum processamento 
realizado por essa classe. Em termos de implementação, uma operação é uma rotina associada a uma 
classe. A sintaxe definida na UML para uma operação é a seguinte: 
[visibilidade] nome([parâmetros]) [: tipo-retorno] [{propriedades}] 
A visibilidade segue a mesma simbologia das visibilidades para atributos. 
O elemento nome corresponde ao nome dado à operação. Se uma operação for pública, ela pode 
ser ativada com a passagem de uma mensagem para o objeto. Se for protegida, ela só é visível para a 
classe e para seus descendentes. Se for privativa, somente objetos da própria classe podem executá-la. 
Os parâmetros de uma operação correspondem às informações que ela recebe quando é executada. 
Normalmente, essas informações são fornecidas pelo objeto remetente da mensagem que pede a execução 
da operação no objeto receptor. Uma operação pode ter zero ou mais parâmetros, que são separados por 
vírgulas. Cada parâmetro da lista tem a seguinte sintaxe: 
[direção] nome-parâmetro: tipo-parâmetro 
O elemento direção serve para definir se o parâmetro pode ou não ser modificado pela operação. O 
modelador pode definir se o parâmetro é de entrada (IN), saída (OUT) ou ambos (INOUT). Se a direção for 
omitida, o valor assumido pelo parâmetro será IN, de entrada. As possíveis direções na definição de um 
parâmetro pela UML são: 
A. IN 
Parâmetro de entrada: não pode ser modificado pela operação. Serve somente como informação 
para o objeto receptor. 
B. OUT 
Parâmetro de saída: pode ser modificado pela operação para fornecer alguma informação ao 
objeto remetente. 
C. INOUT 
Parâmetro de entrada que pode ser modificado. 
O elemento nome-parâmetro corresponde ao nome do parâmetro. Cada parâmetro deve ter um nome 
único dentro da assinatura da operação. 
O elemento tipo-parâmetro corresponde ao tipo do parâmetro e é dependente da linguagem de 
programação. 
O elemento tipo-retorno representa o tipo de dados do valor retornado por uma operação. Esse tipo 
depende da linguagem de programação. 
Especificação de associações 
No modelo de classes de análise, relacionamentos entre objetos são normalmente definidos apenas 
com o uso da associação (ou como um de seus casos especiais, a generalização, a agregação ou a 
composição). As associações são os mecanismos que permitem aos objetos se comunicarem. Elas 
descrevem a conexão entre diferentes classes. Podem ter uma regra que especifica o propósito da 
associação e podem ser unidirecionais ou bidirecionais. Cada ponta da associação também possui um valor 
de multiplicidade que indica como os objetos de um lado se relacionam com os do outro lado. Existem 
diversos tipos de associação, que são modelados desde a etapa de análise: 
A. Unárias, reflexivas ou recursivas (autoassociação) 
Modelagem de Sistemas em UML 
Marcio Quirino - 76 
 
Representam relacionamentos que ocorrem entre objetos da mesma classe. 
B. Binárias 
Representam relacionamentos que ocorrem entre objetos de duas classes. 
C. Ternárias ou n-árias 
Representam relacionamentos que ocorrem entre objetos de mais de duas classes. 
D. Agregação 
Representa relacionamentos todo-parte ondea classe do lado parte pode existir 
independentemente da classe do lado todo. 
E. Composição 
Representa relacionamentos todo-parte onde a existência da classe do lado parte depende da 
existência da classe do lado todo. 
F. Generalização/ especialização 
Representa relacionamentos entre um elemento genérico e um ou mais elementos específicos, 
em que o mais específico possui todas as características do elemento genérico e contém ainda 
particularidades não encontradas no genérico. Essa característica também é chamada de 
Herança. 
G. Classe associativa 
Representa relacionamentos entre classes cuja multiplicidade é muitos para muitos e possuem 
propriedades próprias do relacionamento e não das classes associadas. 
Na etapa de projeto, uma espécie de associação relevante é a dependência, que representa 
relacionamentos entre classes, onde uma é dependente da outra. Qualquer modificação na classe 
independente afetará diretamente objetos da classe dependente. 
 
Exemplo de associação de dependência. Elaborado na ferramenta Astah UML. 
Uma dependência entre classes indica que uma classe depende dos serviços fornecidos pela outra. 
No modelo de análise, é suficiente para o modelador identificar a existência de associações entre classes, 
que é uma forma de dependência. Mas, na fase de especificação do modelo de classes, essa dependência 
precisa ser mais bem definida pelo projetista, uma vez que ela tem influência na forma utilizada para 
implementar as classes envolvidas. Vamos descrever, então, detalhes das possíveis formas de 
dependência. Para isso, considere duas classes, A e B, onde A depende de B. 
Modelagem de Sistemas em UML 
Marcio Quirino - 77 
 
Vários tipos de dependência entre essas duas classes podem existir. Esses tipos são descritos a 
seguir: 
A. Dependência por atributo 
A possui um atributo cujo tipo é B. A dependência por atributo é também chamada de 
dependência estrutural. 
B. Dependência por variável global 
A utiliza uma variável global cujo tipo é B. 
C. Dependência por variável local 
A possui alguma operação cuja implementação utiliza uma variável local de tipo B. 
D. Dependência por parâmetro 
A possui pelo menos uma operação, que possui pelo menos um parâmetro, cujo tipo é B. 
A notação da UML para representar uma dependência no diagrama de classes é de uma seta 
tracejada ligando as classes envolvidas. A seta sai da classe dependente e chega na classe da qual 
depende. Ainda com respeito à notação, as dependências podem ser estereotipadas para indicar o tipo de 
dependência existente entre duas classes. Os estereótipos da UML para rotular relacionamentos de 
dependência são: 
A. <<global>> 
Para variável global 
B. <<local>> 
Para variável local 
C. <<parameter>> 
Para parâmetro 
Transformação de associações em dependências 
No modelo de classes de análise, o modelador especifica uma ou mais associações entre uma classe 
e as demais apresentadas. Na passagem do modelo de classes de análise para o de projeto, o modelador 
deve estudar cada associação para identificar se ela pode ser transformada em dependências. A razão para 
essa transformação é definir melhor o encapsulamento. Quanto menos dependências estruturais houver no 
modelo de classes, maior será a qualidade do projeto (do ponto de vista do encapsulamento e do 
acoplamento das classes constituintes). De um modo geral, as associações que ligam classes de entidade 
permanecem como associações no modelo de projeto. 
Classes persistentes e transientes 
As classes são divididas em: 
A. Persistentes 
Presumem que seus objetos precisam, de alguma maneira, ser preservados mesmo após o 
encerramento da utilização do sistema. 
B. Não persistentes (transientes) 
Terão seus objetos destruídos durante ou na finalização do uso do sistema. Estas são 
diferenciadas por estereótipos <<transient>>. 
Classes de interface 
Uma classe de interface é uma coleção de operações com um nome e é utilizada para especificar 
um tipo de serviço sem especificar como será sua implementação. Essas classes não têm métodos 
concretos, apenas o declaram para que outra classe possa implementá-lo. Elas possibilitam que objetos 
externos ao sistema possam colaborar com uma ou mais classes do sistema. 
Modelagem de Sistemas em UML 
Marcio Quirino - 78 
 
São exemplos as interfaces gráficas, as de interações entre os usuários e as telas do sistema. Há 
um estereótipo para ela (<<interface>>) e sua implementação utiliza uma reta tracejada oriunda da classe 
de implementação, contendo a seta vazia na extremidade que aponta para a classe de interface, como ilustra 
o exemplo a seguir. 
 
Exemplo de classe de interface. Elaborado na ferramenta Astah UML. 
Navegabilidade de associações 
As associações podem ser classificadas em bidirecionais e unidirecionais. Uma associação 
bidirecional indica que há um conhecimento mútuo entre os objetos associados. Ou seja, se um diagrama 
de classes exibe uma associação entre duas classes C1 e C2, então as duas assertivas a seguir são 
verdadeiras: 
• Cada objeto de C1 conhece todos os objetos de C2 aos quais está associado. 
• Cada objeto de C2 conhece todos os objetos de C1 aos quais está associado. 
Graficamente, uma associação unidirecional é representada adicionando-se um sentido à 
associação. A classe para a qual o sentido aponta é aquela cujos objetos não possuem a visibilidade dos 
objetos da outra classe. 
Durante a construção do modelo de classes de análise, associações são normalmente consideradas 
“navegáveis” em ambos os sentidos, ou seja, as associações são bidirecionais. No modelo de classes de 
projeto, o modelador deve refinar a navegabilidade de todas as associações. 
Atenção 
Pode ser que algumas associações precisem permanecer bidirecionais. No entanto, se não houver essa 
necessidade, recomenda-se transformar a associação em unidirecional. Isso porque uma associação bidirecional é 
mais difícil de implementar e de manter do que uma associação unidirecional correspondente. 
Para entender isso, basta ver que o acoplamento entre as classes envolvidas na associação é maior quando 
a navegabilidade é bidirecional, prejudicando a modularização. Portanto, um dos objetivos a alcançar durante o projeto 
é identificar quais navegabilidades são realmente necessárias. 
A definição da navegabilidade se dá em função da troca de mensagens ocorridas nas interações 
entre objetos do sistema. Mais especificamente, devemos analisar os fluxos das mensagens entre objetos 
no diagrama de interações. Dados dois objetos associados, A e B, se há pelo menos uma mensagem de A 
para B em alguma interação, então a associação deve ser navegável de A para B. Da mesma forma, se 
existir pelo menos uma mensagem de B para A, então a associação deve ser navegável de B para A. 
Modelagem de Sistemas em UML 
Marcio Quirino - 79 
 
A definição do sentido da navegabilidade é feita em função das mensagens identificadas na 
modelagem de interação. Em particular, se um objeto do tipo A envia uma mensagem para outro do tipo B, 
então deve haver uma navegabilidade no sentido de A para B no diagrama de classes. 
Mesmo em situações em que a navegabilidade de uma associação precise ser bidirecional, é 
possível implementar apenas um de seus sentidos. 
 
Exemplo de navegabilidade. Elaborado na ferramenta Astah UML. 
3. Empregar os diagramas de estado e de atividades no 
projeto de sistema 
Transição entre estados 
Objetos de um sistema de software orientado a objetos se encontram em um estado particular a cada 
momento. Um objeto muda de estado quando acontece algum evento interno ou externo ao sistema. Quando 
um objeto muda de um estado para outro, diz-se que ele realizou uma transição entre estados. Os estados 
e as transições de estado de um objeto constituem o seu ciclo de vida. 
 
Exemplo de transição de estado. 
No momento de sua transição de um estado para outro, um objeto normalmente realiza determinadasações dentro do sistema. Cada objeto pode passar por um número finito de estados durante a sua vida. 
Quando um objeto transita de um estado para outro, significa que o sistema no qual ele está inserido também 
está mudando de estado. 
Pela análise das transições entre estados dos objetos de um sistema de software, é possível prever 
todas as possíveis operações realizadas, em função de eventos que podem ocorrer. 
O diagrama da UML utilizado para realizar essa análise é o diagrama de estados, também conhecido 
como diagrama de máquina de estado ou de transição de estado (DTE). 
Esse diagrama permite descrever o ciclo de vida de objetos de uma classe, os eventos que causam 
a transição de um estado para outro e a realização de operações resultantes. 
Modelagem de Sistemas em UML 
Marcio Quirino - 80 
 
Atenção 
Assim como diagramas de interação não são construídos para todos os casos de uso, os diagramas de 
transição de estado não devem ser construídos para todas as classes de um sistema, mas apenas para aquelas que 
possuem um número definido de estados conhecidos, e quando o comportamento das classes de objetos é afetado e 
modificado pelos diferentes estados. Nessas classes, um DTE pode ser utilizado para enfatizar os eventos que resultam 
em mudanças de estado. 
Diagrama de transição de estados 
A UML tem um conjunto rico de notações para desenhar um DTE. Os elementos básicos de um 
diagrama de transição de estados são os estados e as transições. Associados a estas últimas estão os 
conceitos de evento, ação e atividade. Um DTE pode também conter elementos menos utilizados, mas às 
vezes úteis, como transições internas, estados aninhados e estados concorrentes. A figura a seguir mostra 
um diagrama de estados para o objeto oferta de disciplina, que pode ter quatro estados: aberta, cancelada, 
lotada e fechada. 
 
Exemplo de diagrama de estados. 
Um estado é uma situação na vida de um objeto durante a qual ele satisfaz alguma condição ou 
realiza alguma atividade. Cada estado de um objeto é normalmente determinado pelos valores dos seus 
atributos e (ou) pelas suas ligações com outros objetos. 
A UML utiliza as seguintes notações para representar os estados: 
A. Estado 
O retângulo com as bordas arredondadas representa um estado. Em sua forma mais simples, o 
retângulo de um estado possui um único compartimento. 
 
B. Estado inicial 
O círculo preenchido indica o estado de um objeto quando ele é criado. Só pode haver um estado 
inicial em um DTE, restrição que serve para definir a partir de que ponto um DTE deve começar 
a ser lido. 
Modelagem de Sistemas em UML 
Marcio Quirino - 81 
 
 
C. Estado final 
Representado por um círculo parcialmente preenchido. Diferentemente do estado inicial, pode 
haver vários estados finais, dependendo dos estados terminais do objeto modelado. 
 
Transições 
Os estados estão associados a outros pelas transições. Uma transição é mostrada como uma linha 
conectando estados, com uma seta apontando do estado origem para o estado destino. Quando ocorre uma 
transição entre estados, diz-se que a transição foi disparada. Note que, em uma transição, o estado 
subsequente pode ser igual ao estado original. Uma transição pode ser rotulada com uma expressão: 
evento (lista-parâmetros) [guarda] / [ação] 
A seguir, vamos entender os elementos envolvidos nas transições entre estados: 
A. Evento 
Um evento é algo que acontece em algum ponto no tempo e que pode modificar o estado de um 
objeto, provocando a transição de estado. Um evento pode conter uma lista de parâmetros que 
são passados para fornecer informações úteis ao objeto receptor de evento. A lista de parâmetros 
é especificada entre parênteses. Na figura exemplo de diagrama de estados, realização de 
inscrição / qtdAlunos := qtdAlunos + 1 é um exemplo de evento. 
Os eventos relevantes a uma classe de objetos podem ser classificados em quatro tipos: 
1. Evento de chamada: recebimento de uma mensagem de outro objeto. Pode-se pensar 
nesse tipo de evento como uma solicitação de serviço de um objeto a outro. 
2. Evento de sinal: recebimento de um sinal. Este é um tipo especial do evento anterior. 
Nesse evento, o objeto recebe um sinal de outro objeto que pode fazê-lo mudar de estado. 
A diferença básica entre o evento de sinal e o evento de chamada é que neste último o 
objeto que envia a mensagem fica esperando a execução dela. No evento de sinal, o 
objeto remetente continua o seu processamento após ter enviado o sinal. O evento de 
sinal raramente é utilizado. 
3. Evento temporal: passagem de um intervalo de tempo predefinido. Em vez de receber 
uma mensagem específica, um objeto pode interpretar a passagem de um certo intervalo 
de tempo como sendo um evento. 
4. Evento de mudança: uma condição que se torna verdadeira. O fato de determinada 
condição se tornar verdadeira também pode ser visto como um evento. 
B. Condição de guarda 
Uma transição pode ter também uma condição de guarda. Uma condição de guarda, ou 
simplesmente guarda, é uma expressão de valor lógico, da mesma forma que a utilizada para 
diagramas de interação. A condição de guarda de uma transição pode ser definida utilizando-se 
Modelagem de Sistemas em UML 
Marcio Quirino - 82 
 
parâmetros passados no evento e atributos e referências a ligações da classe em questão. Além 
disso, uma condição também pode testar o valor de um estado. Uma transição na qual foi definida 
uma condição de guarda é disparada somente se o evento associado ocorre e a condição de 
guarda é verdadeira. Se uma transição não tiver uma condição de guarda, ela sempre será 
disparada quando o evento ocorrer. É importante não confundir a condição de guarda de uma 
transição com um evento de mudança (que também é definido com uma expressão de valor 
lógico). A expressão condicional de uma condição de guarda é sempre apresentada entre 
colchetes, como em [qtdAlunos < capacidadeMáxima] e [else], visto no exemplo de diagrama de 
estados. 
C. Ações 
Ao transitar de um estado para outro, um objeto pode realizar uma ou mais ações. Uma ação é 
uma expressão que pode ser definida em termo dos atributos, das operações ou das associações 
da classe. Os parâmetros do evento também podem ser utilizados. Uma ação pode corresponder 
igualmente à execução de uma operação. A ação é representada na linha da transição e deve 
ser precedida por uma barra inclinada para a direita (símbolo “/”). Note que a ação associada a 
uma transição é executada somente se a transição for disparada. No exemplo de diagrama de 
estados, são exemplos de ações: / qtdAlunos := qtdAlunos + 1 e / qtdAlunos := qtdAlunos – 1. 
D. Atividades 
Semelhante a uma ação, uma atividade é algo que é executado pelo objeto. No entanto, uma 
atividade pode ser interrompida (considera-se que o tempo de execução de uma ação é tão 
insignificante que ela não pode ser interrompida). Por exemplo, enquanto a atividade estiver em 
execução, pode acontecer um evento que a interrompa e cause uma mudança de estado. Outra 
diferença entre ação e atividade é que uma atividade sempre está associada a um estado (ao 
contrário, uma ação está associada a uma transição). 
E. Ponto de junção 
Em algumas situações, o próximo estado de um objeto varia de acordo com o valor da condição 
de guarda. Se o valor da condição de guarda for verdadeiro, o objeto vai para um estado E1; se 
for falso, o objeto vai para outro estado E2. É como se a transição tivesse bifurcações e cada 
transição de saída da bifurcação tivesse uma condição de guarda. Essa situação pode ser 
representada em um DTE por um ponto de junção. Um ponto de junção é desenhado como um 
losango em que chegam uma ou mais transições (provenientes de estados diferentes) e de onde 
partem uma ou mais transições. A cada transição de saída do ponto de junção está associada 
uma condição de guarda. A transição que o objeto segue é aquela para a qual a condição de 
guarda é verdadeira.Note que há um ponto de junção no exemplo de diagrama de estados. 
F. Estados aninhados 
Podem existir estados aninhados dentro de outro estado. Um estado que contém diversos outros 
é dito composto. Todos os estados dentro de um estado composto herdam qualquer transição 
deste último. Isso significa que o uso de estados compostos geralmente torna um DTE mais 
legível. 
G. Estados concorrentes 
Um estado concorrente é um tipo especial de estado composto. Um objeto em um estado 
concorrente pode, na verdade, se encontrar em dois ou mais estados independentes. 
Identificação dos elementos de um diagrama de estados 
Os estados podem ser vistos como uma abstração dos atributos e das associações de um objeto. A 
seguir temos alguns exemplos (os nomes em negrito são possíveis estados). 
• Um professor está licenciado quando não está ministrando curso algum durante o semestre. 
Modelagem de Sistemas em UML 
Marcio Quirino - 83 
 
• Uma oferta de disciplina está aberta quando a capacidade máxima não for alcançada; caso 
contrário, a oferta estará lotada. 
• Um professor está licenciado quando não está ministrando curso algum durante o semestre. 
• Um pedido está atendido quando todos os seus itens estão entregues. 
Um bom ponto de partida para identificar estados de um objeto é analisar os possíveis valores de 
seus atributos e as ligações que ele pode realizar com outros objetos. No entanto, a existência de atributos 
ou ligações não é suficiente para justificar a criação de um DTE para uma classe. O comportamento de 
objetos dessa classe deve depender de tais atributos ou ligações. Em relação a transições, devemos 
identificar os eventos que podem gerá-las. Além disso, é preciso examinar também se há algum fator que 
condicione o disparo da transição. Se existir, esse fator deve ser modelado como uma condição de guarda 
da transição. Já que as transições dependem de eventos para ocorrer, devem-se identificar esses eventos 
primeiramente. 
Outro bom ponto de partida é a descrição dos casos de uso. Os eventos encontrados na descrição 
dos casos de uso são externos ao sistema. Contudo, uma transição pode também ser disparada por um 
evento interno ao sistema. Para identificar os eventos internos relevantes a um objeto, analise os diagramas 
de interação. Esses diagramas contêm mensagens sendo trocadas entre objetos e mensagens, que nada 
mais são do que solicitações de um objeto a outro. Essas solicitações podem ser vistas como eventos. De 
uma forma geral, cada operação com visibilidade pública de uma classe pode ser vista como um evento em 
potencial. 
Dica 
Outra fonte para identificação de eventos relevantes é analisar as regras de negócio definidas para o sistema. 
Normalmente, essas regras possuem informações sobre condições limites que permitem identificar estados e 
transições. 
Construção de diagramas de transições de estados 
Para sistemas bastante simples, a definição dos estados de todos os objetos não é tão trabalhosa. 
No entanto, a quantidade de estados possíveis de todos os objetos de um sistema complexo é grande. Isso 
torna a construção de um DTE para o sistema inteiro uma tarefa bastante complexa. 
Para resolver o problema da explosão exponencial de estados, os diagramas de estados são 
desenhados por classe. 
Geralmente, cada classe é simples o suficiente para que o diagrama de estados correspondente seja 
compreensível. Note, contudo, que essa solução de dividir a modelagem de estados por classes do sistema 
tem a desvantagem de dificultar a visualização do estado do sistema como um todo. Essa desvantagem é 
parcialmente compensada pela construção de diagramas de interação. 
Nem todas as classes de um sistema precisam de um DTE. Um diagrama de estados é desenhado 
somente para classes que exibem um comportamento dinâmico relevante. A relevância do comportamento 
de uma classe depende muito de cada situação em particular. No entanto, objetos cujo histórico precisa ser 
rastreado pelo sistema são típicos para se construir um diagrama de estados. Uma vez selecionadas as 
classes para cada uma das quais se deve construir um diagrama de estados, acompanhe essa sequência 
de passos: 
1. Identifique os estados relevantes para a classe. 
2. Identifique os eventos relevantes aos objetos de uma classe. Para cada evento, identifique 
qual transição que ele ocasiona. 
3. Para cada estado, identifique as transições possíveis quando um evento relevante ocorre. 
4. Para cada estado, identifique os eventos internos e as ações correspondentes relevantes. 
5. Para cada transição, verifique se há fatores que influenciam o seu disparo. Se esse for o caso, 
uma condição de guarda deve ser definida. 
Modelagem de Sistemas em UML 
Marcio Quirino - 84 
 
6. Verifique também se alguma ação deve ser executada quando uma transição é disparada 
(ações). 
7. Para cada condição de guarda e para cada ação, identifique os atributos e as ligações que 
estão envolvidos. Pode ser que esses atributos ou ligações ainda não existam. Nesse caso, 
eles devem ser adicionados ao modelo de classes. 
8. Defina o estado inicial e os eventuais estados finais. 
9. Desenhe o diagrama de estados. Procure posicionar os estados de tal forma que o ciclo de 
vida do objeto possa ser visualizado de cima para baixo e da esquerda para a direita. 
Atenção 
A construção de diagramas de estados de um sistema frequentemente leva à descoberta de novos atributos 
para uma classe, principalmente atributos que servem de abstrações para estados. Além disso, esse processo de 
construção permite identificar novas operações na classe, pois os objetos precisam reagir aos eventos que eles 
recebem, e essas reações são realizadas mediante operações. 
Diagrama de atividades 
Um diagrama de atividade pode ser considerado um tipo especial de diagrama de estados, em que 
são representados os estados de uma atividade em vez dos estados de um objeto. Ao contrário dos 
diagramas de estados, que são orientados a eventos, diagramas de atividade são orientados a fluxos de 
controle. 
Muitos autores dizem que o diagrama de atividades é um fluxograma. Na verdade, o diagrama de 
atividade pode ser visto como uma extensão dos fluxogramas. Além de possuir toda a semântica existente 
em um fluxograma (com notação ligeiramente diferente), o diagrama de atividade possui notação para 
representar ações concorrentes (paralelas), juntamente com a sua sincronização. 
 
Exemplo de diagrama de atividades. Elaborado na ferramenta Astah UML. 
Os elementos de um diagrama de atividade podem ser divididos em dois grupos: 
• Elementos utilizados para representar fluxos de controle sequenciais. 
• Elementos utilizados para representar fluxos de controle paralelos. 
Modelagem de Sistemas em UML 
Marcio Quirino - 85 
 
Veremos mais detalhes de cada tipo a seguir. 
Fluxo de controle sequencial 
Os elementos de um diagrama de atividade usados no controle sequencial são: 
A. Estado ação e Estado atividade 
Um diagrama de atividades exibe os passos de uma computação. Cada estado corresponde a 
um dos passos da computação, em que o sistema está realizando algo. Um estado em um 
diagrama de atividade pode ser um estado atividade ou um estado ação. O primeiro leva um certo 
tempo para ser finalizado. Já o segundo é realizado instantaneamente. 
B. Estados inicial e final e condição de guarda 
Assim como no diagrama de estados, um diagrama de atividade deve ter um estado inicial; ele 
pode ter também vários estados finais e guardas associados a transições. Um diagrama de 
atividade pode não ter estado final, o que significa que o processo ou procedimento sendo 
modelado é cíclico. 
C. Transição de término 
Uma transição de término liga um estado a outro. Essa transição significa o término de um passo 
e o consequente início do outro. Observe que, em vez de ser disparada pela ocorrência de um 
evento (como nos diagramas de estados), essa transição é disparada pelo término de umestado 
de ação. Pode haver uma transição rotulada com a condição de guarda especial [else], o que 
significa que, se todas as demais condições de guarda foram avaliadas como falsas, a transição 
associada a essa guarda especial é disparada. 
D. Pontos de ramificação 
Um ponto de ramificação possui uma única transição de entrada e várias de saída. Para cada 
transição de saída, há uma condição de guarda associada. Quando o fluxo de controle chega a 
um ponto de ramificação, uma e somente uma das condições de guarda deve ser verdadeira. 
E. Ponto de união 
Um ponto de união reúne diversas transições que, direta ou indiretamente, têm um ponto de 
ramificação em comum. 
Fluxo de controle paralelo 
Um diagrama de atividade pode conter fluxos de controle paralelos. Isso significa que é possível 
haver dois ou mais fluxos de controle sendo executados simultaneamente em um diagrama de atividades. 
Para sincronizar dois ou mais fluxos paralelos, as barras de sincronização são utilizadas. Há dois tipos de 
barra de sincronização: 
A. Barra de bifurcação (fork) 
Uma barra de bifurcação recebe uma transição de entrada e cria dois ou mais fluxos de controle 
paralelos. A partir desse momento, cada um dos fluxos criados é executado independentemente 
e em paralelo com os demais. 
 
 
Modelagem de Sistemas em UML 
Marcio Quirino - 86 
 
B. Barra de junção (join) 
Uma barra de junção recebe duas ou mais transições de entrada e une os fluxos de controle em 
um único fluxo. Essa barra tem o objetivo de sincronizar fluxos de controle paralelos criados 
anteriormente no diagrama. As transições de saída da barra de junção somente são disparadas 
quando todas as transições de entrada tiverem sido disparadas. 
 
Raias 
Algumas vezes, as atividades de um processo podem ser distribuídas por vários agentes que o 
executarão. Isso normalmente ocorre em processos de negócio de uma organização, onde as tarefas são 
executadas por pessoas ou departamentos diversos. Nesses casos, o processo pode ser representado em 
um diagrama de atividades com o uso de raias de natação. As raias de natação dividem o diagrama de 
atividades em compartimentos. Cada compartimento contém atividades que são realizadas por um agente 
específico. Além disso, as entidades de cada compartimento podem estar realizando atividades em paralelo. 
 
Exemplo de diagrama de atividades com raias e fork. Elaborado na ferramenta Astah UML. 
Modelagem da lógica de uma operação complexa 
Quando um sistema de software é adequadamente decomposto em seus objetos constituintes e as 
responsabilidades de cada objeto estão bem definidas, a maioria das operações é bastante simples. Essas 
operações não necessitam de modelagem gráfica para serem entendidas. No entanto, em alguns casos, 
notadamente quando uma operação de uma classe de controle implementa uma regra de negócio, pode 
haver a necessidade de se descrever a lógica dessa operação ou da própria regra de negócio. Diagramas 
de atividade também podem ser utilizados com esse objetivo, nisso se assemelhando a um fluxograma. 
 
Modelagem de Sistemas em UML 
Marcio Quirino - 87 
 
4. Empregar os diagramas de componentes e de implantação 
Diagrama de componentes 
O diagrama de componentes apresenta o relacionamento entre os diferentes componentes de um 
sistema de software. Na UML, o termo "componente" refere-se a um módulo que representa sistemas ou 
subsistemas com capacidade de interagir. Para isso, existe uma abordagem de desenvolvimento em torno 
de componentes. 
Nesse diagrama, são representados os diferentes componentes de software necessários para que o 
sistema funcione corretamente. 
Em uma abordagem de programação orientada a objetos, o desenvolvedor usa o diagrama de 
componentes para agrupar classes com base em um objetivo comum. Assim, é função do diagrama de 
componentes documentar como os componentes estão estruturados, organizados e como se relacionam, 
permitindo uma melhor compreensão e facilitando a sua reutilização. Também serve para modelar arquivos 
de processos de negócio, descrevendo as partes que participam dele e suas relações. 
Um diagrama de componentes suporta tanto a especificação dos componentes lógicos, como, por 
exemplo, componentes de negócio, de processo, entre outros. Os principais benefícios na construção desse 
diagrama são: 
• Permitir visualizar a estrutura lógica e física do sistema. 
• Identificar os componentes do sistema e como eles se relacionam. 
• Perceber o comportamento do serviço quanto à interface. 
Componente 
Um componente nada mais é do que uma caixa preta (artefato do sistema) que possui vida autônoma 
e que, somente por meio de suas interfaces, oferece ou requer serviços de outras caixas pretas, sem que 
para isso tenha que conhecer seus conteúdos. Um componente é modelado ao longo do ciclo de vida de 
desenvolvimento, incluindo a concepção da funcionalidade do sistema por meio de casos de uso, definição 
das classes, entre outros. 
Na UML, os componentes também fazem uso de estereótipos. Os mais utilizados são arquivos, 
tabela, banco de dados, executável e biblioteca. Assim sendo, podemos dizer que um componente é 
qualquer arquivo que seja necessário à execução do sistema de informação. 
Os componentes são elementos de alto nível que permitem o agrupamento de várias interfaces sem 
considerá-las um pacote. Cada componente é representado por um retângulo contendo um nome que deve 
traduzir sua função. Se necessário, pode conter um estereótipo. No canto superior do retângulo, há um ícone 
que é também um retângulo com dois menores sobrepostos. 
 
Representação de um componente 
Os componentes também podem ser descritos por meio da visão externa usando símbolos de 
interface colados na caixa do componente. Nesse caso, é interessante anexar uma máquina de estados 
para interfaces, portas e para o próprio componente para permitir uma descrição mais precisa. 
Modelagem de Sistemas em UML 
Marcio Quirino - 88 
 
 
Exemplo de diagrama de componentes. Elaborado na ferramenta Astah UML. 
Quando mais detalhes são necessários para a perfeita especificação de um componente, podemos 
definir uma estrutura interna de partes e conectores, usando o que podemos chamar de visão interna ou 
“caixa branca”. Nessa estrutura, geralmente estão contidos outros componentes. Esses componentes 
podem ser implementados por diferentes tipos de arquivo. No diagrama de componentes, esses tipos podem 
ser destacados por meio de estereótipos, representados por rótulos acima do nome do componente. Nas 
diretrizes da UML definidas pela OMG, um artefato é dito como sendo definido pelo usuário e representa um 
elemento concreto do mundo físico. Ele pode ter propriedades ou operações e pode ser instanciado ou 
associado com outros artefatos. 
Interfaces 
Interfaces são coleções de operações que especificam serviços de um componente. É por meio delas 
que os componentes se comunicam com o mundo externo, seja para oferecer ou receber serviços. Interfaces 
descrevem o comportamento visível externamente e não especificam qualquer estrutura (não podem incluir 
atributos), nem qualquer implementação. 
As interfaces fazem as associações entre os componentes do software. 
As interfaces podem ser chamadas quando requerem ou esperam serviços. Podem ser 
opcionalmente por meio de portas onde é possível haver informações adicionais, tais como requisito de 
desempenho ou políticas que determinem que a interface seja realizada de maneira adequada. 
Conectores 
São utilizados nos diagramas de componentes para incluir interfaces baseadas em restrições e 
notações. Existem dois tipos principais de conectores: 
A. Conector Assembly 
Conecta dois componentes para definir que um deles fornece os serviços que o outro requer. 
 
Modelagem de Sistemas em UML 
Marcio Quirino - 89 
 
B. Conector Delegate 
Indica que um sinal que chega para um componente será transferido para o outro para tratamentoou manipulação. Isso significa que quando colocamos um conector de delegação, estamos 
dizendo que naquela instância do componente o trabalho não será realizado, mas sim por outro 
componente. Esse tipo de conector é bastante usado para modelar decomposição hierárquica 
em serviços. 
Camadas 
A arquitetura de sistemas em camadas permite isolar a camada de apresentação das de regras de 
negócio e de armazenamento de dados. Isso permite aumentar o desempenho do sistema, além de facilitar 
a manutenção, atualização e substituição de componentes. Isso é muito interessante nos sistemas atuais 
que se caracterizam muitas vezes por atender grande número de usuários e áreas de negócio. 
Um exemplo clássico de arquitetura em camadas é o padrão de projeto MVC (Model – View – 
Controller), em que os componentes da aplicação consistem na interface (View) que invoca o controlador 
(Controller), o qual, por sua vez, acessa o banco de dados (Model). 
Essa separação das camadas de software permite a modularização e o reuso dos componentes do 
sistema. Um exemplo é ilustrado na figura a seguir, em uma aplicação hipotética (note que diversas outras 
formas de componentização poderiam ser adotadas, a critério do projetista). 
 
Exemplo de diagrama de componentes usando MVC. Elaborado na ferramenta Astah UML. 
Diagrama de implantação 
O diagrama de implantação especifica um conjunto de artefatos de infraestrutura que podem ser 
utilizados para definir a arquitetura física de execução de sistemas de informação. Ele foca a organização 
da arquitetura sobre a qual o software irá ser implantado e executado em termos de hardware, software 
básico e redes de comunicação, ou seja, quais máquinas (computadores, servidores, switches etc.), quais 
Modelagem de Sistemas em UML 
Marcio Quirino - 90 
 
programas de software básico (sistema operacional, sistema gerenciador de banco de dados, browser) serão 
necessários para suportar o sistema, bem como definir como essas máquinas serão conectadas, com qual 
velocidade de conexão e quais protocolos de comunicação são utilizados. 
O diagrama de implantação descreve a implementação física de informações geradas pelo programa 
de software em componentes de hardware. Na UML, um diagrama de implantação representa a estrutura 
física do sistema em si, o que, assim como o diagrama de componentes, pode ser feito de várias formas. 
 
Caixas tridimensionais representam os elementos básicos de software básico ou hardware, ou nós 
no sistema. 
 
As linhas de nós a nós indicam relacionamentos. 
 
As formas menores contidas dentro das caixas tridimensionais representam os artefatos de software 
contidos nos nós. 
Nós do diagrama de implantação 
São definidos de maneira aninhada e representam dispositivos de hardware e ambientes de 
execução de software. São os elementos mais básicos do diagrama de implantação; podem representar 
computadores pessoais e/ou servidores de bancos de dados, de aplicação ou de internet, sistemas 
operacionais, browser, sistemas gerenciadores de bancos de dados etc. Eles podem ser compostos de 
outros nós, sendo comum encontrar um nó que representa um item de hardware contendo outros nós que 
representam ambientes de execução. 
O nó representa um elemento físico capaz de oferecer recursos computacionais e, geralmente, 
possui pelo menos memória e processador. Também serve para representar topologias de rede por meio 
de ligações entre instâncias de nós. Podem ser conectados para representar uma topologia de redes usando 
caminhos de comunicação que podem ser definidos como servidor de aplicação, servidor web, entre outros. 
Atenção 
A elaboração do diagrama de implantação depende do porte do sistema a ser desenvolvido. Por exemplo, não 
faz muito sentido para um sistema que será executado dentro de um único computador. Em outros casos, porém, ele 
pode ser muito útil, principalmente para ser utilizado como meio de comunicação entre a equipe de desenvolvimento e 
de infraestrutura, pois servirá de base para a equipe de infraestrutura instalar e configurar servidores, gerenciadores 
de bancos de dados, entre outros. 
A figura a seguir ilustra um diagrama de implantação. 
Modelagem de Sistemas em UML 
Marcio Quirino - 91 
 
 
Exemplo de diagrama de implantação. Elaborado na ferramenta Astah UML. 
Podem ser usados estereótipos que são, como em outros diagramas da UML, uma maneira gráfica 
ou textual de diferenciar componentes dos diagramas (classes, casos de uso, associações etc.). Podem ser 
representados por meio de textos escritos entre dois sinais de maior e menor quando não modificam o 
modelo original do componente (<<>>) e, também, por meio de um novo componente visual, porém 
padronizado pela UML, como os nós que podem conter os seguintes estereótipos: <<device>>, 
<<artifact>>, <<execution environment>>. 
A. Device 
Representa um dispositivo computacional com capacidade de processamento em que artefatos 
podem ser implantados para execução. Os dispositivos podem ser complexos, isto é, podem ser 
constituídos por outros dispositivos. Para representar um device, utilizamos o estereótipo 
<<device>>. 
B. Artefatos 
Representam objetos concretos do mundo físico, usados e/ou resultantes de um processo de 
desenvolvimento. São exemplos de artefatos: programas fontes e executáveis, uma tabela de 
bancos de dados, scripts, um documento do sistema, uma mensagem de correio eletrônico etc. 
Para representar um artefato, é utilizado o estereótipo <<artifact>>. Artefatos são sempre 
implantados em nós. 
C. Ambiente de execução 
Representam uma subclasse de um nó. São exemplos de ambiente de execução: sistemas 
operacionais, sistemas gerenciadores de bancos de dados etc. Para representar um ambiente de 
execução utilizamos o estereótipo <<execution environment>>. 
D. Associação 
Os nós são conectados por meio de caminhos de comunicação para criar sistemas em rede, ou 
seja, possuem ligações entre si de forma que possam se comunicar e trocar informações. Essas 
ligações são chamadas de associações e são representadas por segmentos de reta ligando um 
Modelagem de Sistemas em UML 
Marcio Quirino - 92 
 
nó a outro. Uma associação pode conter estereótipos utilizados para determinar, por exemplo, o 
tipo de protocolo de comunicação usado entre os nós. 
Considerações finais 
Neste conteúdo, aprendemos a desenvolver diagramas usualmente empregados na fase de projeto 
de software. No primeiro módulo, vimos os diagramas de interação (sequência e comunicação). No diagrama 
de sequência, tivemos uma visão geral e sua relação com diagrama de classes e especificações de casos 
de uso. Também entendemos quais são os elementos que formam esse diagrama (básicos, decisões, 
repetições, criação e destruição de objetos). Falamos sobre as mensagens síncronas e assíncronas. Sobre 
o diagrama de comunicação, aprendemos sobre que elementos compõem esse diagrama e como ele pode 
ser utilizado em conjunto com o diagrama de sequência. 
No módulo seguinte, tratamos do diagrama de classes de projeto. Esse é um dos diagramas mais 
importantes da fase de modelagem do software, desde a fase de análise, passando pelo projeto até a 
implementação. Tratamos das responsabilidades das classes, do papel dos relacionamentos, do 
detalhamento de métodos e dos atributos. Aprendemos sobre navegabilidade, classes de interface, de 
controle e pacotes. 
Em seguida, falamos sobre diagrama de atividades e diagrama de estados. Em ambos, tratamos dos 
conceitos básicos e de suas respectivas finalidades. Cuidamos também de falar sobre seus elementos e o 
passo a passo para sua construção. Por fim, aprendemos também outros dois diagramas mais físicos, mas 
não menos importantes, que são o diagrama de componentes e o de implantação. Em ambos, vimos 
finalidades e conceitos. 
Referências 
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. Rio de Janeiro, Brasil: Campus, 
2015. 
OMG. Unified ModelingLanguage - Versão 2.5. OBJECT MANAGEMENT GROUP, 2015. 
Explore+ 
Para aprofundar mais seu conhecimento sobre o conteúdo apresentado: 
VEJA 
O canal do YOUTUBE Estudo na Web, que tem como principal objetivo desmistificar e tornar mais 
fácil o aprendizado com exemplos simples e exercícios práticos, diversos materiais sobre UML, inclusive 
alguns específicos sobre os diagramas apresentados aqui. 
LEIA 
O artigo Os principais diagramas da UML – Resumo rápido apresentado pela revista Profissionais TI, 
da organização de mesmo nome, que traz um conjunto de diversas ferramentas que podem ser utilizadas 
para modelagem dos diagramas apresentados neste conteúdo. 
 
Modelagem de Sistemas em UML 
Marcio Quirino - 93 
 
Estudo de Caso de Modelagem de Sistemas em UML 
Descrição 
A modelagem de um projeto de software de acordo com o paradigma orientado a objetos, usando a 
linguagem UML (Unified Modeling Language). 
Propósito 
Aplicar os conceitos relacionados com a modelagem de um projeto de software, empregando os 
modelos da UML em um estudo de caso, é importante para a formação do profissional de Computação. 
Preparação 
Antes de iniciar o conteúdo deste tema, instale em seu computador um programa que lhe permita 
elaborar modelos, sob a forma de diagramas da UML (Linguagem Unificada de Modelagem). Nossa 
sugestão inicial é o Astah Free Student License, e será necessário usar seu e-mail institucional para ativar 
a licença. Preencha os dados do formulário, envie e aguarde a liberação de sua licença em seu e-mail 
institucional. Ao receber a licença, siga as instruções do e-mail e instale o produto em seu computador. Após 
a instalação, utilize o Astah para acessar os arquivos utilizados neste tema: estudoCasoPousada_analise e 
estudoCasoPousada_projeto. 
Sugestões de links adicionais de programas livres para modelagem de sistemas em UML (UML tools) 
podem ser encontradas em buscas na Internet. 
Introdução 
O presente tema trata do desenvolvimento de um estudo de caso que inclui as principais atividades 
de modelagem exigidas durante um processo de desenvolvimento de software. 
Na etapa de levantamento de requisitos, são identificados os serviços a serem fornecidos pelo 
sistema, bem como as restrições operacionais, ou seja, os requisitos funcionais e não funcionais, 
respectivamente. 
A etapa de análise inclui a geração do modelo de casos de uso a partir dos requisitos funcionais, 
sendo esse modelo composto de diagramas de casos de uso, artefatos gráficos, complementados por 
descrições de casos de uso, artefatos textuais. Ainda na etapa de análise, são gerados: o modelo de classes, 
composto de diagramas de classes, que representam as estruturas estáticas dos objetos; o modelo de 
atividades, composto de diagramas de atividades, que descrevem os aspectos dinâmicos do sistema 
exibindo passos de uma computação, sendo esses orientados a fluxos de controle; e o modelo de estados, 
composto de diagramas de estados, que também descrevem os aspectos dinâmicos do sistema, modelando 
o comportamento de objetos de uma classe na forma de uma máquina de estados, sendo esses orientados 
a eventos. 
Na etapa de projeto, podemos destacar: a geração do modelo de interação, que inclui os diagramas 
de sequência e/ou diagramas de comunicação, usados para modelar a interação entre os objetos das 
diversas classes identificadas nas fases de análise e projeto; o refinamento do modelo de classes, com os 
aspectos estáticos e estruturais do sistema, ou seja, os diagramas de classes de análise; a montagem do 
modelo de implementação, composto de diagramas de componentes; e a elaboração do modelo de 
implantação, composto de diagramas de implantação. 
 
Modelagem de Sistemas em UML 
Marcio Quirino - 94 
 
1. Produzir o documento de requisitos para um estudo de 
caso de modelagem de sistemas 
As atividades típicas que compõem o processo de desenvolvimento de software estão ilustradas a 
seguir, que mostra as atividades mais comuns dos processos de desenvolvimento de software, ou seja, 
qualquer processo deverá possuir as referidas atividades. 
 
Atividades típicas de um processo de desenvolvimento de software. 
UML (Unified Modeling Language) 
Considerando que o padrão atual da indústria de software é o paradigma orientado a objetos, a UML, 
ou seja, Linguagem de Modelagem Unificada, permite a geração de diversos documentos, de acordo com o 
referido paradigma, durante o processo de desenvolvimento de software, sendo esses documentos 
denominados artefatos de software, que podem ser textuais ou gráficos. 
Os artefatos gráficos produzidos em um sistema orientado a objetos são definidos através dos 
diagramas da UML. Como mostra a imagem a seguir, os diagramas da UML são classificados em diagramas 
de estruturas e de comportamentos, também conhecidos como diagramas estáticos e dinâmicos, 
respectivamente. 
 
Diagramas da UML. 
Segue, no quadro abaixo, breve descrição dos diagramas: 
Diagrama Especificação 
Diagrama de perfil 
Permite a definição de tipos padronizados, como estereótipos, restrições e valores rotulados. O 
foco é a adequação aos modelos UML para diferentes plataformas, por exemplo. 
Diagrama de classes 
Descreve para cada classe suas propriedades (atributos e métodos) e seus relacionamentos com 
as demais classes. Classe é a base estrutural dos sistemas orientados a objetos. 
Diagrama de estruturas compostas 
Possibilita a descrição de colaborações internas de classes, interfaces ou componentes visando a 
especificação de uma funcionalidade. 
Diagrama de componentes Apresenta a estrutura e conexões entre os componentes de um sistema. 
Modelagem de Sistemas em UML 
Marcio Quirino - 95 
 
Diagrama Especificação 
Diagrama de implantação 
Especifica o ambiente computacional sobre o qual o sistema vai operar, além de distribuir os 
artefatos (pacotes, classes e componentes) nos nós (elementos computacionais). 
Diagrama de objetos É um diagrama de classes instanciado, ou seja, mostra exemplos de instâncias. 
Diagrama de pacotes 
Descreve estruturas hierárquicas que englobam outros elementos, como outros pacotes, casos de 
uso, classes. Usado para modularizar logicamente um sistema em suas partes relevantes 
(subsistemas). 
Diagrama de atividades 
Descreve o comportamento de procedimentos, processos de negócios e fluxos de trabalho, 
suportando processamento sequencial e paralelo. 
Diagrama de casos de uso 
Mostra como os usuários (atores) interagem com o sistema, do ponto de vista externo, 
evidenciando as funcionalidades com as quais interagem. 
Diagrama de estados 
Mostra como os eventos que afetam o sistema alteram o estado dos objetos ao longo de seus 
ciclos de vida. 
Diagrama de sequência Mostra como os objetos interagem, evidenciando o tempo (a sequência das interações). 
Diagrama de comunicação Mostra como os objetos interagem, evidenciando o tempo das conexões entre eles. 
Diagrama de visão geral de 
interação 
Um mix de diagrama de sequência e de atividades. Uma especialização do diagrama de atividades 
para interações. 
Diagrama de tempo 
Diagrama de interação, com foco nas restrições de temporização, por exemplo, evidenciar as 
mudanças no estado de um objeto ao longo do tempo. 
Tabela: Alberto Tavares da Silva. 
Dica 
Nem todos os 14 diagramas serão utilizados no estudo de caso. Na verdade, alguns raramente são usados na 
prática. 
Processo de desenvolvimento de software 
Levantamento de Requisitos, Análise, Projeto, Implementação, Testes e Implantação. 
Levantamento de requisitos 
Considerando as atividades genéricas que compõem o processo de desenvolvimento de software, a 
atividade de levantamento de requisitos, também denominada elicitação de requisitos, corresponde à etapa 
de compreensão do problema por parte do engenheiro de software ou equipe. 
O principal objetivo do levantamento de requisitos é que usuários e equipe de desenvolvimento 
tenham a mesma visão do problema a ser resolvido.Nessa etapa, os desenvolvedores, juntamente com os clientes, tentam levantar e definir as 
necessidades dos futuros usuários do sistema a ser desenvolvido, sendo essas necessidades denominadas 
requisitos. Um requisito corresponde a uma descrição de um serviço a ser fornecido pelo sistema ou uma 
restrição operacional. 
Como podemos elicitar os requisitos? 
O engenheiro de software poderá utilizar determinadas técnicas: 
• Leitura de obras de referência e livros-texto 
• Observação do ambiente do usuário 
• Realização de entrevistas com os usuários 
• Entrevistas com especialistas do domínio 
Modelagem de Sistemas em UML 
Marcio Quirino - 96 
 
• Reutilização de análises anteriores 
• Comparação com sistemas preexistentes do mesmo domínio do negócio 
Minimundo do estudo de caso 
Para fins didáticos, escolhemos um estudo de caso simples o suficiente para entendimento do 
problema, porém, necessariamente completo para ilustrar todas as atividades do processo de análise e 
projeto do sistema, empregando os diagramas da UML mais frequentemente usados na prática. 
Aplicadas as técnicas de elicitação de requisitos, a equipe de engenheiros de software definiu a 
descrição do minimundo do estudo de caso a ser desenvolvido conforme a seguir. 
Descrição do Minimundo 
A empresa fictícia Pousadas Férias no Nordeste possui uma rede de pousadas e pretende contratar 
um sistema de software para a gestão de reservas de quartos online, incluindo a precificação das diárias e 
produtos disponíveis para consumo, bem como o pagamento dessas diárias e produtos consumidos pelos 
respectivos clientes. 
Uma reserva pode ser realizada de forma online ou por meio de contato telefônico com um 
funcionário da recepção da pousada. O cadastro do cliente é obrigatório para confirmação da reserva. O 
cancelamento da reserva pode ser realizado online ou por telefone. 
Os produtos disponíveis incluem bebidas, lanches e refeições diversas, sendo os consumos 
realizados pelos clientes registrados por funcionários atendentes de bar ou de cozinha da pousada. 
Os funcionários do setor administrativo da empresa mantêm atualizados os registros necessários à 
realização de reservas, tais como funcionários, pousadas, quartos e outros, bem como a precificação de 
diárias e produtos. 
A seguir, veremos os requisitos estabelecidos pela equipe de engenheiros de software. 
Requisitos funcionais (RF) 
A tabela a seguir lista os requisitos funcionais estabelecidos pela equipe de engenheiros de software. 
RF 1 
O sistema deve permitir que os clientes realizem reservas de quartos online ou por contato telefônico com a recepção da 
pousada. 
RF 2 
O sistema deve permitir que um cliente realize uma reserva somente se estiver cadastrado, podendo o referido cadastro 
ocorrer de forma online ou por contato telefônico. 
RF 3 
Quando o cliente realiza uma reserva online, o sistema realiza a cobrança de uma diária no cartão de crédito para 
confirmação da reserva. 
RF 4 
Quando o cliente realiza uma reserva por meio telefônico, o sistema exige uma pré-reserva para confirmação da reserva. 
Nesse caso, a recepção realiza a validação (inclui o registro do valor depositado) ou cancelamento da pré-reserva. 
RF 5 O cliente pode cancelar uma reserva. 
RF 6 O sistema deve permitir a precificação das diárias dos quartos das pousadas pelo setor administrativo da empresa. 
RF 7 
O sistema deve permitir a precificação dos produtos disponíveis para consumo pelos clientes pelo setor administrativo da 
empresa. 
RF 8 
O sistema deve interagir com um sistema terceirizado (operadora de cartão crédito) para pagamentos com cartão de 
crédito. 
RF 9 
Os consumos de produtos por parte dos clientes devem ser registrados pelos atendentes de bares e cozinha das 
pousadas. 
Modelagem de Sistemas em UML 
Marcio Quirino - 97 
 
RF 10 
Os funcionários do setor administrativo da empresa mantêm atualizados os registros necessários à realização de 
reservas, ou seja, funcionários, pousadas, quartos. 
RF 11 A quitação da reserva, realizada pela recepção da pousada e somente com cartão de crédito, deve ocorrer no check-out. 
RF 12 O setor administrativo gera relatórios periódicos das ocupações dos quartos das pousadas. 
RF 13 O gerente da pousada gera relatórios periódicos de ocupação dos quartos da pousada. 
Requisitos funcionais do estudo de caso. Tabela: Alberto Tavares da Silva. 
Requisitos não funcionais (RNF) 
Os requisitos não funcionais estão associados às restrições impostas ao sistema que podem ser 
categorizados como de produto, organizacionais e externos. A tabela a seguir lista os requisitos não 
funcionais definidos pela equipe de engenheiros de software. 
RNF 1 O sistema deve utilizar tecnologia WEB. 
RNF 2 O SGBD adotado é o MySQL. 
RNF 3 A linguagem de programação para desenvolvimento adotada é Java, sendo a IDE Eclipse.. 
RNF 4 O framework para o mapeamento objeto-relacional é o Hibernate. 
RNF 5 O padrão de arquitetura adotado é o MVC (model-view-controller). 
RNF 6 O processo de desenvolvimento de software adotado é o Scrum. 
RNF 7 O prazo estimado do projeto de software é de 04 (quatro) meses. 
RNF 8 
Atributo de qualidade crítico a ser considerado na seleção de um provedor de serviço na nuvem e de internet: 
confiabilidade. 
Requisitos não funcionais do estudo de caso. Tabela: Alberto Tavares da Silva. 
Requisitos de domínio 
Os requisitos de domínio, também conhecidos por regras de negócio (RN), originam-se do domínio 
de aplicação do sistema, em vez das necessidades específicas dos usuários do sistema. 
A tabela a seguir lista as regras de negócio definidas pela equipe de engenheiros de software. 
RN 1 Uma reserva é realizada por um único cliente. 
RN 2 Uma reserva pode incluir no mínimo 01 (um) quarto e no máximo 03 (três) quartos disponíveis no momento da reserva. 
RN 3 
A pré-reserva exigida na reserva por meio telefônico impõe um depósito bancário, por parte do cliente, correspondente a 
40% do total da reserva na conta da respectiva Pousada. Nesse caso, a validade ou cancelamento da reserva é realizada 
pela recepção. O cliente tem o prazo de 24h para envio do recibo de depósito via WhatsApp ou SMS. 
RN 4 O cancelamento de uma reserva pode ser realizado até 24h antes da data de check-in estabelecida na reserva. 
RN 5 No caso de cancelamento da reserva realizada por telefone, o valor da pré-reserva é estornado ao cliente. 
RN 6 No caso de cancelamento por período menor que 24h, ou não comparecimento, será cobrada uma diária. 
RN 7 Uma reserva realizada online somente é confirmada após a autorização da operadora de cartão (sistema terceirizado). 
RN 8 Os consumos de produtos por parte dos clientes são pagos no momento do check-out, com o valor restante das diárias. 
RN 9 O check-in é realizado a partir de 15h e o check-out, até 12h. 
javascript:void(0)
Modelagem de Sistemas em UML 
Marcio Quirino - 98 
 
RN 10 O sistema deve permitir o pagamento da reserva online e no check-out somente com cartão de crédito. 
Regras de negócio do estudo de caso. Tabela: Alberto Tavares da Silva. 
Vimos neste módulo que a etapa de levantamento de requisitos, ou elicitação de requisitos, permite 
o entendimento do problema por parte da equipe de engenheiros de software. 
Na etapa de levantamento de requisitos, é gerado o documento de requisitos categorizado em 
requisitos funcionais, não funcionais e de domínio, as denominadas regras de negócio. 
A identificação dos requisitos é realizada por meio de técnicas, tais como leitura de obras de 
referência e livros-texto, observação do ambiente do usuário, realização de entrevistas com os usuários, 
entrevistas com especialistas do domínio e outras. 
O documento de requisitos inclui os requisitos funcionais que correspondem aos serviços a serem 
fornecidos pelo sistema, os requisitos não funcionais, às restrições operacionais e os requisitos de domínio, 
que se originam do domínio de aplicação do sistema. 
2. Construir o modelode casos de uso para um estudo de 
caso de modelagem de sistemas em UML 
Modelo de casos de uso 
Vejamos agora a etapa de análise do processo de desenvolvimento de software genérico. 
 
Etapa: Análise. 
Nessa etapa, os engenheiros de software realizam um estudo detalhado dos requisitos levantados 
na etapa anterior, construindo modelos para representar o sistema a ser desenvolvido. Usualmente, a 
primeira abstração é a funcional, pois permite aos engenheiros de software moldar o sistema de acordo com 
as necessidades dos usuários. 
A referida abstração funcional é representada pelo modelo de casos de uso, que direciona diversas 
das atividades posteriores do ciclo de vida do sistema de software. 
O modelo de casos de uso é composto por um ou mais diagramas de casos de uso, artefatos gráficos, 
e pelas descrições de casos de usos, artefatos textuais. Os componentes do referido diagrama incluem 
casos de uso, atores, ou seja, elementos externos que interagem com o sistema, e relacionamentos entre 
os elementos anteriores. 
Estudo de caso – Diagrama de casos de uso 
Vejamos agora a construção do diagrama de casos de uso com base nos requisitos funcionais 
listados no módulo anterior. 
A. RF 1 
Inicialmente, vamos analisar o RF 1 a seguir: 
RF 1: O sistema deve permitir que os clientes realizem reservas de quartos online ou por contato 
telefônico com a recepção da pousada. 
Podemos identificar no texto um caso de uso denominado “Registrar Reserva”, interagindo com 
dois atores: Cliente ou Recepção. A referida abstração é representada a seguir. 
Modelagem de Sistemas em UML 
Marcio Quirino - 99 
 
 
Diagrama de caso de uso RF 1 gerado pela ferramenta Astah. 
O relacionamento entre ambos os atores é denominado de generalização, ou seja, o ator 
Recepção pode realizar também o caso de uso do ator Cliente. 
B. RF 3 
Vamos analisar o RF 3 a seguir: 
RF 3: Quando o cliente realiza uma reserva online, o sistema realiza a cobrança de uma diária 
no cartão de crédito para confirmação da reserva. 
Podemos identificar uma funcionalidade denominada “Registrar Cobrança de Diária”, interagindo 
com o caso de uso “Registrar Reserva” e com o ator Operadora Cartão Crédito. A abstração 
proposta está representada na imagem a seguir. Nesse caso, fizemos uso da abstração 
denominada “extend” que representa um relacionamento entre casos de uso, ou seja, o caso de 
uso “Registrar Reserva” (estendido) pode, na forma de um desvio condicional, incluir o 
comportamento representado pelo caso de uso “Registrar Cobrança de Diária” (extensor). 
 
Diagrama de casos de uso RF 3 gerado pela ferramenta Astah. 
C. RF 11 
Vamos analisar o RF 11 a seguir: 
RF 11: A quitação da reserva, realizada pela recepção da pousada e somente com cartão de 
crédito, deve ocorrer no check-out. 
Podemos identificar uma funcionalidade denominada “Realizar Check-out” e uma segunda, 
“Quitar Reserva”. A primeira interage com o ator Recepção. A abstração proposta está 
representada a seguir. 
Modelagem de Sistemas em UML 
Marcio Quirino - 100 
 
 
Diagrama de casos de uso RF 11 gerado pela ferramenta Astah. 
Nesse caso, fizemos uso da abstração denominada “include” que representa um relacionamento 
entre casos de uso, ou seja, o caso de uso “Realizar Check-out” (inclusor) utiliza, na forma de um desvio 
incondicional, o comportamento representado pelo caso de uso “Quitar Reserva” (incluído). Por sua vez, o 
caso de uso “Quitar Reserva” interage com o ator Operadora de Cartão de Crédito. 
Diagrama de Casos de Uso aplicando todos RF 
Aplicando as devidas abstrações para todos os requisitos funcionais listados na tabela de requisitos 
funcionais vista no módulo 1, propomos o diagrama de casos de uso, ilustrado a seguir, para nosso estudo 
de caso. 
 
Diagrama de casos de uso do estudo de caso gerado pela ferramenta Astah. 
Em sistemas complexos, representar todos os casos de uso do sistema em um único diagrama de 
casos de uso talvez o torne um tanto ilegível. Uma possibilidade é realizar o agrupamento de casos de uso 
em pacotes, podendo esse agrupamento lógico ocorrer por ator, por ciclo de desenvolvimento ou por área 
específica da empresa. 
Veja a seguir uma proposta de empacotamento por atores. 
Modelagem de Sistemas em UML 
Marcio Quirino - 101 
 
 
Diagrama de pacotes de casos de uso do estudo de caso gerado pela ferramenta Astah. 
Atenção 
Importante destacar que um dos desafios iniciais do engenheiro de software é a modularização da solução do 
problema, sendo que esse empacotamento permite visualizar os principais módulos que poderão compor a referida 
modularização. 
Também vale ressaltar que não existe uma solução única para o modelo de casos de uso e tampouco 
para o empacotamento, sendo muito provável que diferentes equipes produzam modelos diferentes para o 
mesmo minimundo. 
Estudo de caso – descrições de casos de uso 
Lembramos que cada caso de uso é definido por meio de uma descrição textual das interações que 
ocorrem entre ator(es) e o sistema, não sendo a forma dessa descrição definida pela UML. 
De acordo com Bezerra (2014), existem dois tipos de casos de uso: 
A. Primários 
Representam os objetivos dos atores e modelam os processos que estão sendo automatizados. 
B. Secundários 
Não agregam valor direto aos papéis dos atores, sendo, entretanto, necessários para o 
funcionamento do sistema. 
Vejamos um exemplo a partir de um caso de uso que apresente um objetivo bem específico para os 
atores Cliente e Recepção: “Registrar Reserva”. Nesse caso, temos dois cenários: um principal, que 
considera a reserva online realizada pelo cliente, e um alternativo, que considera a reserva realizada por 
telefone e registrada por um funcionário da recepção. 
 
Modelagem de Sistemas em UML 
Marcio Quirino - 102 
 
Caso de uso: Registrar Reserva. 
Atores: Cliente ou Recepção (funcionário) 
Pré-condição: Cliente ou Recepção deve estar identificado pelo sistema. 
Fluxo Principal: 
1. O sistema busca as pousadas disponíveis. 
2. O Cliente/Recepção informa a pousada destino e as datas de check-in e check-out. 
3. O sistema busca quartos disponíveis no período informado. 
4. O sistema lista os quartos disponíveis para o período informado por tipo, incluindo a quantidade máxima de pessoas a 
serem acomodadas. 
5. O Cliente/Recepção seleciona os quartos e informa a quantidade de pessoas por quarto selecionado, sendo no mínimo 
1 quarto e no máximo 3 (de acordo com RN 2). 
6. O sistema exige os dados de login do cliente para efetivação da reserva online. 
7. O cliente informa os dados para login no sistema. 
8. O sistema valida o cliente. 
9. O sistema calcula o valor total da reserva. 
10. O sistema gera um resumo da reserva incluindo a pousada, período, quantidade de pessoas acomodadas por quarto 
selecionado e valor a pagar. 
11. O Cliente/Recepção confirma a reserva. 
12. Obter confirmação de pagamento parcial de reserva online por meio de cartão de crédito <<extend Registrar Cobrança 
de Diária>>. 
13. O sistema registra a reserva e gera o código de reserva. 
Fluxo Alternativo (6): reserva realizada por contato telefônico (recepção da pousada) 
a. O sistema exige dados de login do funcionário da recepção para efetivação da reserva por contato telefônico. 
b. O funcionário da recepção informa dados para login. 
c. O funcionário da recepção informa o CPF do cliente. 
d. O sistema valida o cliente. 
e. Prosseguir no passo 9. 
Fluxo Alternativo (10): reserva realizada por contato telefônico (recepção da pousada) 
a. O sistema gera um resumo da reserva incluindo a pousada, período, quantidade de pessoas acomodadas por quarto 
selecionado, o valor total a pagar e o valor para depósito da pré-reserva pelo cliente (de acordo com RN 3). 
b. Prosseguir passo 11. 
Fluxo Alternativo (12): reserva realizada por contato telefônico (recepção da pousada) 
a. Prosseguir no passo 13. 
Fluxo de exceção (12): cartão de crédito não validadopela operadora. 
a. Se o cliente tiver outro cartão, repetir o passo 12, senão encerrar caso de uso. 
Pós-condição: o código da reserva deve ser informado ao cliente. 
Regras de negócio: RN 2 e RN 3. 
Tabela: Alberto Tavares da Silva. 
CRUD 
CRUD (acrónimo do inglês Create, Read, Update and Delete) são as quatro operações básicas (criação, 
consulta, atualização e destruição de dados) utilizadas em bases de dados relacionais (RDBMS) fornecidas aos 
utilizadores do sistema. 
Vejamos agora uma descrição de um caso de uso considerado secundário, cuja realização inclui as 
operações de CRUD. 
Caso de uso: Manter Pousada. 
Atores: Setor administrativo (funcionário). 
Pré-condição: O funcionário do setor administrativo deve estar identificado pelo sistema. 
Modelagem de Sistemas em UML 
Marcio Quirino - 103 
 
Fluxo Principal: 
1. O setor administrativo seleciona a operação: 
o Opção Inserir. 
o Opção Consultar. 
o Opção Alterar. 
o Opção Excluir. 
Fluxo Alternativo (1.1): Inserir 
a. O sistema busca os funcionários na função de gerente. 
b. O setor administrativo informa: CNPJ, nome, nome fantasia, endereço completo, telefone, e-mail de contato e seleciona 
o gerente da pousada. 
c. O sistema valida dados da nova pousada. 
d. O setor administrativo confirma o cadastro. 
O sistema registra a pousada com status de “ativa”. 
Fluxo Alternativo (1.2): Consultar 
a. O sistema busca as pousadas cadastradas. 
b. O setor administrativo seleciona a pousada. 
O sistema busca os dados da pousada, incluindo o gerente dela. 
Fluxo Alternativo (1.3): Alterar 
a. O setor administrativo seleciona a pousada. 
b. O sistema busca os dados da pousada, incluindo o gerente da pousada. 
c. O sistema busca os funcionários na função de gerente. 
d. O setor administrativo edita: CNPJ, nome, nome fantasia, endereço completo, telefone, e-mail de contato, seleciona novo 
gerente da pousada e/ou altera o status (ativa/inativa). 
e. O setor administrativo confirma a atualização. 
O sistema atualiza registro da pousada. 
Fluxo Alternativo (1.4): Excluir 
a. O sistema busca as pousadas cadastradas. 
b. O setor administrativo seleciona a pousada. 
c. O sistema busca os dados da pousada, incluindo o gerente da pousada. 
d. O setor administrativo confirma exclusão. 
e. O setor administrativo informa seus dados de login para confirmar a exclusão, pois serão excluídos todos os dados 
associados, tais como reservas, consumos, funcionários alocados. 
O sistema realiza a exclusão da pousada. 
Tabela: Alberto Tavares da Silva. 
Vimos neste módulo a geração do modelo de casos de uso de um estudo de caso, atividade da etapa 
de análise de um processo de desenvolvimento de software genérico, a partir de um documento de requisitos 
gerado na etapa levantamento de requisitos do referido processo. 
3. Construir os modelos de análise para um estudo de caso 
de modelagem de sistemas em UML 
Modelo de classes 
Após termos gerado o modelo de casos de uso com as funcionalidades a serem disponibilizadas aos 
usuários, e ainda na etapa de análise do processo de desenvolvimento de software genérico, vamos à 
construção do modelo de classes. 
As referidas funcionalidades necessitam, internamente, que objetos colaborem mutuamente para 
produção dos resultados esperados pelos respectivos usuários; essa colaboração possui um aspecto 
Modelagem de Sistemas em UML 
Marcio Quirino - 104 
 
estrutural estático que permite compreender como o sistema está estruturado internamente para que as 
citadas funcionalidades externamente visíveis sejam produzidas. 
A abstração que permite identificar o aspecto estrutural e estático dos objetos que compõem a 
solução do problema é a modelagem de classes. 
Um modelo de classes é composto por um ou mais diagramas de classes, mostrando a existência 
das classes e os seus relacionamentos numa visão lógica e estática do sistema. 
Atenção 
O modelo de classes evolui durante o processo de desenvolvimento. Portanto, o modelo de classes na etapa 
de análise não deve representar detalhes da solução do problema, limitando-se à identificação das classes, atributos 
e associações. 
Classes se relacionam com outras classes ou mesmo com a própria classe através de associações, 
que podem ser associações simples ou específicas, como a agregação, a composição e a 
generalização/especialização. Esta última é também conhecida como herança, pelo fato de as classes 
especializadas (subclasses) herdarem as propriedades das classes genéricas (superclasses). Quando uma 
subclasse for uma especialização de diferentes superclasses, ocorre a herança múltipla, prevista na 
orientação a objetos e implementada pela UML. 
Estudo de caso – Modelo de classes 
Daremos continuidade ao nosso estudo de caso a partir dos casos de uso identificados no módulo 
anterior, aplicando a técnica de identificação de classes denominada “Análise de casos de uso”, ou seja, a 
técnica de identificação dirigida por casos de uso. Nessa técnica, o engenheiro de software busca identificar 
as classes necessárias para produzir o comportamento que está documentado na descrição de caso de uso, 
de modo que quando todos os casos de uso tiverem sido analisados, todas as classes terão sido 
identificadas, ou a maioria delas. 
Selecionemos o caso de uso “Registrar Reserva” para início da criação do nosso modelo de classes. 
Analisando a descrição textual desse caso de uso, mostrada anteriormente, podemos identificar os seguintes 
objetos: 
• Cliente 
• Funcionário (reserva realizada por telefone) 
• Reserva 
• Pousada 
• Quarto 
• Tipo de quarto 
• Preço da diária (para cálculo do valor total da reserva) 
• Pagamento (no caso de reserva online) 
O diagrama de classes de análise para o caso de uso Registrar Reserva, a seguir, propõe uma 
solução para a estrutura estática dos objetos identificados, cabendo ressaltar que a tipagem de dados no 
modelo de classes de análise não é obrigatória. 
Modelagem de Sistemas em UML 
Marcio Quirino - 105 
 
 
Diagrama de classes de análise para o caso de uso Registrar Reserva gerado pela ferramenta Astah. 
Vejamos as principais abstrações aplicadas: 
• Pessoa é uma superclasse de Cliente e Funcionário. 
• Toda reserva está associada a 1 (um) cliente, que pode fazer 1 (uma) ou mais reservas. 
• Uma reserva e registrada por no minimo 0 (zero) funcionário (reserva online) e no máximo 1 
(um) funcionário (reserva por telefone). 
• Uma reserva pode possuir no mínimo 1 (um) e no máximo 3 (três) quartos (RN 2). 
• Uma pousada possui no mínimo 1 (um) e no máximo vários quartos, sendo utilizada a 
associação de composição, ou seja, o objeto parte (Quarto) só tem existência se o objeto todo 
(Pousada) existir. 
• Um quarto se associa com várias instancias da classe PrecoDiaria, sendo o valor cobrado 
dependente da data da reserva. 
• Uma reserva pode estar associada a no mínimo 0 (zero), caso de reserva por telefone, ou no 
máximo vários pagamentos por cartão, caso de reserva online. 
• Historicamente, um funcionário pode ter gerenciado 0 (zero) ou mais pousadas e uma 
pousada pode ter sido gerenciada por 1 (um) ou mais gerentes. 
Aplicando a mesma abstração, com foco nos objetos, para os demais casos de uso, temos como 
resultado o diagrama de classes de análise proposto para o nosso estudo de caso ilustrado a seguir. 
Modelagem de Sistemas em UML 
Marcio Quirino - 106 
 
 
Diagrama de classes do estudo de caso gerado pela ferramenta Astah. 
Atenção 
Assim como no modelo de casos de uso, é importante ressaltar que não há uma solução única para o modelo 
de classes, em face das diversas possibilidades de modelagem de classes, atributos e associações resultantes do 
modelo de casos de uso. 
Destacamos a abstração aplicada à classe Consumo, sendo essa uma classe associativa resultante 
da associação entre Quarto e Produto, e que depois se associa à classe Funcionário, responsável pelo 
registro do consumo. Normalmente,uma classe associativa é necessária quando duas ou mais classes 
estão associadas, sendo necessário manter informações sobre essa associação, ou seja, toda vez que 
ocorre um consumo é registrada a data e a quantidade do produto consumido por um funcionário. Essa 
solução foi aplicada à classe associativa Gerenciamento que permite identificar a data em que um 
Modelagem de Sistemas em UML 
Marcio Quirino - 107 
 
funcionário assume a função de gerente em uma pousada, bem como a respectiva data de liberação da 
função. 
Modelo de atividades 
O modelo de atividades é composto por diagramas de atividades que, entre outros, descrevem os 
aspectos dinâmicos de um sistema, ou seja, um diagrama de atividade exibe passos de uma computação. 
Os referidos diagramas possuem as seguintes aplicações: 
Modelagem de processo de negócio 
Cujo enfoque está em entender o comportamento do sistema no decorrer de diversos casos de uso 
(processos de negócio), ou seja, como determinados casos de uso do sistema se relacionam no decorrer 
do tempo. 
Modelagem da lógica de um caso de uso 
A realização de um caso de uso requer que alguma computação seja realizada e, nessas situações, 
é interessante complementar a descrição do caso de uso com um diagrama de atividade. 
Modelagem da lógica de uma operação 
Embora muitas das operações sejam simples, pode haver a necessidade de se descrever a lógica 
de uma operação mais complexa na forma gráfica. 
Estudo de caso ‒ Modelo de atividades 
Prossigamos no nosso estudo de caso construindo o diagrama de atividades que represente 
graficamente a modelagem da descrição de caso de uso “Registrar Reserva”, estabelecida anteriormente 
de forma textual em “Estudo de caso – descrições de casos de uso”. 
Analisando a referida descrição, podemos observar que a interação ocorre entre os atores 
Cliente/Recepção (que possuem um relacionamento de generalização) e o sistema, ou seja, o diagrama de 
atividades deve conter duas raias de acordo com a imagem a seguir, de modo que algumas atividades são 
de responsabilidade dos atores e outras, do sistema. 
 
Diagrama de atividades parcial do caso de uso Registrar Reserva gerado pela ferramenta Astah. 
No diagrama de atividades parcial do caso de uso Registrar Reserva, podemos ver as primeiras 
etapas de montagem do diagrama considerando os seguintes passos computacionais: 
 
 
Modelagem de Sistemas em UML 
Marcio Quirino - 108 
 
Fluxo Principal: 
a. O sistema busca as pousadas disponíveis. 
b. O Cliente/Recepção informa a pousada destino e as datas de check-in e check-out. 
c. O sistema busca quartos disponíveis no período informado. 
d. O sistema lista os quartos disponíveis para o período informado por tipo, incluindo a quantidade máxima de pessoas a 
serem acomodadas. 
e. O Cliente/Recepção seleciona os quartos e informa a quantidade de pessoas por quarto selecionado, sendo no mínimo 1 
quarto e no máximo 3 (de acordo com RN 2 – Tabela 3). 
f. O sistema exige os dados de login do cliente para efetivação da reserva online. 
... 
Fluxo Alternativo (6): reserva realizada por contato telefônico (recepção da pousada) 
a. O sistema exige dados de login do funcionário da recepção para efetivação da reserva por contato telefônico. 
Tabela: Alberto Tavares da Silva. 
Após a definição das raias, podemos inserir o elemento que representa o início do processo (círculo 
escuro). O primeiro passo a considerar é “Busca as pousadas disponíveis” sob responsabilidade do 
Sistema, sendo a próxima atividade “Informa a pousada destino e as datas de check-in e check-out”, do 
ator Cliente/Recepção. Interessante observar que no passo 6 “O sistema exige os dados de login do 
cliente para efetivação da reserva online” temos um fluxo alternativo (losango), ou seja, caso a reserva 
seja online, a atividade a ser realizada pelo sistema é “Exige os dados de login do cliente para efetivação 
da reserva online” e, no caso de reserva por telefone, a atividade será “Exige dados de login do 
funcionário da recepção para efetivação da reserva por contato telefônico”. Aplicando a mesma 
abstração nos demais fluxos da referida descrição, teremos o diagrama de atividades do caso de uso 
“Registrar Reserva” ilustrado na imagem a seguir, onde podemos observar que o fluxo de atividades tem 
quatro possíveis encerramentos, representados pelos círculos vazados. 
Modelagem de Sistemas em UML 
Marcio Quirino - 109 
 
 
Diagrama de atividades do caso de uso Registrar Reserva gerado pela ferramenta Astah. 
Modelo de estados 
Ainda na etapa de análise do processo, vejamos o modelo de estados. 
No contexto do paradigma orientado a objetos, um determinado objeto possui um estado particular, 
mudando de estado quando acontece algum evento interno ou externo ao sistema. 
Nessa transição de um estado para outro, um objeto realiza determinadas ações dentro do sistema. 
O modelo de estados é composto por diagramas de estados que descrevem os possíveis estados 
pelos quais objetos, instâncias de uma determinada classe, podem passar e as alterações dos estados como 
resultado de eventos que atingem esses objetos. 
Modelagem de Sistemas em UML 
Marcio Quirino - 110 
 
Estudo de caso ‒ Modelo de estados 
Dando continuidade ao nosso estudo de caso, podemos identificar, no diagrama de classes do estudo 
de caso, uma classe cujos objetos possuem mudanças significativas de estados, a classe Reserva. Uma 
reserva pode assumir estados durante a execução do software, tal como no diagrama de atividades do caso 
de uso Registrar Reserva. Uma reserva pode ter dois estados iniciais: 
A. Em validação 
Quando a reserva é realizada por telefone 
B. Confirmada 
Quando a reserva é realizada de forma online 
Analisemos a mudança de estado de “Em validação” para “Confirmada”, cuja expressão para 
transição é “Cliente deposita pré-reserva [até 24h depois da reserva] / Confirmar reserva”, ou seja, temos a 
expressão “evento [condição de guarda] / ação”. O evento corresponde a “Cliente deposita pré-reserva”, a 
condição para a mudança de estado inclui “[até 24h depois da reserva]” e, finalmente, a ação correspondente 
no sistema é denominada de “Confirmar reserva”. Aplicando a mesma expressão às demais mudanças de 
estados, temos o diagrama de estados ilustrado a seguir. 
 
Diagrama de estados para a classe Reserva gerado pela ferramenta Astah. 
Vimos, neste módulo, a construção dos artefatos da fase de análise, a saber: 
Modelagem de Sistemas em UML 
Marcio Quirino - 111 
 
Modelo de classes de análise 
Corresponde à estrutura estática dos objetos que irão colaborar mutuamente para a produção dos 
resultados esperados pelos respectivos usuários, ou seja, essa colaboração possui um aspecto estrutural 
estático que permite compreender como o sistema está estruturado internamente para que as citadas 
funcionalidades externamente visíveis sejam produzidas. 
Modelo de atividades 
Composto de diagramas de atividades, permite descrever os aspectos dinâmicos de um sistema 
tendo três possíveis aplicações: modelagem de processo de negócio, modelagem da lógica de um caso de 
uso e modelagem da lógica de uma operação ou método. 
Modelo de estados 
Composto de diagramas de estados, permite também identificar aspectos dinâmicos de um sistema, 
sendo que a transição entre estados ocorre a partir de um evento externo, incluindo uma ou mais condições 
de guarda e uma correspondente ação no sistema. 
4. Produzir o modelo de projeto para um estudo de caso de 
modelagem de sistemas em UML 
Daremos continuidade ao nosso estudo de caso, que trata do gerenciamento de uma rede de 
pousadas, desenvolvendo os principais modelos da etapa de projeto do processo de desenvolvimento de 
software genérico. 
 
Etapa: Projeto. 
Modelo de interação 
O modelo de interação é composto por diagramas de sequência e/ou diagramas de comunicação, 
podendo ser iniciado na fase de análise ou na fase de projeto para representar os aspectosdinâmicos do 
sistema. Consideremos que o início da sua construção ocorre na etapa de projeto do processo, tendo como 
finalidade principal detalhar os objetos e mensagens requeridas na realização de um caso de uso. 
Embora os modelos representem visões distintas do sistema, esses modelos são interdependentes, 
estando a modelagem de interação diretamente relacionada com a modelagem de casos de uso e a 
modelagem de classes. 
Diagrama de sequência 
Este diagrama organiza os objetos participantes da interação na horizontal, sendo que cada objeto 
possui uma linha de vida e as mensagens entre esses objetos são representadas com linhas horizontais 
rotuladas partindo da linha de vida do objeto remetente e chegando à linha de vida do objeto receptor. A 
posição vertical das mensagens permite deduzir a ordem na qual elas são enviadas. 
Diagrama de comunicação 
Este diagrama organiza os objetos em forma de nós, sendo adicionados setas e rótulos de 
mensagens nas ligações entre esses objetos; a ordem das mensagens é explicitada pela sua numeração 
sequencial no diagrama de comunicação. 
Atenção 
Os diagramas de comunicação e sequência representam as mesmas interações e devem estar consistentes 
com o diagrama de classes e com a respectiva descrição de caso de uso. 
Modelagem de Sistemas em UML 
Marcio Quirino - 112 
 
Estudo de caso – Modelo de interação 
Daremos continuidade ao nosso estudo de caso, gerando o diagrama de sequência do caso de uso 
“Registrar Reserva”. Como afirmado anteriormente, esse diagrama possui uma interdependência com os 
modelos de casos de uso e modelo de classes, portanto vamos iniciar nossa abstração “dinâmica” com a 
descrição do referido caso de uso desenvolvida no tópico Estudo de caso – modelo de casos de uso, sendo 
parcialmente replicada a seguir: 
Caso de uso: Registrar Reserva. 
Atores: Cliente e Recepção (funcionário) 
Pré-condição: Cliente ou Recepção deve estar identificado pelo sistema. 
Fluxo Principal: 
1. O sistema busca as pousadas disponíveis. 
2. O Cliente/Recepção informa a pousada destino e as datas de check-in e check-out. 
3. O sistema busca quartos disponíveis no período informado. 
4. O sistema lista os quartos disponíveis para o período informado por tipo, incluindo a quantidade máxima de pessoas 
a serem acomodadas. 
5. O Cliente/Recepção seleciona os quartos e informa a quantidade de pessoas por quarto selecionado, sendo no 
mínimo 1 (um) quarto e no máximo 3 (três) (de acordo com RN 2). 
6. O sistema exige os dados de login do cliente para efetivação da reserva online. 
... 
Fluxo Alternativo (6): reserva realizada por contato telefônico (recepção da pousada) 
a. O sistema exige dados de login do funcionário da recepção para efetivação da reserva por contato telefônico. 
b. O funcionário da recepção informa dados para login. 
c. O funcionário da recepção informa o CPF do cliente. 
d. O sistema valida o cliente. 
e. Prosseguir no passo 9. 
Tabela: Alberto Tavares da Silva. 
Temos que considerar na construção do modelo de interação o requisito não funcional “RNF 5 ‒ O 
padrão de arquitetura adotado é o MVC (model-view-controller)”, pois novos objetos serão incorporados, a 
fim de permitir que o projeto do sistema tenha um nível de detalhamento suficiente para sua implementação. 
Diagrama de sequência 
Retornando à nossa descrição, analisemos o passo 1, “O sistema busca as pousadas disponíveis”, 
estando a respectiva modelagem ilustrada a seguir. Nos diagramas de interação, por convenção de boa 
prática, empregamos os sufixos Model, View e Controller na denominação dos objetos, para indicar as 
camadas respectivas na fase de implementação do modelo. 
 
Diagrama de sequência parcial do caso de uso “Registrar Reserva” gerado pela ferramenta Astah. 
A interação do ator, cliente ou funcionário da recepção definido no diagrama de casos de uso do 
estudo de caso, é iniciada pelo método CreateAction da classe controladora ReservaController que, por sua 
Modelagem de Sistemas em UML 
Marcio Quirino - 113 
 
vez, instancia um objeto PousadaModel, que é um objeto entidade identificado a partir do diagrama de 
classes de análise, a fim de que esse busque as pousadas disponíveis. 
Em seguida, analisemos os passos 2, “O Cliente/Recepção informa a pousada destino e as datas de 
check-in e check-out” e 3, “O sistema busca quartos disponíveis no período informado”, cujas modelagens 
estão representadas a seguir. 
 
Diagrama de sequência parcial do caso de uso “Registrar Reserva” passo 2 gerado pela ferramenta Astah. 
Após uma segunda interação do ator, ou seja, seleção da pousada, uma função JavaScript na 
camada View aciona um método na classe controladora a fim de buscar os quartos disponíveis para a 
selecionada pousada no período desejado, conforme observado na imagem a seguir. 
 
Diagrama de sequência parcial do caso de uso “Registrar Reserva” passo 3 gerado pela ferramenta Astah. 
Modelagem de Sistemas em UML 
Marcio Quirino - 114 
 
Finalmente, vamos analisar o passo 6, “O sistema exige os dados de login do cliente para efetivação 
da reserva online”. 
Após uma quarta interação do ator, ou seja, informação de dados do login, ocorre a possibilidade de 
dois cenários estabelecidos pelos fluxos principal e alternativo, ou seja, reserva realizada pelo cliente 
(principal) ou pelo funcionário da recepção (alternativo). O operador “alt” permite representar essa abstração, 
pois caso o ator seja o cliente, será acionado o respectivo método de validação, e caso seja o funcionário, 
ocorrerá a respectiva validação de login, bem como a validação do CPF do cliente. 
Na quinta interação, a confirmação da reserva, temos duas opções de acordo com o cenário; no 
cenário que a reserva é realizada pelo ator cliente, ocorre a extensão do caso de uso Registrar Cobrança 
de Diária, reveja o diagrama de casos de uso do estudo de caso: 
 
Extend em diagrama de casos de uso do estudo de caso gerado pela ferramenta Astah. 
Caso essa cobrança seja confirmada, ou a reserva seja realizada pelo ator funcionário da recepção 
(cenário alternativo), ocorre o registro da reserva. Após a aplicação das abstrações descritas, propomos o 
diagrama de sequência ilustrado a seguir. 
Modelagem de Sistemas em UML 
Marcio Quirino - 115 
 
 
Diagrama de sequência do caso de uso “Registrar Reserva” gerado pela ferramenta Astah. 
Diagrama de comunicação 
Agora, vejamos a elaboração do diagrama de comunicação para o mesmo caso de uso, ou seja, 
“Registrar Reserva”. Nesse caso, podemos aplicar a mesma abstração aplicada na construção do diagrama 
de sequência, ou seja, a partir da descrição de caso de uso e do diagrama de classes identificar os objetos 
que fazem parte da solução do caso de uso e as respectivas trocas de mensagens, levando em consideração 
algum requisito não funcional relacionado com o padrão de arquitetura adotado (no caso MVC). A imagem 
a seguir ilustra o diagrama de comunicação proposto. Note que a sequência da execução é ordenada pelos 
números sequenciais das mensagens e o resultado das interações é o mesmo do diagrama de sequência. 
Modelagem de Sistemas em UML 
Marcio Quirino - 116 
 
 
Diagrama de comunicação do caso de uso “Registrar Reserva” gerado pela ferramenta Astah. 
Modelo de classes de projeto 
O modelo de classes de projeto é resultante de refinamentos no modelo de classes de análise, sendo 
incluídos detalhes úteis para a implementação das respectivas classes. 
Dica 
Como boa prática, sugerimos que esse modelo seja construído em paralelo com o modelo de interações. 
Estudo de caso ‒ Modelo de classes de projeto 
Aplicando os principais refinamentos no diagrama de classe de análise para o caso de uso Registrar 
Reserva ilustrado anteriormente no módulo 3, propomos o diagrama de classes de projeto apresentado a 
seguir. A sintaxe dos atributos foi definida no modelo de análise, sendo as visibilidades privativas 
(qualificador de visibilidade“–“). 
Modelagem de Sistemas em UML 
Marcio Quirino - 117 
 
 
Diagrama de classes de projeto para o caso de uso Registrar Reserva gerado pela ferramenta Astah. 
Podemos observar que as mensagens definidas no diagrama de sequência apresentado 
anteriormente foram incorporadas como métodos na respectivas classes, tal como a mensagem “10.1 
Registrar()” implementada na classe destino “Reserva”, incluindo o tipo de visibilidade, no caso públicas 
(qualificador de visibilidade “+”), e tipo de retorno. 
Vamos exemplificar refinamentos relacionados com a navegabilidade entre classes (repare nas 
multiplicidades de cada associação): 
(a) 
Ocorrência de uma associação bidirecional entre Cliente/Reserva, pois a navegabilidade não está 
representada por flechas, ou seja, o envio de mensagens deverá ocorrer em ambos os sentidos, 
sendo que um objeto Cliente poderá instanciar uma coleção de objetos Reserva (veja atributo 
oLstReserva) e um objeto Reserva poderá instanciar um objeto Cliente (veja o atributo oCliente). 
 
(b) 
Ocorrência de uma associação unidirecional entre Reserva/Quarto, pois a navegabilidade está 
representada por uma flecha, ou seja, o envio de mensagens deverá ocorrer em um único sentido, 
sendo que um objeto Reserva poderá instanciar uma coleção de objetos Quarto (veja atributo 
oLstQuarto). 
Nosso diagrama de classes de projeto para o caso de uso Registrar Reserva permite ilustrar, 
também, o refinamento relacionado com o conceito de classe abstrata, que permite organizar hierarquias 
gen/spec e a implementação do princípio do polimorfismo. A classe Pessoa é uma classe abstrata estando 
a mesma em itálico. 
Modelagem de Sistemas em UML 
Marcio Quirino - 118 
 
Aplicando a abstração descrita para o caso de uso “Registrar Reserva” para os demais casos de uso, 
teremos o diagrama de projeto do sistema. 
Dica 
Os métodos de acesso get/set, ou as propriedades, não estão representados em função da geração automática 
pelos compiladores modernos a partir dos atributos. 
Modelo de implementação 
O modelo de implementação é composto de um ou mais diagramas de componentes, que permite 
representar, de forma gráfica, os componentes do sistema e suas dependências. 
Estudo de caso ‒ Modelo de implementação 
Retornemos ao nosso estudo de caso, ainda na fase de projeto do processo. A imagem a seguir 
ilustra uma proposta para o diagrama de componentes, considerando os modelos de casos de uso (módulo 
2), de classes (módulo 3) e de interação (módulo 4). 
 
Diagrama de componentes para o estudo de caso gerado pela ferramenta Astah. 
A partir do empacotamento de casos de uso, propomos uma solução (entre outras muitas!) onde 
cada pacote corresponde a uma aplicação. Cada aplicação possui suas próprias classes controladoras 
(pacote Controller) e views (pacote View); entretanto, as classes do tipo model (stereotype) são acessadas 
por todas as aplicações por uma interface IPadrao. Como especificado no requisito não funcional RNF 2 no 
módulo 1, o banco de dados é o MySql, sendo o framework de persistência o Hibernate (RNF 4). Lembramos 
que esse diagrama representa um alto nível de abstração, pois podemos detalhar cada aplicação com um 
respectivo diagrama de componentes. 
Modelo de implantação 
O modelo de implantação é composto de um ou mais diagramas de implantação e define os nós 
de processamento disponíveis, ou seja, os componentes físicos do sistema e suas interdependências. A 
referida modelagem cresce de importância em função da complexidade do sistema. 
Modelagem de Sistemas em UML 
Marcio Quirino - 119 
 
Estudo de caso ‒ Modelo de implantação 
A imagem a seguir ilustra uma proposta de diagrama de implantação para o nosso estudo de caso, 
sendo necessários apenas três nós computacionais para sua implantação. 
 
Diagrama de implantação para o estudo de caso gerado pela ferramenta Astah. 
Neste módulo, demos continuidade ao estudo de caso que trata do gerenciamento de uma rede de 
pousadas desenvolvendo os principais modelos da etapa de projeto do processo de desenvolvimento de 
software genérico. 
Neste módulo vimos os seguintes modelos: 
Modelo de interação 
Permite identificar os objetos e respectivas interações, por meio de mensagens, na realização de 
casos de uso, sendo esse modelo composto por diagramas de sequência e/ou diagramas de comunicação. 
Modelo de classes de projeto 
É gerado a partir do refinamento do modelo de classes de análise, ou seja, transformações aplicadas 
nos atributos, operações e associações. Esse modelo é construído em paralelo com o modelo de interações, 
contendo detalhes úteis para a implementação das classes nele contidas. 
Modelo de implementação 
Composto de diagramas de componentes, permite identificar os componentes e suas dependências. 
Modelo de implantação 
Composto por um ou mais diagramas de implantação, define os nós computacionais necessários à 
implantação do sistema. 
Considerações finais 
Apresentamos neste tema um estudo de caso que permitiu a aplicação dos conceitos relacionados 
com a modelagem de um projeto de software, incluindo as etapas de levantamento de requisitos, análise e 
projeto do processo de desenvolvimento de software genérico. 
Na etapa de levantamento de requisitos, identificamos os serviços a serem fornecidos pelo sistema, 
bem como as restrições operacionais, ou seja, os requisitos funcionais, não funcionais e as regras de 
negócio. 
Modelagem de Sistemas em UML 
Marcio Quirino - 120 
 
Na etapa de análise foram gerados, a partir dos requisitos funcionais, o modelo de casos de uso, 
composto de diagramas de casos de uso e de descrições de casos de uso, o modelo de classes, composto 
de diagramas de classes, o modelo de atividades, composto de diagramas de atividades, e o modelo de 
estados, composto de diagramas de estados. 
Na etapa de projeto, foi gerado o modelo de interação, que inclui os diagramas de sequência e/ou 
diagramas de comunicação, o modelo de classes de projeto, composto de diagramas de classes 
devidamente refinados a partir dos diagramas de classes de análise, o modelo de implementação, composto 
de diagramas de componentes, e o modelo de implantação, composto de diagramas de implantação. 
Referências 
BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. 3. ed. Rio de Janeiro: Elsevier, 
2014. 
WAZLAWICK, R. S. Análise e Projeto de Sistemas de Informação Orientados a Objetos. 2. ed. Rio 
de Janeiro: Elsevier, 2011. 
Explore+ 
Para saber mais sobre os assuntos tratados neste tema, leia: 
Capítulos 4 a 11 ‒ Princípios de Análise e Projeto de Sistemas. 
Capítulos 3, 4, 5, 7 e 9 ‒ Análise e Projeto de Sistemas de Informação Orientados a Objetos. 
 
 
Modelagem de Sistemas em UML 
Marcio Quirino - 121 
 
Introdução a Padrões de Projeto - Design Patterns 
Descrição 
Padrões de projeto de software e visão geral dos padrões GRASP, SOLID e GoF. 
Propósito 
Compreender o conceito de padrões de projeto e ser capaz de identificar oportunidades para a 
aplicação dos principais padrões em projetos de sistemas são habilidades importantes para a sua formação, 
pois elas possibilitam a criação de programas bem estruturados por meio do uso de soluções 
reconhecidamente bem-sucedidas para problemas recorrentes no desenvolvimento de software. 
Preparação 
Este conteúdo não requer nenhum pré-requisito operacional obrigatório. Porém, antes de iniciar, é 
recomendado ter instalado em seu computador um programa que lhe permita elaborar modelos sob a forma 
de diagramas da UML (Linguagem Unificada de Modelagem). Nossa sugestão inicial é o Astah Free Student 
License, usado nos exemplos deste estudo, e, para isso, será necessário lançar mão do seu e-mail 
institucional para ativar a licença. Preencha os dados do formulário no site do software, envie e aguarde a 
liberação de sua licença em seu e-mail institucional. Ao receber a licença, siga as instruções do e-mail e 
instale o produtoem seu computador. Os arquivos-fonte dos diagramas Astah UML mostrados neste 
conteúdo podem ser baixados aqui. 
Sugestões de links adicionais de programas livres para modelagem de sistemas em UML (UML 
Tools) podem ser encontradas em buscas na internet. 
Introdução 
Desenvolvedores pouco experientes frequentemente têm dificuldade em estruturar um software de 
forma que ele satisfaça os requisitos de qualidade demandados. 
Por que é importante estruturar um software adequadamente? Não basta programar as suas 
instruções de forma que ele realize corretamente as funções demandadas pelo cliente? 
Realizar as funções corretamente é apenas um dos requisitos de qualidade de um sistema. Um 
sistema bem-sucedido passa por diversos ciclos de evolução ao longo da sua existência, motivados por 
mudanças tanto no negócio como na tecnologia. Para complicar o cenário, as pessoas que participam dos 
ciclos iniciais de desenvolvimento podem ir para outros projetos ou outras empresas, e novos 
desenvolvedores precisarão dar continuidade à evolução do sistema. Portanto, não basta que ele funcione 
corretamente; deve ser estruturado de modo que sua manutenção seja possível a custos e prazos aceitáveis. 
Neste estudo, você aprenderá como os conceitos de padrões de projeto, padrões GRASP, GoF e 
princípios SOLID podem ser empregados para a produção de sistemas bem estruturados. 
1. Conceitos gerais de padrões de projeto, seus elementos e 
suas características 
Design patterns 
Design patterns ou padrões de projeto são soluções gerais para problemas recorrentes durante o 
desenvolvimento de um software. 
Você já ouviu falar em padrões de projeto (design patterns)? Sabe por que eles foram criados? 
Modelagem de Sistemas em UML 
Marcio Quirino - 122 
 
Neste módulo, você vai aprender o que são padrões de projeto, como eles são definidos e entender 
as vantagens e desvantagens da sua utilização. 
Motivação e origem dos padrões de projeto 
• Imagine que você foi alocado em um novo trabalho, ficando responsável por evoluir um 
sistema desenvolvido por outras pessoas ao longo de anos. 
• Você não se sentiria mais confortável se o software tivesse sido projetado com estruturas de 
solução que você já conhecesse? 
Ao aprendermos a programar em uma linguagem orientada a objetos, por exemplo, somos capazes 
de definir classes, atributos, operações, interfaces e subclasses com essa linguagem. Esse conhecimento 
nos permite responder a perguntas operacionais como, por exemplo: 
“Como eu escrevo a definição de uma classe nesta linguagem de programação?”. 
Entretanto, quando temos que estruturar um sistema, a pergunta passa a ser bem mais complexa: 
“Quais classes, interfaces, relacionamentos, atributos e operações devemos definir para resolvermos 
este problema de forma adequada?”. 
Ao desenvolvermos um sistema, nos deparamos inúmeras vezes com essa pergunta. É comum um 
desenvolvedor iniciante se sentir perdido diante da diversidade de respostas possíveis, sendo que algumas 
podem facilitar, enquanto outras podem dificultar bastante as futuras evoluções do sistema. 
Que tipo de conhecimento, então, um desenvolvedor experiente utiliza para estruturar um sistema? 
Fazendo uma analogia com o jogo de xadrez, um desenvolvedor inexperiente guarda semelhanças 
com um jogador iniciante, que sabe colocar as peças no tabuleiro, conhece os movimentos permitidos para 
cada peça e domina alguns princípios elementares do jogo, como a importância relativa das peças, e o 
centro do tabuleiro. 
Um desenvolvedor inexperiente conhece as construções básicas de programação (ex.: sequência, 
decisão, iteração, classes, objetos, atributos, operações) e alguns princípios elementares de estruturação 
de um sistema, tais como dividi-lo em módulos e evitar construir módulos longos e complexos. 
O que diferencia os grandes enxadristas dos iniciantes? 
1. Os grandes enxadristas estudaram ou experimentaram inúmeras situações de jogo e 
acumularam experiência sobre as consequências que determinado lance pode gerar no 
desenrolar da partida. 
2. Quanto maior for o arsenal de situações conhecidas por um jogador, maiores as chances que 
ele terá de fazer uma boa jogada em pouco tempo. 
3. E isso mesmo: os jogadores de xadrez também têm um prazo para cumprir. Existem 
campeonatos que definem um tempo máximo de duas horas para que cada jogador realize 
seus primeiros quarenta lances. 
Um jogador iniciante não aprende apenas jogando e vivenciando essas situações. Ele pode estudar 
inúmeras situações catalogadas pelas quais outros jogadores já passaram. 
Comentário 
Existem catálogos de situações e estratégias para o início, para o meio e para a finalização de um jogo de 
xadrez. 
As estratégias para o início de jogo são conhecidas como aberturas. Cada abertura tem um nome e 
corresponde a um conjunto de jogadas que geram consequências positivas e, eventualmente, negativas 
Modelagem de Sistemas em UML 
Marcio Quirino - 123 
 
para cada lado (peças brancas ou pretas). Uma dessas aberturas é o nome de uma das séries originais 
mais vistas na história da Netflix: O gambito da rainha. 
E o que diferencia os desenvolvedores experientes dos iniciantes? 
Resposta 
Desenvolvedores experientes acumularam conhecimento sobre as consequências de resolver um problema 
aplicando determinada estrutura de solução, isto é, dividindo a solução em um conjunto específico de módulos e 
estabelecendo uma estrutura particular de interação entre eles. Essa experiência acumulada permite-lhes reusar, no 
presente, soluções que funcionaram bem no passado em problemas similares, produzindo sistemas flexíveis, elegantes 
e em menor tempo. 
Muitos problemas em estruturação de software são recorrentes, então que tal registrá-los com as 
respectivas soluções para que, de forma análoga aos livros de abertura do xadrez, possamos compartilhar 
esse conhecimento com desenvolvedores que estejam encarando um problema análogo pela primeira vez? 
Foi o que pensaram quatro engenheiros de software (Erich Gamma, Richard Helm, Ralph Johnson e 
John Vlissides) em 1994, quando publicaram o livro Design patterns: elements of reusable object-oriented 
software, descrevendo 23 padrões que eles utilizaram no desenvolvimento de diversos sistemas ao longo 
de suas carreiras. Os autores ficaram mais conhecidos como a “gangue dos quatro” (tradução de gang of 
four), e os padrões publicados são conhecidos como os “padrões GoF”. Desde então, diversas publicações 
surgiram relatando novos padrões, críticas a padrões existentes, padrões específicos para determinadas 
linguagens e paradigmas de programação, padrões arquiteturais e até mesmo antipadrões – construções 
que tipicamente trazem consequências negativas para a estrutura de um sistema. 
O que é um padrão de projeto 
Um padrão de projeto (design pattern) descreve um problema recorrente e a estrutura fundamental 
da sua solução definida por módulos e pelas comunicações entre eles. 
Em uma estrutura de solução orientada a objetos, a solução é descrita por classes, interfaces e 
mecanismos de colaboração entre objetos. 
Porém, o conceito de padrões de projeto é mais abrangente, uma vez que existem padrões voltados 
para outros paradigmas de programação, como, por exemplo, programação funcional e programação 
reativa. 
Um padrão de projeto apresenta quatro elementos fundamentais: 
A. Nome 
O nome possibilita a comunicação entre os desenvolvedores em um nível mais abstrato. Em 
uma discussão de projeto, em vez de descrevermos todos os elementos participantes da solução 
para um problema, a forma de comunicação entre eles e as consequências do seu uso, basta 
mencionarmos o nome do padrão apropriado. 
Um desenvolvedor experiente pode recomendar algo como: “use o Observer para resolver esse 
problema!”, e isso será suficiente, pois conhecendo o padrão Observer, você já saberá como 
estruturar a solução. Portanto, os nomes dos padrões foram um vocabulário compartilhadopelos 
desenvolvedores, para agilizar a discussão de soluções de projeto. 
B. Problema 
Um padrão deve descrever as situações nas quais a sua utilização é apropriada, explicando o 
problema e o contexto. Os problemas podem ser específicos, como, por exemplo: “como 
podemos representar diferentes algoritmos com o mesmo propósito na forma de classes?” ou 
“como podemos instanciar uma classe específica, dentre várias similares, sem criar uma 
dependência rígida com a implementação escolhida?”. 
Modelagem de Sistemas em UML 
Marcio Quirino - 124 
 
Este elemento também pode descrever e discutir soluções inadequadas ou pouco flexíveis para 
o contexto apresentado, de forma que, se você estiver pensando em uma solução similar às 
descritas, o seu problema passará a ser: “ok, estou vendo que a estrutura que estava pensando 
em aplicar não é adequada. Como devo, então, estruturar a solução?”. 
C. Solução 
O padrão deve descrever os elementos recomendados para a implementação, suas 
responsabilidades, seus relacionamentos e colaborações. A solução é uma descrição abstrata 
que pode ser replicada em diferentes situações e sistemas. O desenvolvedor deve traduzir essa 
descrição abstrata em uma implementação específica no problema particular que ele estiver 
resolvendo. Note que a solução é uma ideia que precisa ser construída e implementada pelo 
desenvolvedor. Um catálogo de padrões de projeto é bem diferente de uma biblioteca de código, 
pois um padrão de projeto não tem o propósito de promover reutilização de código, mas sim de 
conhecimento, know-how. 
D. Consequências 
Um padrão precisa discutir os custos e benefícios da solução proposta. Uma solução pode dar 
maior flexibilidade ao projeto, ao mesmo tempo em que pode trazer maior complexidade ou até 
mesmo resultar em problemas de performance. Antes de utilizarmos um padrão, devemos 
sempre avaliar os custos e benefícios em relação ao problema particular que estamos querendo 
resolver. 
Vantagens e desvantagens do uso de padrões de projeto 
Por que você deve conhecer padrões de projeto? Podemos enumerar alguns motivos: 
1. Padrões facilitam o desenvolvimento, pois permitem a reutilização de soluções bem-
sucedidas em problemas similares. Um padrão não pode ser simplesmente uma ideia; ao 
contrário, só pode ser considerado como tal se passar pela regra dos três: ele deve ter sido 
utilizado em pelo menos três diferentes situações ou aplicações. 
2. Padrões possibilitam maior produtividade ao desenvolvimento, uma vez que não 
desperdiçamos tempo pensando, fazendo e refinando soluções até encontrarmos a mais 
adequada. Padrões nos fornecem um atalho para uma boa solução. 
3. Padrões reforçam práticas de reutilização de código com estruturas que acomodam 
mudanças por meio do uso de mecanismos como delegação, composição e outras técnicas 
que não sejam baseadas em estruturas de herança. 
4. Padrões fornecem uma linguagem comum para os desenvolvedores, agilizando a troca de 
ideias e experiências. 
E quais são as desvantagens ou os pontos de atenção na utilização de padrões de projeto? 
1. Desde que o conceito foi apresentado na década de 1990, surgiu uma grande quantidade de 
padrões. Portanto, a curva de aprendizado pode ser grande. 
2. Decidir se um padrão pode ser empregado em um problema específico nem sempre é uma 
tarefa fácil e requer alguma experiência. 
3. Às vezes é necessário adaptar ou mudar alguma característica da solução proposta por um 
padrão para tornar sua utilização adequada a um problema específico, o que também requer 
experiência. 
4. É comum um iniciante achar que os padrões devem estar por toda a implementação e acabar 
fazendo uso inadequado deles. 
5. Não existe consenso sobre a qualidade de todos os padrões. Singleton, por exemplo, é um 
padrão GoF que gera grande controvérsia, sendo considerado um antipadrão por muitos. 
 
Modelagem de Sistemas em UML 
Marcio Quirino - 125 
 
Principais padrões em linhas gerais 
Os 23 padrões de projeto GoF são classificados em três grandes categorias: 
Criação 
Os padrões de projeto desta categoria têm como objetivo tornar a implementação independente da forma com 
que os objetos são criados, compostos ou representados. 
Os cinco padrões GoF desta categoria são: Abstract Factory, Builder, Factory Method, Prototype e 
Singleton. 
Estrutura 
Os padrões de projeto desta categoria tratam de formas de combinar classes e objetos para formar estruturas 
maiores. 
Os sete padrões GoF desta categoria são: Adapter, Bridge, Composite, Decorator, Facade, Flyweight e 
Proxy. 
Comportamento 
Os padrões de projeto da categoria comportamental tratam de algoritmos, da distribuição de responsabilidades 
pelos objetos e da comunicação entre eles. 
Os onze padrões GoF desta categoria são: Chain of Responsibility, Command, Interpreter, Iterator, 
Mediator, Memento, Observer, State, Strategy, Template Method e Visitor. 
 
Saiba mais 
Existem inúmeros padrões publicados para diferentes problemas: arquitetura e projeto detalhado de software, 
padrões específicos para uma linguagem de programação, testes, gerência de projeto, gerência de configuração, entre 
outros. Você não precisa estudar todos os padrões disponíveis, mas é importante saber que eles existem, onde estão 
descritos e conhecer os problemas que eles resolvem. Assim, no dia em que tiver que resolver um problema similar, 
você poderá aproveitar uma solução utilizada com sucesso por outras pessoas. 
Como achá-los? Experimente fazer uma busca na internet com termos gerais, tais como “pattern books”, 
“patterns catalog”, ou mais específicos, como “java design patterns”, “cloud architecture patterns”, “node js patterns”. 
Você encontrará dicas mais específicas na seção Explore +. 
2. Propósito dos padrões GRASP e as situações nas quais 
eles podem ser aplicados 
GRASP é o acrônimo para o termo em inglês General Responsibility Assignment Software Patterns, 
termo definido por Craig Larman no livro intitulado Applying UML and patterns, que define padrões gerais 
para a atribuição de responsabilidades em software. 
• Os padrões GoF tratam de problemas específicos em projeto de software. 
• Os padrões GRASP podem ser vistos como princípios gerais de projeto de software orientado 
a objetos aplicáveis a diversos problemas específicos. 
Neste módulo, você vai aprender seis padrões GRASP: 
• Especialista 
• Criador 
• Baixo acoplamento 
• Alta coesão 
• Controlador 
• Polimorfismo 
Especialista 
Problema: 
Quando estamos elaborando a solução técnica de um projeto utilizando objetos, a nossa principal 
tarefa consiste em definir as responsabilidades de cada classe e as interações necessárias entre os objetos 
dessas classes, para cumprir as funcionalidades esperadas com uma estrutura fácil de entender, manter e 
estender. 
Modelagem de Sistemas em UML 
Marcio Quirino - 126 
 
Solução: 
Este padrão trata do princípio geral de atribuição de responsabilidades aos objetos de um sistema: 
atribua a responsabilidade ao especialista, isto é, ao módulo que traga o conhecimento necessário para 
realizá-la. 
Comentário 
Atribuir a responsabilidade ao especialista é uma heurística intuitiva que utilizamos no nosso cotidiano. A quem 
você atribuiria a responsabilidade de trocar a parte elétrica da sua casa? Possivelmente a alguém com o conhecimento 
necessário para realizar essa atividade (um especialista), ou seja, um eletricista. 
Suponha que você esteja desenvolvendo um site de vendas de produtos pela internet. 
A figura a seguir apresenta um modelo simplificado de classes desse domínio. Digamos que o site 
deva apresentar o pedido do cliente e o valor total do pedido. 
Como você organizaria as responsabilidades entre as classes, para fornecer essa informação? 
 
Padrão Especialista – classes de domínio. 
O valor total do pedido pode ser definido como a soma do valor de cada um de seus itens. 
Segundo o padrão Especialista, a responsabilidade deveficar com o detentor da informação. Nesse 
caso, quem conhece todos os itens que compõem um pedido? O próprio pedido, não é mesmo? Então, 
vamos definir a operação obterValorTotal na classe Pedido. 
E onde ficaria o cálculo do preço de um item do pedido? 
Quais informações são necessárias para esse cálculo? 
A quantidade e o preço do produto. Quem conhece essas informações? 
A classe Item do Pedido conhece a quantidade e o produto associado. Vamos definir, então, uma 
operação obterValor na classe Item do Pedido. 
E o preço do produto? 
Basta o objeto item do pedido pedir essa informação para o produto, por meio da operação de acesso 
getPrecoUnitario. 
A figura seguinte apresenta o diagrama de classes com a alocação de responsabilidades resultante. 
Modelagem de Sistemas em UML 
Marcio Quirino - 127 
 
 
Padrão Especialista – alocação de responsabilidades. 
O diagrama de sequência da próxima figura ilustra a colaboração definida para implementar a 
obtenção do valor total de um pedido. 
 
Padrão Especialista – colaboração (opção 1). 
Consequências: 
Quando o padrão Especialista não é seguido, é comum encontrarmos uma solução deficiente 
(antipadrão) conhecida como “God Class” – que consiste em definir apenas operações de acesso 
(conhecidas como getters e setters) nas classes de domínio – e concentrar toda a lógica de determinada 
funcionalidade do sistema em uma única classe, usualmente definida na forma de uma classe de controle 
ou de serviço. Essa classe implementa procedimentos utilizando as operações de acesso das diversas 
classes de domínio, que, nesse estilo de solução, são conhecidas como classes “idiotas”. 
Existem, entretanto, situações em que a utilização desse padrão pode comprometer conceitos como 
coesão e acoplamento. 
Exemplo 
Qual classe deveria ser responsável por implementar o armazenamento dos dados de um Pedido no banco de 
dados? 
Pelo princípio do Especialista, deveria ser a própria classe Pedido, uma vez que ela detém todas as 
informações que serão armazenadas. Porém, essa solução acoplaria a classe de negócio com conceitos relativos à 
tecnologia de armazenamento (e.g. SQL, NoSQL, arquivos etc.), ferindo o princípio fundamental da coesão, pois a 
classe Pedido ficaria sujeita a dois tipos de mudança: mudanças no negócio e mudanças na tecnologia de 
armazenamento, o que é absolutamente inadequado. 
Criador 
Problema 
A instanciação de objetos é uma das instruções mais presentes em um programa orientado a objetos. 
Embora um comando simples, como new ClasseX em Java, resolva a questão, a instanciação indiscriminada 
Modelagem de Sistemas em UML 
Marcio Quirino - 128 
 
– e sem critérios bem definidos – de objetos por todo o sistema tende a gerar uma estrutura pouco flexível, 
difícil de modificar e com alto acoplamento entre os módulos. 
Portanto, a pergunta que este padrão tenta responder é: 
Quem deve ser responsável pela instanciação de um objeto de determinada classe? 
Solução 
Coloque em uma classe X a responsabilidade de criar uma instância da classe Y se X for um 
agregado formado por instâncias de Y, ou se X possuir os dados de inicialização necessários para a criação 
de uma instância de Y. 
No exemplo do site de vendas de produtos pela internet, considerando o modelo de classes da figura 
Especialista – classes de domínio, qual classe deveria ser responsável pela criação das instâncias de Item 
do Pedido? 
Resposta 
Uma abordagem comum, mas inadequada, é instanciar o item em uma classe de serviço e apenas acumulá-lo 
no Pedido. Entretanto, quando se trata de uma relação entre um agregado e suas partes, a responsabilidade pela 
criação das partes deve ser alocada ao agregado, responsável por todo o ciclo de vida das suas partes (criação e 
destruição). 
A figura a seguir apresenta o diagrama de classes após definirmos a operação adicionarItem na 
classe Pedido. Perceba que as operações vão sendo definidas nas diversas classes à medida que 
estabelecemos os mecanismos de colaboração para cada funcionalidade do sistema. 
 
Padrão Creator – classes de domínio. 
Consequências 
• O padrão Criador é especialmente indicado para a criação de instâncias que formam parte 
de um agregado, por promover uma solução de menor acoplamento. 
• Por outro lado, o padrão Criador não é apropriado em algumas situações especiais, como, 
por exemplo, a criação condicional de uma instância dentro de uma família de classes 
similares. 
Baixo acoplamento 
Problema 
Acoplamento corresponde ao grau de dependência de um módulo em relação a outros módulos do 
sistema. Um módulo com alto acoplamento depende de vários outros módulos e tipicamente apresenta 
problemas como propagação de mudanças pelas relações de dependência, dificuldade de entendê-lo 
Modelagem de Sistemas em UML 
Marcio Quirino - 129 
 
isoladamente e dificuldade de reusá-lo em outro contexto, por exigir a presença dos diversos módulos que 
formam a sua cadeia de dependências. 
Outra questão importante com relação ao acoplamento é a natureza das dependências. 
• Se uma classe A depende de uma classe B, dizemos que A depende de uma implementação 
concreta presente em B. 
• Por outro lado, se uma classe A depende de uma interface I, dizemos que A depende de uma 
abstração, pois A poderia trabalhar com diferentes implementações concretas de I, sem 
depender de nenhuma específica. 
De forma geral, sistemas mais flexíveis são construídos quando fazemos implementações (classes) 
dependerem de abstrações (interfaces), especialmente quando a interface abstrair diferentes possibilidades 
de implementação, seja por envolver diferentes soluções tecnológicas (ex.: soluções de armazenamento e 
recuperação de dados), seja por envolver diferentes questões de negócio (ex.: diferentes regras de negócio, 
diferentes fornecedores de uma mesma solução de pagamento etc.). 
Portanto, a pergunta que este padrão tenta responder é: 
• Como definir relações de dependência entre as classes de um sistema de forma a manter o 
acoplamento baixo, minimizar o impacto de mudanças e facilitar o reuso? 
Solução 
Distribuir as responsabilidades de forma a gerar um baixo acoplamento entre os módulos. 
Para você entender o conceito de baixo acoplamento, vamos apresentar um contraexemplo, isto é, 
uma situação em que foi criado um acoplamento maior do que o desejado. A figura seguinte apresenta outra 
solução para o problema mostrado no padrão Especialista, na qual fazemos o cálculo do preço do item do 
pedido dentro da operação obterValorTotal da classe Pedido. Para isso, percorremos todos os itens do 
pedido, obtemos a quantidade e o produto de cada item, o preço unitário do produto e multiplicamos a 
quantidade pelo preço unitário. 
Essa solução gerou um acoplamento entre Pedido e Produto que não está presente na solução dada 
pelo padrão Especialista. 
 
Consequências 
Acoplamento é um princípio fundamental da estruturação de software que deve ser considerado em 
qualquer decisão de projeto de software. Portanto, avalie com cuidado se cada acoplamento definido no 
projeto é realmente necessário ou se existem alternativas que levariam a um menor acoplamento, ou, ainda, 
se alguma abstração poderia ser criada para não gerar dependência com uma implementação específica. 
Atenção 
Modelagem de Sistemas em UML 
Marcio Quirino - 130 
 
Cuidado para não gerar soluções excessivamente complexas em que não haja motivação real para criar 
soluções mais flexíveis. Em geral, manter as classes de domínio isoladas e não dependentes de tecnologia (ex.: 
persistência, GUI, integração entre sistemas) é uma política geral de acoplamento que deve ser seguida, recomendada 
por diversas proposições de arquitetura. 
Alta coesão 
Problema 
Coesão é uma forma de avaliar se as responsabilidades de um módulo estão fortemente relacionadas 
e têm o mesmo propósito. Buscamos criar módulos com alta coesão, isto é, elementos com 
responsabilidades focadas e com umtamanho aceitável. 
Comentário 
Módulos ou classes com baixa coesão realizam muitas operações pouco correlacionadas, gerando sistemas 
de difícil entendimento, reuso, manutenção e muito sensíveis às mudanças. 
Portanto, a pergunta que este padrão tenta responder é: 
Como definir as responsabilidades dos módulos de forma que a complexidade resultante seja 
gerenciável? 
Solução 
A solução consiste em definir módulos de alta coesão. Mas como se mede a coesão? 
Coesão está ligada ao critério utilizado para reunir um conjunto de elementos em um mesmo módulo. 
Coesão está ligada ao critério utilizado para reunir um conjunto de elementos em um mesmo módulo. 
A. Coesão de um método de uma classe 
Um método reúne um conjunto de instruções. 
B. Coesão de uma classe 
Uma classe reúne um conjunto de atributos e operações. 
C. Coesão de um pacote 
Um pacote reúne um conjunto de classes e interfaces. 
D. Coesão de um subsistema 
Um subsistema reúne um conjunto de pacotes. 
A coesão de um módulo, seja ele classe, pacote ou subsistema, pode ser classificada de acordo com 
o critério utilizado para reunir o conjunto dos elementos que o compõem. 
Devemos estruturar os módulos de forma que eles apresentem coesão funcional, isto é, os elementos 
são agrupados porque, juntos, cumprem um único propósito bem definido. 
As classes do pacote java.io da linguagem Java, por exemplo, estão reunidas por serem 
responsáveis pela entrada e saída de um programa. Nesse pacote, encontramos classes com 
responsabilidades bem específicas, como: 
A. FileOutputStream 
(para escrita de arquivos binários) 
 
Modelagem de Sistemas em UML 
Marcio Quirino - 131 
 
B. FileInputStream 
(para leitura de arquivos binários) 
C. FileReader 
(para leitura de arquivos texto) 
D. FileWriter 
(para escrita de arquivos texto) 
Consequências 
Coesão e acoplamento são princípios fundamentais em projetos de software. A base da 
modularidade de um software está na definição de módulos com alta coesão e baixo acoplamento. 
Comentário 
Sistemas construídos com módulos apresentando alta coesão tendem a ser mais flexíveis, mais fáceis de 
serem entendidos e evoluídos, além de proporcionarem mais possibilidades de reutilização e de um projeto com baixo 
acoplamento. 
Entretanto, em sistemas distribuídos é preciso balancear a elaboração de módulos com 
responsabilidades específicas com o princípio fundamental de sistemas distribuídos, que consiste em 
minimizar as chamadas entre processos. 
Controlador 
Problema 
Um sistema interage com elementos externos, também conhecidos como atores. Muitos elementos 
externos geram eventos que devem ser capturados pelo sistema, processados e produzir alguma resposta, 
interna ou externa. 
Por exemplo, quando o cliente solicita o fechamento de um pedido na nossa loja online, esse evento 
precisa ser capturado e processado pelo sistema. Este padrão procura resolver o seguinte problema: 
A quem devemos atribuir a responsabilidade de tratar os eventos que correspondam a requisições 
de operações para o sistema? 
Solução 
Atribuir a responsabilidade de receber um evento do sistema e coordenar a produção da sua resposta 
a uma classe que represente uma das seguintes opções: 
A. Opção 1 
Uma classe correspondente ao sistema ou a um subsistema específico, solução conhecida pelo 
nome Controlador Fachada. Normalmente é utilizada em sistemas com poucos eventos. 
B. Opção 2 
Uma classe correspondente a um caso de uso onde o evento ocorra. Normalmente essa classe 
tem o nome formado pelo nome do caso de uso com um sufixo Processador, Controlador, 
Sessao ou algo similar. 
Essa classe deve reunir o tratamento de todos os eventos que o sistema receba no contexto deste 
caso de uso. Esta solução evita a concentração das responsabilidades de tratamento de eventos de 
diferentes funcionalidades em um único Controlador Fachada, evitando a criação de um módulo com baixa 
coesão. 
Modelagem de Sistemas em UML 
Marcio Quirino - 132 
 
Atenção 
Note que esta classe não cumpre responsabilidades de interface com o usuário. Em um sistema de home 
banking, por exemplo, o usuário informa todos os dados de uma transação de transferência em um componente de 
interface com o usuário e, ao pressionar o botão transferir, esse componente delega a requisição para o controlador 
realizar o processamento lógico da transferência. Assim, o mesmo controlador pode atender a solicitações realizadas 
por diferentes interfaces com o usuário (web, dispositivo móvel, totem 24 horas). 
Consequências 
Normalmente, um módulo Controlador, ao receber uma requisição, coordena e controla os elementos 
que são responsáveis pela produção da resposta. 
• Em uma orquestra, um maestro comanda o momento em que cada músico deve entrar em 
ação, mas ele mesmo não toca nenhum instrumento. 
• Da mesma forma, um módulo Controlador é o grande orquestrador de um conjunto de objetos, 
cada qual com sua responsabilidade específica na produção da resposta ao evento. 
Um problema que pode ocorrer com este padrão é alocar ao Controlador responsabilidades além da 
orquestração, como se o maestro, além de comandar os músicos, ficasse responsável também por tocar 
piano, flauta e outros instrumentos. Essa concentração de responsabilidades no Controlador gera um 
módulo grande, complexo e que ninguém se sente confortável em evoluir. 
Polimorfismo 
Problema 
Como evitar construções condicionais complexas no código? 
Suponha que você esteja implementando a parte de pagamento em cartão de uma loja virtual. Para 
realizar um pagamento interagindo diretamente com uma administradora de cartão, temos que passar por 
um processo longo e complexo de homologação junto a ela. Imagine realizar esse processo com cada 
administradora! 
Broker 
Broker é o software intermediário que permite que programadores façam chamadas a programas de um 
computador para outro. 
API 
Interface de Programação de Aplicação, do inglês Application Programming Interface 
Para simplificar o problema, existem diferentes brokers de pagamento que já são homologados com 
as diversas administradoras e fornecem uma API para integração com a nossa aplicação. Cada broker tem 
uma política de preços e volume de transações e, eventualmente, podem surgir novos broker com políticas 
mais atrativas no mercado. 
Agora imagine que fornecemos uma solução de software de loja virtual para diferentes lojas, que 
podem demandar diferentes brokers de pagamento em função das suas exigências de segurança, preço e 
volume de transações. Isso significa que o nosso software tem que ser capaz de funcionar com diferentes 
brokers, cada um com a sua API. 
Sem polimorfismo, esse problema poderia ser resolvido com uma solução baseada em if-then-else 
ou switch-case, sendo cada alternativa de brokers mapeada para um comando case no switch ou em uma 
condição no if-then-else (figura a seguir). 
Pense como ficaria esse código se houvesse vinte brokers diferentes. 
Modelagem de Sistemas em UML 
Marcio Quirino - 133 
 
 
Solução sem polimorfismo. 
O problema que esse padrão resolve é o seguinte: 
Como escrever uma solução genérica para alternativas baseadas no tipo de um elemento, criando 
módulos plugáveis? 
No nosso exemplo, as alternativas são todos os diferentes tipos de brokers com as suas respectivas 
APIs. 
Solução 
Percebeu como a solução baseada em estruturas condicionais do tipo if-then-else ou switch-case, 
além de serem mais complexas, criam um acoplamento do módulo chamador com cada implementação 
específica? Note como a classe Fechamento Pedido depende diretamente de todas as implementações de 
broker de pagamento. 
A solução via polimorfismo consiste em criar uma interface genérica para a qual podem existir 
diversas implementações específicas (veja na figura seguinte). 
A estrutura condicional é substituída por uma única chamada utilizando essa interface genérica. O 
chamador, portanto, não precisa saber quem estádo outro lado da interface concretamente provendo a 
implementação. Essa capacidade de um elemento (a interface genérica) poder assumir diferentes formas 
concretas (broker1, broker2 ou broker3, no nosso exemplo) é conhecida como polimorfismo. 
 
Solução com polimorfismo. 
Consequências 
Polimorfismo é um princípio fundamental em projetos de software orientados a objetos que nos ajuda 
a resolver, de forma sintética, elegante e flexível, o problema de lidar com variantes de implementação de 
uma mesma operação conceitual. 
Modelagem de Sistemas em UML 
Marcio Quirino - 134 
 
Dica 
Esse princípio geral é utilizado para a definição de diversos padrões GoF, tais como: Adapter, Command, 
Composite, Proxy, State e Strategy. 
Entretanto, é preciso ter cuidado para não implementar estruturas genéricas em situações em que 
não haja possibilidade de variação. Uma solução genérica é mais flexível, mas é preciso estar atento para 
não investir esforço na produção de soluções genéricas para problemas que sejam específicos por natureza, 
isto é, que não apresentem variantes de implementação. 
3. Características dos princípios SOLID 
Princípios SOLID 
Você já ouviu falar em SOLID? 
Esse termo é frequentemente encontrado como um conhecimento requisitado em perfis de vagas 
para desenvolvimento de software. 
SOLID é um acrônimo para cinco princípios de projeto orientado a objetos, definidos por Robert C. 
Martin, que devem ser seguidos para nos ajudar a produzir software com uma estrutura sólida, isto é, uma 
estrutura que permita sua evolução e manutenção com menor esforço. 
Cada letra do acrônimo corresponde a um dos princípios: 
S. Single-Responsibility Principle (SRP) 
O. Open-closed Principle (OCP) 
L. Liskov Substitution Principle (LSP) 
I. Interface Segregation Principle (ISP) 
D. Dependency Inversion Principle (DIP) 
Princípio da Responsabilidade Única (SRP) 
O princípio SRP (do inglês Single Responsibility Principle) estabelece que o módulo deve ser 
responsável por um – e apenas um – ator, representando o papel desempenhado por alguém envolvido com 
o software. Nesse contexto, um módulo corresponde a um arquivo-fonte. 
Exemplo 
Em Java, um módulo corresponde a uma classe. 
Suponha que a nossa loja virtual tenha requisitos de busca de produtos por nome e por 
departamento, cadastro de um novo produto e exportação de dados dos produtos em formato CSV. Se 
pensarmos conforme o padrão Especialista, por exemplo, todas essas funcionalidades trabalham com os 
dados dos produtos e, portanto, poderiam ser alocadas ao módulo ProdutoRepository, conforme ilustrado 
na figura seguinte. 
 
Violação do princípio SRP. 
Modelagem de Sistemas em UML 
Marcio Quirino - 135 
 
Atenção 
Essa alocação de responsabilidades viola o princípio SRP, pois define um módulo que atende a diferentes 
atores. 
Vamos analisar os atores envolvidos com cada responsabilidade do módulo: 
• Pesquisar produtos por nome e por departamento são demandas do cliente da loja. 
• Incluir produto é uma demanda da área de vendas. 
• GerarCSV é uma demanda da área de integração de sistemas. 
Portanto, o módulo ProdutoRepository apresenta diferentes razões para mudar: a área de integração 
pode demandar um novo formato para a exportação dos dados dos produtos, enquanto os clientes podem 
demandar novas formas de pesquisar os produtos. 
De acordo com o princípio SRP, devemos separar essas responsabilidades em três módulos, o que 
nos daria a flexibilidade de, por exemplo, separar a busca de produtos e a inclusão de produtos em serviços 
fisicamente independentes, o que possibilitaria atender diferentes demandas de escalabilidade de forma 
mais racional. 
Exemplo 
A busca de produtos pode ter que atender a milhares de clientes simultâneos, enquanto esse número, no caso 
da inclusão de produtos, não deve passar de algumas dezenas de usuários. 
Princípio Aberto Fechado (OCP) 
O princípio OCP (do inglês Open Closed Principle) estabelece que um módulo deve estar aberto para 
extensões, mas fechado para modificações, isto é, seu comportamento deve ser extensível sem que seja 
necessário alterá-lo para acomodar as novas extensões. 
Quando uma mudança em um módulo causa uma cascata de modificações em módulos 
dependentes, isso é sinal de que a estrutura do software não acomoda mudanças adequadamente. Se 
aplicado de forma adequada, este princípio permite que futuras mudanças desse tipo sejam feitas pela 
adição de novos módulos, e não pela modificação de módulos já existentes. 
Você deve estar pensando como é possível fazer com que um módulo estenda seu comportamento 
sem que seja necessário mudar uma linha do seu código. A chave para esse enigma chama-se abstração. 
Em uma linguagem orientada a objetos, é possível criar uma interface abstrata que apresente diferentes 
implementações concretas e, portanto, um novo comportamento, em conformidade com essa abstração, 
pode ser adicionado simplesmente criando-se um módulo. 
O exemplo a seguir apresenta um código que não segue o princípio Open Closed. A classe 
CalculadoraGeometrica contém operações para calcular a área de triângulos e quadrados. 
Violação do princípio OCP (clonagem). 
 
public class Triangulo { 
 private double base; 
 private double altura; 
 
 public double getBase() { 
 return base; 
 } 
 
 public void setBase(double base) { 
 this.base = base; 
 } 
 
 public double getAltura() { 
 return altura; 
 } 
Modelagem de Sistemas em UML 
Marcio Quirino - 136 
 
 
 public void setAltura(double altura) { 
 this.altura = altura; 
 } 
} 
 
public class Quadrado { 
 double lado; 
 
 public double getLado() { 
 return lado; 
 } 
 
 public void setLado(double lado) { 
 this.lado = lado; 
 } 
} 
 
public class CalculadoraGeometrica { 
 public double obterArea(Quadrado quadrado) { 
 return quadrado.getLado() * quadrado.getLado(); 
 } 
 
 public double obterArea(Triangulo triangulo) { 
 return triangulo.getBase() * triangulo.getAltura() / 2; 
 } 
} 
Imagine que o programa tenha que calcular a área de um círculo, por exemplo. 
O módulo CalculadoraGeometrica poderá calcular a área de um círculo sem que o seu código seja 
alterado? 
Não, pois teremos que adicionar uma nova operação obterArea à CalculadoraGeometrica. Essa é 
uma forma comum de violação, em que uma classe concentra diversas operações da mesma natureza que 
operam sobre tipos diferentes. 
O exemplo a seguir ilustra outra forma comum de violação do princípio OCP. 
public class FiguraGeometrica { 
} 
 
public class Triangulo extends FiguraGeometrica { 
 private double base; 
 private double altura; 
 
 public double getBase() { 
 return base; 
 } 
 
 public void setBase(double base) { 
 this.base = base; 
 } 
 
 public double getAltura() { 
 return altura; 
 } 
 
 public void setAltura(double altura) { 
 this.altura = altura; 
 } 
} 
 
public class Quadrado extends FiguraGeometrica { 
 double lado; 
 
 public double getLado() { 
 return lado; 
 } 
Modelagem de Sistemas em UML 
Marcio Quirino - 137 
 
 
 public void setLado(double lado) { 
 this.lado = lado; 
 } 
} 
 
public class CalculadoraGeometrica { 
 public double obterArea(FiguraGeometrica figura) { 
 if (figura instanceof Quadrado) { 
 return obterAreaQuadrado((Quadrado) figura); 
 } else if (figura instanceof Triangulo) { 
 return obterAreaTriangulo((Triangulo) figura); 
 } else { 
 return 0.0; 
 } 
 } 
 
 private double obterAreaQuadrado(Quadrado quadrado) { 
 return quadrado.getLado() * quadrado.getLado(); 
 } 
 
 private double obterAreaTriangulo(Triangulo triangulo) { 
 return triangulo.getBase() * triangulo.getAltura() / 2; 
 } 
} 
Neste caso, a classe CalculadoraGeometrica possui uma operaçãoobterArea, que recebe um tipo 
genérico FiguraGeometrica, mas continua concentrando a lógica de cálculo para todos os tipos de figuras. 
Para incluir um círculo, precisaríamos adicionar a operação obterAreaCirculo e modificar a implementação 
da operação obterArea, inserindo uma nova condição. Imagine como ficaria o código dessa operação se ela 
tivesse que calcular a área de cinquenta tipos diferentes de figuras geométricas! 
O que devemos fazer para que o módulo CalculadoraGeometrica possa estar aberto para trabalhar 
com novos tipos de figuras sem precisarmos alterar o seu código? 
A resposta está no emprego da abstração e, neste exemplo, dos princípios do Especialista e do 
Polimorfismo. 
• Para isso, definimos que toda figura geométrica é capaz de calcular sua área, sendo que a 
fórmula de cálculo de cada figura específica deve ser implementada nas realizações 
concretas de FiguraGeometrica. 
• Dessa forma, para adicionar uma nova figura geométrica, basta adicionar um novo módulo 
com uma implementação específica para essa operação. 
O próximo exemplo ilustra a nova estrutura do projeto. 
A classe FiguraGeometrica define uma operação abstrata obterArea. Aplicando o princípio do 
Especialista, cada subclasse fica responsável pelo cálculo da sua área. Aplicando o princípio do 
Polimorfismo, o módulo CalculadoraGeometrica passa a depender apenas da abstração FiguraGeometrica, 
que define que todo elemento desse tipo é capaz de calcular a sua área. Dessa forma, a calculadora 
geométrica pode funcionar com novos tipos de figuras, sem que seja necessário alterar o seu código, uma 
vez que ela deixou de depender da forma específica da figura. 
Reestruturação adequada ao princípio OCP. 
 
public abstract class FiguraGeometrica { 
 public abstract double obterArea(); 
} 
 
public class Triangulo extends FiguraGeometrica { 
 private double base; 
 private double altura; 
Modelagem de Sistemas em UML 
Marcio Quirino - 138 
 
 
 public double obterArea() { 
 return this.getBase() * this.getAltura() / 2; 
 } 
 
 public double getBase() { 
 return base; 
 } 
 public void setBase(double base) { 
 this.base = base; 
 } 
 public double getAltura() { 
 return altura; 
 } 
 public void setAltura(double altura) { 
 this.altura = altura; 
 } 
} 
 
public class Quadrado extends FiguraGeometrica { 
 double lado; 
 
 public double obterArea() { 
 return this.getLado() * this.getLado(); 
 } 
 public double getLado() { 
 return lado; 
 } 
 public void setLado(double lado) { 
 this.lado = lado; 
 } 
} 
 
public class CalculadoraGeometrica { 
 public double obterArea(FiguraGeometrica figura) { 
 return figura.obterArea(); 
Princípio da Substituição de Liskov (LSP) 
O princípio LSP (do inglês Liskov Substitution Principle) foi definido em 1988 por Barbara Liskov e 
estabelece que um tipo deve poder ser substituído por qualquer um de seus subtipos sem alterar o correto 
funcionamento do sistema. 
O exemplo seguinte apresenta um caso clássico de violação do princípio de Liskov. Na geometria, 
um quadrado pode ser visto como um caso particular de um retângulo. Se levarmos essa propriedade para 
a implementação em software, podemos definir uma classe Quadrado como uma extensão da classe 
Retangulo. 
Atenção 
Note que, como a largura do quadrado é igual ao comprimento, a implementação dos métodos de acesso 
(setLargura e setComprimento) do quadrado deve se preocupar em preservar essa propriedade. 
Princípio LSP (Quadrado) 
 
 
public class Retangulo { 
 private double largura; 
 private double comprimento; 
 
 public double area() { 
 return largura * comprimento; 
 } 
 
 public double getLargura() { 
 return largura; 
 } 
Modelagem de Sistemas em UML 
Marcio Quirino - 139 
 
 public void setLargura(double largura) { 
 this.largura = largura; 
 } 
 public double getComprimento() { 
 return comprimento; 
 } 
 public void setComprimento(double comprimento) { 
 this.comprimento = comprimento; 
 } 
} 
 
public class Quadrado extends Retangulo { 
 public void setLargura(double largura) { 
 super.setLargura(largura); 
 super.setComprimento(largura); 
 } 
 public void setComprimento(double largura) { 
 super.setLargura(largura); 
 super.setComprimento(largura); 
 } 
} 
Porém, o próximo exemplo mostra como essa solução viola o princípio da substituição de Liskov. O 
método verificarArea da classe ClienteRetangulo recebe um objeto r do tipo Retangulo. 
De acordo com esse princípio, o código desse método deveria funcionar com qualquer objeto de um 
tipo derivado de Retangulo. Entretanto, no caso de um objeto do tipo Quadrado, a execução da chamada 
setComprimento fará com que os dois atributos do quadrado passem a ter o valor 10. Em seguida, a 
execução da chamada setLargura fará com que os dois atributos do quadrado passem a ter o valor 8 e, 
portanto, o valor retornado pelo método área definido na classe Retangulo será 64 e não 80, violando o 
comportamento esperado para um retângulo. 
Violação do princípio LSP 
 
public class ClienteRetangulo { 
 public void verificarArea(Retangulo r) throws Exception { 
 r.setComprimento(10); 
 r.setLargura(8); 
 if (r.area() != 80) { 
 throw new Exception("area incorreta"); 
 } 
 } 
} 
Esse caso ilustra que, embora um quadrado possa ser classificado como um caso particular de um 
retângulo, o princípio de Liskov estabelece que um subtipo não pode estabelecer restrições adicionais que 
violem o comportamento genérico do supertipo. Nesse caso, o fato de o quadrado exigir que comprimento 
e largura sejam iguais o torna mais restrito que o retângulo. Portanto, definir a classe Quadrado como um 
subtipo de Retangulo é uma solução inapropriada para este problema, do ponto de vista da orientação a 
objetos, por violar o princípio de Liskov. 
Princípio da Segregação de Interfaces (ISP) 
O princípio ISP (do inglês Interface Segregation Principle) estabelece que clientes de uma classe não 
devem ser forçados a depender de operações que eles não utilizem. 
O código do exemplo a seguir apresenta uma interface que viola esse princípio por reunir operações 
que dificilmente serão utilizadas em conjunto. As operações login e registrar estão ligadas ao registro e à 
autorização de acesso de um usuário, enquanto a operação logErro registra mensagens de erro ocorridas 
durante algum processamento, e a operação enviarEmail permite enviar um e-mail para o usuário logado. 
 
Modelagem de Sistemas em UML 
Marcio Quirino - 140 
 
Violação do princípio ISP 
 
public interface IUsuario { 
 boolean login(String login, String senha); 
 boolean registrar(String login, String senha, String email); 
 void logErro(String msgErro); 
 boolean enviarEmail(String assunto, String conteudo); 
} 
Segundo este princípio, devemos manter a coesão funcional das interfaces, evitando colocar 
operações de diferentes naturezas em uma única interface. Aplicando ao exemplo, poderíamos segregar a 
interface original em três interfaces (exemplo a seguir): 
• IAutorizacao, com as operações de login e registro de usuários; 
• IMensagem, com as operações de registro de erro, aviso e informações; 
• IEmail para o envio de e-mail. 
Segregação das interfaces 
 
public interface IAutorizacao { 
 boolean login(String login, String senha); 
 boolean registrar(String login, String senha, String email); 
} 
 
public interface IEmail { 
 boolean enviarEmail(String assunto, String conteudo); 
} 
 
public interface IMensagem { 
 void logErro(String msgErro); 
 void logAviso(String msgAviso); 
 void logInfo(String msgInfo); 
} 
Princípio da Inversãode Dependências (DIP) 
O princípio DIP (do inglês Dependency Inversion Principle) estabelece que as entidades concretas 
devem depender de abstrações e não de outras entidades concretas. Isso é especialmente importante 
quando estabelecemos dependências entre entidades de camadas diferentes do sistema. 
Segundo este princípio, um módulo de alto nível não deve depender de um módulo de baixo nível. 
A. Módulos de alto nível 
São aqueles ligados estritamente ao domínio da aplicação (ex.: Loja, Produto, ServiçoVenda 
etc.). 
B. Módulos de baixo nível 
São ligados a alguma tecnologia específica (ex.: acesso a banco de dados, interface com o 
usuário etc.) e, portanto, mais voláteis. 
O próximo exemplo apresenta um caso de dependência de um módulo de alto nível em relação a um 
módulo de baixo nível. A classe ServicoConsultaProduto depende diretamente da implementação de um 
repositório de produtos que acessa um banco de dados relacional Oracle. 
Essa dependência é estabelecida na operação obterPrecoProduto da classe 
ServicoConsultaProduto pelo comando new ProdutoRepositoryOracle(). 
 
 
Modelagem de Sistemas em UML 
Marcio Quirino - 141 
 
Violação do princípio da Inversão de Dependências 
 
public class ProdutoRepositoryOracle { 
 public Produto obterProduto(String codigo) { 
 Produto p = new Produto(); 
 // implementacao SQL de recuperação do produto 
 return p; 
 } 
 
 public void salvarProduto(Produto produto) { 
 // implementacao SQL de insert ou update do produto 
 } 
} 
 
public class ServicoConsultaProduto { 
 public double obterPrecoProduto(String codigo) { 
 ProdutoRepositoryOracle repositório 
 = new ProdutoRepositoryOracle(); 
 Produto produto = repositorio.obterProduto(codigo); 
 return produto.getPreco(); 
 } 
} 
A figura a seguir apresenta, em um diagrama UML, a relação de dependência existente entre a classe 
concreta ServicoConsultaProduto e a classe concreta ProdutoRepositoryOracle. 
 
Violação do DIP (Diagrama UML). 
Por que essa dependência é inadequada? 
Como aspectos tecnológicos são voláteis, devemos isolar a lógica de negócio, permitindo que a 
implementação concreta desses aspectos possa variar sem afetar as classes que implementam a lógica de 
negócio. 
O exemplo a seguir apresenta uma solução resultante da aplicação deste princípio. A interface 
abstrata (ProdutoRepository) define um contrato abstrato entre cliente (ServicoConsultaProduto) e 
fornecedor (ProdutoRepositoryOracle). Em vez de o cliente depender de um fornecedor específico, ambos 
passam a depender dessa interface abstrata. 
Assim, a classe ServicoConsultaProduto pode trabalhar com qualquer implementação concreta da 
interface ProdutoRepository, sem que seu código precise ser alterado. 
public interface ProdutoRepository { 
 Produto obterProduto(String codigo); 
 void salvarProduto(Produto produto); 
} 
public class ProdutoRepositoryOracle implements ProdutoRepository { 
 public Produto obterProduto(String codigo) { 
 Produto p = new Produto(); 
 // implementacao SQL de recuperação do produto 
 return p; 
 } 
 
 public void salvarProduto(Produto produto) { 
 // implementacao SQL de insert ou update do produto 
 } 
} 
 
public class ServicoConsultaProduto { 
 ProdutoRepository repositorio; 
Modelagem de Sistemas em UML 
Marcio Quirino - 142 
 
 
 public ServicoConsultaProduto(ProdutoRepository repositorio) { 
 this.repositorio = repositorio; 
 } 
 public double obterPrecoProduto(String codigo) { 
 Produto produto = repositorio.obterProduto(codigo); 
 return produto.getPreco(); 
 } 
} 
A figura a seguir apresenta o diagrama UML correspondente à nova estrutura da solução após a 
aplicação desse princípio. A classe ServicoConsultaProduto depende apenas da interface 
ProdutoRepository, enquanto a classe ProdutoRepositoryOracle é uma das possíveis implementações 
concretas dessa interface. 
 
Diagrama UML da solução de acordo com o DIP. 
4. Propósito dos principais padrões GoF e as situações nas 
quais eles podem ser aplicados 
Este módulo apresenta uma seleção de alguns dos padrões GoF mais utilizados no desenvolvimento 
de sistemas. 
Factory Method 
Problema 
Este padrão define uma interface genérica de criação de um objeto, deixando a decisão da classe 
específica a ser instanciada para as implementações concretas dessa interface. Este padrão é muito 
utilizado no desenvolvimento de frameworks. 
Os frameworks definem pontos de extensão (hot spots) nos quais devem ser feitas adaptações do 
código para um sistema específico. Tipicamente, os frameworks definem classes e interfaces abstratas que 
devem ser implementadas nas aplicações que os utilizem. Um exemplo de framework muito usado em Java 
é o Spring. 
Por que este padrão é importante? 
Em aplicações desenvolvidas em Java, por exemplo, podemos criar um objeto de uma classe 
simplesmente utilizando o operador new. 
Comentário 
Embora seja uma solução aceitável para pequenos programas, à medida que o sistema cresce, a quantidade 
de códigos para criar objetos também cresce, espalhando-se por todo o sistema. 
Modelagem de Sistemas em UML 
Marcio Quirino - 143 
 
Como a criação de um objeto determina dependência entre a classe onde a instanciação está sendo 
feita e a classe instanciada, é preciso muito cuidado para não criar dependências que dificultem futuras 
evoluções do sistema. 
Solução 
A figura a seguir apresenta a estrutura de solução proposta pelo padrão Factory Method. 
Os participantes são: 
1. Produto: define o tipo abstrato dos objetos criados pelo padrão. Todos os objetos 
concretamente instanciados serão derivados deste tipo. 
2. ProdutoConcreto: corresponde a qualquer classe concreta que implementa a definição 
abstrata do tipo Produto. Representa as classes específicas em uma aplicação desenvolvida 
com um framework. 
3. Criador: declara um Factory Method que define uma interface abstrata que retorna um objeto 
genérico do tipo Produto. 
4. CriadorConcreto: corresponde a qualquer classe concreta que implemente o Factory Method 
definido abstratamente no Criador. 
 
Estrutura do padrão Factory Method. 
A figura seguinte apresenta um exemplo de aplicação do padrão. 
• Na parte superior, estão as classes que pertencem a um framework genérico de geração de 
relatório. 
• Na parte inferior, estão as classes concretas de uma aplicação que utiliza o framework para 
gerar um relatório de vendas. 
As operações criarCabecalho, criarCorpo e criarRodape, definidas na classe genérica, são 
implementadas concretamente na classe RelatorioVendas. Cada método dessa subclasse cria um objeto 
específico que implementa os tipos abstratos Cabecalho, Corpo e Rodape definidos no framework. 
A classe Relatorio desempenha o papel de Criador, a classe RelatorioVendas corresponde ao 
participante CriadorConcreto, enquanto as classes Cabecalho, Corpo e Rodape desempenham o papel de 
Produto; finalmente, as classes CabecalhoVendas, CorpoVendas e RodapeVendas correspondem ao 
participante ProdutoConcreto. 
Modelagem de Sistemas em UML 
Marcio Quirino - 144 
 
 
Exemplo do padrão Factory Method. 
Consequências 
O padrão Factory Method permite criar estruturas arquiteturais genéricas (frameworks), provendo 
pontos de extensão por meio de operações que instanciam os objetos específicos da aplicação. Dessa 
forma, todo código genérico pode ser escrito no framework e reutilizado em diferentes aplicações, evitando 
soluções baseadas em clonagem ou em estruturas condicionais complexas. 
Adapter 
Problema 
O problema resolvido por este padrão é análogo ao da utilização de tomadas em diferentes partes 
do mundo. 
Exemplo 
Quando um turista americano chega em um hotel no Brasil, ele provavelmente não conseguirá colocar o seu 
carregador de celular na tomada queestá na parede do quarto. 
 
Como ele não pode mudar a tomada que está na parede, pois ela é propriedade do hotel, a solução é utilizar 
um adaptador que converta os pinos do carregador americano em uma saída de três pinos compatível com as tomadas 
brasileiras. 
Como esse problema ocorre em um software? 
1. Imagine que estamos desenvolvendo um software para a operação de vendas de diferentes 
lojas de departamentos, e que cada loja possa utilizar uma solução de pagamento dentre as 
diversas disponíveis no mercado. 
Modelagem de Sistemas em UML 
Marcio Quirino - 145 
 
2. O problema é que cada fornecedor permite a realização de um pagamento em cartão de 
crédito por meio de uma API específica fornecida por ele. 
3. Portanto, o software de vendas deve ser capaz de ser plugado a diferentes API de pagamento 
que oferecem basicamente o mesmo serviço: intermediar as diversas formas de pagamento 
existentes no mercado. 
Gostaríamos de poder fazer um software de vendas aderente ao princípio Open Closed, isto é, um 
software que pudesse trabalhar com novos fornecedores que apareçam no mercado, sem termos que mexer 
em módulos já existentes. 
Solução 
O Adapter é um padrão estrutural, cuja estrutura é apresentada na figura a seguir. 
O participante Fornecedor define uma API proprietária e que não pode ser alterada. O participante 
Alvo representa a generalização dos serviços oferecidos pelos diferentes fornecedores. Os demais módulos 
do sistema utilizarão apenas este participante, ficando isolados do fornecedor concreto da implementação. 
O participante adaptador transforma uma requisição genérica feita pelo cliente em uma chamada à API 
específica do fornecedor com o qual ele está conectado. 
Atenção 
Note que cada fornecedor possuirá um adaptador específico, da mesma forma que existem adaptadores 
específicos para cada padrão de tomada. 
 
Estrutura do padrão Adapter 
A figura a seguir apresenta como este padrão poderia ser aplicado no problema do software para a 
loja de departamentos. Suponha que existam dois brokers de pagamento (ABC e XPTO), sendo as suas 
respectivas API representadas pelas classes BrokerPagamentoABC e BrokerPagamentoXPTO. Note que 
as operações dessas classes, embora similares, têm nomes diferentes e poderiam também ter parâmetros 
de chamada e retorno diferentes. Essas classes são fornecidas pelos fabricantes e não podem ser 
alteradas. 
A aplicação deste padrão consiste em definir uma interface genérica (BrokerPagamento) que será 
utilizada em todos os módulos do sistema que precisem interagir com o brokers de pagamento 
(representados genericamente pela classe Cliente do diagrama). Para cada API específica, criamos um 
adaptador que implementa a interface genérica BrokerPagamento, traduzindo a chamada da operação 
genérica pagtoEmCartaoCredito para o protocolo específico da API. Dessa forma, a operação do 
AdaptadorBrokerABC chamará a operação pagarCartaoCredito do BrokerPagamentoABC, enquanto a 
operação do AdaptadorBrokerXPTO chamará a operação efetuarPagtoCredito de BrokerPagamentoXPTO. 
Modelagem de Sistemas em UML 
Marcio Quirino - 146 
 
 
Exemplo do padrão Adapter. 
Consequências 
O padrão Adapter permite incorporar módulos previamente desenvolvidos, modificando sua interface 
original sem que haja necessidade de alterá-los, possibilitando a utilização de diferentes implementações 
proprietárias por meio de uma única interface, sem criar dependências dos módulos clientes com as 
implementações proprietárias. 
Facade 
Problema 
O problema resolvido pelo padrão estrutural Facade (fachada) é reduzir a complexidade de 
implementação de uma operação do sistema, fornecendo uma interface simples de uso, ao mesmo tempo 
em que evita que a implementação precise lidar com diferentes tipos de objetos e chamadas de operações 
específicas. 
A próxima figura apresenta uma situação típica em que o padrão Facade pode ser utilizado. A classe 
GUI Ponto de Venda representa um elemento da camada de interface com o usuário responsável por 
registrar itens vendidos no caixa da loja. Para isso, quando os dados do item são entrados pelo operador, a 
implementação busca o produto chamando uma operação da classe ProdutoRepository, cria um ItemVenda 
adicionando-o a um objeto Venda, e salva a nova configuração da Venda chamando uma operação da classe 
VendaRepository. Essa solução é inadequada, pois cria inúmeras dependências e gera maior complexidade 
em uma classe de interface com o usuário. 
 
Padrão Facade – problema. 
Modelagem de Sistemas em UML 
Marcio Quirino - 147 
 
Solução 
A figura a seguir mostra como essas dependências entre um elemento de interface com o usuário e 
os elementos de negócio e armazenamento podem ser simplificadas pela introdução da classe 
ServicoVenda. Ela passa a servir de fachada para a execução de uma operação complexa do sistema, 
oferecendo uma interface única e simplificada para a classe GUI Ponto de Venda. Em vez de chamar várias 
operações de diferentes objetos, basta ela chamar a operação registrarItem definida na classe fachada. 
Dessa forma, os elementos da camada de interface com o usuário ficam isolados da complexidade de 
implementação e da estrutura interna dos objetos pertencentes à lógica de negócio envolvida na operação. 
 
Padrão Facade – solução. 
Consequências 
O padrão Facade é bastante utilizado na estruturação dos serviços lógicos que um sistema oferece, 
isolando a camada de interface com o usuário da estrutura da lógica de negócio do sistema. Portanto, este 
padrão nada mais é do que a aplicação do princípio da abstração, em que isolamos um cliente de detalhes 
irrelevantes de implementação, promovendo uma estrutura com menor acoplamento entre as camadas. 
Strategy 
Problema 
O problema resolvido pelo padrão Strategy ocorre quando temos diferentes algoritmos para realizar 
determinada tarefa. 
Exemplo 
Uma loja de departamentos pode ter diferentes políticas de desconto aplicáveis em função da época do ano 
(ex.: Natal, Páscoa, Dia das Mães, Dia das Crianças). 
Como organizar esses algoritmos de forma que possamos respeitar o princípio Open Closed, fazendo 
com que o sistema de vendas possa aplicar novas políticas de desconto sem que seja necessário modificar 
o que já está implementado? 
Solução 
O padrão Strategy define uma família de algoritmos, onde cada um é encapsulado em sua própria 
classe. Os diferentes algoritmos compõem uma família que pode ser utilizada de forma intercambiável, e 
novos algoritmos podem ser adicionados à família sem afetar o código existente. 
A figura a seguir apresenta a estrutura do padrão. O tipo Estrategia define uma interface comum a 
todos os algoritmos, podendo ser implementado como uma classe abstrata ou como uma interface. Essa 
interface genérica é utilizada pelo participante Contexto quando este necessitar que o algoritmo seja 
Modelagem de Sistemas em UML 
Marcio Quirino - 148 
 
executado. Estrategia A, B e C são implementações específicas do algoritmo genérico que o participante 
Contexto pode disparar. A estratégia específica deve ser injetada no módulo Contexto, que pode alimentar 
a estratégia com seus dados. 
 
Padrão Strategy – estrutura. 
A próxima figura apresenta um exemplo de aplicação do padrão Strategy. A classe Venda representa 
uma venda da loja de departamentos. Uma política de desconto pode ser associada a uma venda no 
momento de sua instanciação e utilizada para cálculo do valor a ser pago pelo cliente. 
Para obter o valor a pagar da Venda, basta obter o seu valor total, somando o valor dos seus itens, 
e subtrair o valor retornado pela operação aplicar da instância de PoliticaDesconto, associada ao objeto 
venda. 
Note que novas políticas podem ser agregadas à solução, bastando adicionar uma nova 
implementação da interface PoliticaDesconto. Nenhuma alteração na classe Venda é necessária, pois ela 
faz uso apenas da interface genérica, não dependendo denenhuma política de descontos específica. 
 
Exemplo do padrão Strategy. 
Consequências 
O padrão Strategy permite separar algoritmos de diferentes naturezas dos elementos necessários 
para sua execução. No exemplo da loja de departamentos, podemos aplicar à Venda diferentes tipos de 
algoritmo, tais como: política de desconto, cálculo de frete e prazo de entrega, entre outros. Cada tipo de 
algoritmo conta com especializações que podem ser implementadas em uma família própria de algoritmos. 
O padrão Strategy oferece uma solução elegante e extensível para o encapsulamento de algoritmos 
que podem ter diferentes implementações, isolando, de suas implementações concretas, os módulos 
clientes desses algoritmos. Além disso, permite a remoção de estruturas condicionais complexas 
normalmente presentes quando essas variações não são implementadas com este padrão. 
Modelagem de Sistemas em UML 
Marcio Quirino - 149 
 
Template Method 
Problema 
O padrão Template Method é aplicável quando temos diferentes implementações de uma operação 
em que alguns passos são idênticos e outros são específicos de cada implementação. 
Para ilustrar o problema, suponha a implementação de duas máquinas de bebidas: uma de café e 
outra de chá. O procedimento de preparação é bem similar, com alguns passos em comum e outros 
específicos: 
Máquina de café Máquina de chá 
Esquentar a água Esquentar a água 
Preparar mistura (via moagem do café) Preparar mistura (via infusão do chá) 
Colocar a mistura no copo Colocar a mistura no copo 
Adicionar açúcar, se selecionado Adicionar açúcar, se selecionado 
Adicionar leite, se selecionado Adicionar limão, se selecionado 
Liberar a bebida Liberar a bebida 
 
O problema consiste em implementar diferentes formas concretas de um algoritmo padrão contendo 
pontos de variação, sem clonar o algoritmo em cada forma concreta, nem produzir uma única implementação 
contendo diversas estruturas condicionais. 
Solução 
A figura a seguir apresenta a estrutura geral da solução. 
O procedimento genérico é definido em um método na classe abstrata. Cada passo do procedimento 
é definido como uma operação na classe abstrata. Alguns passos são comuns e, portanto, podem ser 
implementados na própria classe abstrata. Os passos específicos são definidos como operações abstratas 
na classe abstrata, sendo as implementações específicas implementadas nas subclasses, como é o caso 
do passo 2. 
 
Template Method – estrutura. 
A figura seguinte apresenta uma solução para o problema da máquina de café e da máquina de chá 
utilizando este padrão. 
Modelagem de Sistemas em UML 
Marcio Quirino - 150 
 
O método prepararReceita, definido na superclasse MaquinaBebida, possui seis passos que são 
definidos como operações nesta mesma classe. Note que existem dois passos definidos como operações 
abstratas, pois são executados de forma específica nas duas máquinas: prepararMistura e 
adicionarComplemento. Cada máquina derivada da classe abstrata MaquinaBebida implementa apenas os 
passos específicos, isto é, apenas a implementação dessas duas operações abstratas. 
 
Template Method – exemplo. 
Consequências 
O padrão Template Method evita a duplicação de algoritmos que apresentem a mesma estrutura, 
com alguns pontos de variação entre eles. O algoritmo é implementado apenas uma vez em uma classe 
abstrata onde são definidos os pontos de variação. As subclasses específicas implementam esses pontos 
de variação. Dessa forma, qualquer alteração no algoritmo comum pode ser feita em apenas um módulo. 
Esse padrão é muito utilizado na implementação de frameworks, permitindo a construção de 
estruturas de controle invertidas, também conhecidas como “princípio de Hollywood” ou “Não nos chame, 
nós o chamaremos”, referindo-se a estruturas em que a superclasse é quem chama os métodos definidos 
nas subclasses, e não o contrário. 
Considerações Finais 
Neste estudo, você viu que os desenvolvedores de software devem produzir sistemas com uma 
estrutura adequada que permita a sua evolução com custos e prazos aceitáveis. Padrões de projeto formam 
um corpo de conhecimento muito útil, pois permitem a reutilização de boas soluções de projeto e a produção 
de sistemas bem estruturados. 
Viu também como os padrões GRASP e o princípios SOLID oferecem um conjunto de conceitos 
fundamentais para qualquer projeto de software e, em especial, para projetos orientados a objetos. Saber 
estruturar sistemas em módulos com baixo acoplamento e alta coesão, aplicando conceitos como 
polimorfismo, inversão de dependências e módulos abertos para extensões sem precisarem ser 
modificados, é uma habilidade fundamental para os desenvolvedores de software atualmente. 
Finalmente, você conheceu os principais padrões de projeto GoF e viu como eles promovem o reuso 
de soluções para problemas recorrentes em projetos de software. 
O assunto é vasto e de grande importância no mercado, sendo o seu conhecimento um diferencial 
do profissional de desenvolvimento de sistemas. Um aspecto interessante nessa área é que, dentro do 
espírito de reuso de padrões de projeto, a comunidade de desenvolvimento costuma compartilhar suas 
experiências de forma colaborativa. 
Modelagem de Sistemas em UML 
Marcio Quirino - 151 
 
Referências 
BUSCHMANN, F. et al. Pattern-oriented software architecture: a system of patterns. 1. ed. River 
Street, NJ: John Wiley & Sons, 2000. 
GAMMA, E. et al. Design patterns: elements of reusable object-oriented software. 1. ed. Boston: 
Addison-Wesley, 1994. 
LARMAN, C. Applying UML and patterns: an introduction to object-oriented analysis and design and 
iterative development. 3. ed. Upper Saddle River, NJ: Prentice Hall, 2004. 
MARTIN, R.C. Clean architecture: a craftsman´s guide to software structure and design. 1. ed. Upper 
Saddle River, NJ: Prentice Hall, 2017. 
Explore+ 
Indicamos a leitura dos livros: 
Patterns of enterprise application architecture, de Martin Fowler. O livro apresenta padrões para 
módulos de interface com o usuário, persistência de dados, lógica de negócio e integração de sistemas. 
Java EE 8 design patterns and best practices, de Rhuan Rocha e João Purificação. O livro aborda 
padrões para interface com o usuário, lógica do negócio, integração de sistemas, orientação a aspectos, 
programação reativa e microsserviços. 
Além de livros-texto, é possível encontrar muitos artigos técnicos por meio de buscas na internet, 
usando os acrônimos dos tipos de padrões e princípios abordados no conteúdo (GoF, GRASP, SOLID) ou 
os nomes específicos dos padrões e princípios que pretenda utilizar, aproveitando soluções adotadas com 
sucesso por outras pessoas.