Modelagem de Sistemas

Prévia do material em texto

UNIVERSIDADE FEDERAL DE JUIZ DE FORA 
INSTITUTO DE CIÊNCIAS EXATAS 
 DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO 
 
LICENCIATURA EM COMPUTAÇÃO 
 
 
 
 
 
 
 
 
 
 
 
 
MODELAGEM DE SISTEMAS 
 
 
 
 
 
 
 
 
 
 
 
 
 
Elaborado por: Prof. Michel Heluey Fortuna 
 
 
 
 
 
 
 
 
Agosto/2012
 
ii 
 
Apresentação 
 
[Sobre o material] 
Este material de estudo versa sobre modelagem de sistemas, especialmente, sistemas de 
software. Ele foi elaborado para servir de apoio à disciplina de mesmo nome, com carga 
horária de 30 horas, do curso de Licenciatura em Computação da Universidade Federal de 
Juiz de Fora (UFJF). 
Uma vez que a disciplina-alvo deste material não tem pré-requisito formal, o objetivo 
foi fazê-lo autocontido. Isso significa, entre outras coisas, que alguns conceitos de 
orientação a objetos, necessários ao entendimento do conteúdo aqui apresentado sobre 
modelagem, foram incorporados ao longo do texto. 
Apenas uma parte do rol de modelos existentes para a representação das diferentes 
visões de um sistema e, em particular, do rol de modelos preconizados pela Unified 
Modeling Language (UML), foi coberta aqui. Isso se deveu, principalmente, à limitação de 
carga horária da disciplina-alvo. Pelo mesmo motivo, nem todos os detalhes dos modelos 
cobertos foram incluídos. De qualquer forma, tanto os modelos cobertos, quanto os 
detalhes de cada um, estão entre os mais básicos, estáveis e frequentemente utilizados no 
desenvolvimento de software. 
[Sobre o autor] 
O autor deste material de estudo é doutor em Engenharia de Sistemas e Computação pela 
Universidade Federal do Rio de Janeiro (COPPE/UFRJ) e professor do Departamento de 
Ciência da Computação da Universidade Federal de Juiz de Fora (UFJF). Durante um bom 
tempo atuou também como analista de sistemas em empresas privadas e estatais. Sua 
principal área de interesse é a modelagem de sistemas de informação. 
 
iii 
 
Sumário 
 
Lista de Figuras e Tabelas .............................................................................. v 
1. Introdução .................................................................................................. 1 
O que são modelos? ............................................................................................ 3 
Linguagens x Modelos ........................................................................................ 4 
O paradigma OO ................................................................................................. 5 
UML ................................................................................................................... 6 
2. Modelo de Casos de Uso ........................................................................... 8 
2.1. Introdução ............................................................................................................... 8 
2.2. Diagrama de UCs .................................................................................................... 9 
2.3. Descrição dos UCs ................................................................................................ 10 
Sumário ............................................................................................................. 11 
Fluxo de Eventos .............................................................................................. 11 
2.4. Relacionamentos entre UCs .................................................................................. 14 
Inclusão ............................................................................................................. 14 
Extensão ............................................................................................................ 14 
Considerações sobre Include e Extend ............................................................. 15 
Generalização ................................................................................................... 17 
3. Diagrama de Classes de Objetos ............................................................ 20 
3.1. Introdução ............................................................................................................. 20 
Classe  Objeto ................................................................................................. 21 
3.2. Associações entre classes ...................................................................................... 22 
Associação reflexiva ......................................................................................... 24 
Classe de associação ......................................................................................... 24 
Agregação e Composição ................................................................................. 25 
Generalização/especialização ........................................................................... 27 
4. Diagrama de Estados .............................................................................. 29 
4.1. Introdução ............................................................................................................. 29 
4.2. Elementos de um DE ............................................................................................ 31 
Estados .............................................................................................................. 31 
Eventos ............................................................................................................. 32 
Transições ......................................................................................................... 34 
Atividades ......................................................................................................... 34 
Ações ................................................................................................................ 36 
Estados compostos e subestados sequenciais ................................................... 36 
4.3. Relação com outros modelos ................................................................................ 37 
5. Diagrama de Sequência .......................................................................... 39 
5.1. Introdução ............................................................................................................. 39 
 
iv 
 
5.2. DS  DSS .............................................................................................................. 39 
5.3. Elementos do DS .................................................................................................. 41 
Linha de vida e barras de ativação .................................................................... 41 
Mensagens ........................................................................................................ 42 
Fragmentos de sequência .................................................................................. 45 
5.4. Relação com os outros modelos ............................................................................ 47 
6. Diagrama de Comunicação .................................................................... 48 
6.1. Introdução ............................................................................................................. 48 
6.2. Comparação com outros modelos ......................................................................... 49 
6.3. Comparação: DCom  DS .................................................................................... 50 
6.4. Traduzindo um DS em um DCom ........................................................................ 51 
7. Diagrama de Atividade ........................................................................... 53 
7.1. Introdução .............................................................................................................53 
7.2. Elementos do DA .................................................................................................. 55 
Ação .................................................................................................................. 55 
Transições ......................................................................................................... 55 
Nó objeto .......................................................................................................... 55 
Nó Início da Atividade...................................................................................... 56 
Decisão e Aglutinação ...................................................................................... 56 
Nós de finalização............................................................................................. 57 
Ramificação e Junção ....................................................................................... 58 
Evento temporal ................................................................................................ 59 
Eventos externos ............................................................................................... 59 
Subatividade ..................................................................................................... 60 
Nó conector ....................................................................................................... 62 
7.3. Relação com outros modelos / diagramas ............................................................. 62 
Bibliografia..............................................................................................63 
 
v 
 
Lista de Figuras e Tabelas 
Figuras: 
Figura 1.1: Como se constrói (e se cobra por) software!? ..................................................... 1 
Figura 1.2: Requisitos iniciais do Sistema Restaurante ......................................................... 3 
Figura 1.3: Planta baixa (modelo) de uma residência destacando uma janela ...................... 5 
Figura 1.4: Diagramas da UML 2.4 ....................................................................................... 6 
Figura 2.1: Exemplo de diagrama de casos de uso ................................................................ 9 
Figura 2.2: Níveis mais comuns de detalhamento na descrição de UCs ............................. 10 
Figura 2.3: Fluxo de eventos do UC Pagar a nota (Sistema Restaurante) ......................... 12 
Figura 2.4: Fluxo de eventos do UC Abrir conta (sistema bancário) .................................. 12 
Figura 2.5: Fluxo de eventos com alternativa (UC Pagar a nota) ...................................... 13 
Figura 2.6: Representação do relacionamento de inclusão entre UCs ................................ 14 
Figura 2.7: Representação do relacionamento de extensão entre UCs ................................ 15 
Figura 2.8: Efeito de A includes B sobre o fluxo de eventos dos UCs A e B ..................... 16 
Figura 2.9: Efeito de A extends B sobre o fluxo de eventos dos UCs A e B ...................... 17 
Figura 2.10: Representação do relacionamento de generalização entre UCs ...................... 18 
Figura 2.11: Exemplo de relacionamento generalização entre dois UCs ........................... 18 
Figura 3.1: Exemplo de diagrama de classes de objetos ..................................................... 20 
Figura 3.2: Uma classe (de objetos) Pessoa e um objeto dessa classe ................................ 22 
Figura 3.3: Associação, ligações e multiplicidades ............................................................. 23 
Figura 3.4: Associação reflexiva e papéis ........................................................................... 24 
Figura 3.6: Exemplos de associações do tipo agregação ..................................................... 25 
Figura 3.7: Exemplos de associações do tipo composição .................................................. 26 
Figura 3.8: Generalização / especialização entre classes .................................................... 28 
Figura 3.9: Metamodelo (parcial) de um DC ...................................................................... 28 
Figura 4.1: DE de um sistema de portão de garagem automatizado ................................... 29 
Figura 4.2: Elementos de um DE e sua representação gráfica ............................................ 31 
Figura 4.3: DE (protocolo) da classe Pedido do sistema Restaurante ................................ 33 
Figura 4.4: DE do negócio de um restaurante ..................................................................... 35 
Figura 4.5: Estados civis de uma pessoa (utilizando estados compostos) ........................... 36 
Figura 5.1: DS de sistema (DSS) – Caso de uso Pedir a nota (sistema Restaurante) ......... 39 
Figura 5.2: Diagrama de sequência – Caso de uso Pedir a nota (sistema Restaurante) ..... 40 
Figura 5.3: Linha de vida e barras de ativação .................................................................... 41 
Figura 5.4: Tipos de mensagens .......................................................................................... 42 
Figura 5.5: Exemplo de utilização de mensagem assíncrona .............................................. 43 
Figura 5.6: Formas equivalentes de retorno de mensagem ................................................. 44 
Figura 5.7: Exemplos de fragmentos de sequência ............................................................. 46 
Figura 5.8: Forma alternativa para fragmento opt simples .................................................. 46 
Figura 5.9: Forma alternativa para o fragmento loop simples ............................................. 47 
Figura 6.1: Exemplo de diagrama de comunicação (DCom) .............................................. 48 
Figura 6.2: Tipos de mensagens .......................................................................................... 49 
Figura 6.3: Respostas fora de ordem em mensagens assíncronas ....................................... 50 
Figura 6.4: DS a traduzir para DCom .................................................................................. 51 
Figura 6.5: Primeiro passo de tradução – Objetos ............................................................... 52 
Figura 6.6: Segundo passo de tradução – Ligações ............................................................. 52 
Figura 6.7: Terceiro passo de tradução – Mensagens .......................................................... 52 
Figura 7.1: Exemplo de diagrama de atividade (DA) – venda por telefone ........................ 54 
Figura 7.2: Representação gráfica dos nós e transições de um DA ..................................... 55 
 
vi 
 
Figura 7.3: (a) Combinação de aglutinação e decisão; (b) Significado da combinação ...... 57 
Figura 7.4: (a) Combinação de junção e ramificação; (b) Significado da combinação....... 58 
Figura 7.5: Exemplo de evento temporal recorrente ........................................................... 59 
Figura 7.6: Envio e recebimento de sinais ........................................................................... 59 
Figura 7.7: Espera desde o início da atividade .................................................................... 60 
Figura 7.8: Exemplo de utilização do nó de subatividade – Subatividade Libera pedido .. 61 
Figura 7.9: DA da subatividade Libera pedido ................................................................... 61 
Figura 7.10: Utilização de conector em um DA .................................................................. 62 
 
Tabelas: 
Tabela 3.1: Comparação entre agregação e composição ..................................................... 26 
Tabela 5.1: Exemplos válidos de mensagens (sintaxe) ....................................................... 45 
Tabela 5.2: Alguns operadores de fragmentos de sequência............................................... 45 
Tabela 6.1: Comparação entre o DCom e o DS .................................................................. 50 
 
Modelagem de Sistemas Capítulo 1: Introdução 
 
1 
 
1. Introdução 
Observe atentamente a Figura 1.1 abaixo; o que ela lhe diz? 
 
Figura 1.1: Como se constrói (e se cobra por) software!?
1
 
A primeira reação à figura acima pode ser rir... De fato, ela é engraçada! Mas logo se 
percebe o quanto ela reflete a realidade dos problemas enfrentados por aqueles que se 
envolvem com a tarefa de desenvolver um sistema computacional, com o seu componente 
de software. Eu mesmo já acompanhei diversos projetos de desenvolvimento de software e 
pude observar muitos desses problemas. Nas próximas linhas vou tentar expressar o que 
essa figura me diz ou recorda, com base na minha experiência como analista de sistemas. 
Meu objetivo é motivá-lo(a) a conhecer e a saber utilizar o ferramental descrito neste 
material de estudo, pois ele poderá lhe ajudar a resolver, ou pelo menos contornar, parte 
das dificuldades enfrentadas por todos que se dedicam a desenvolver software. 
O processo de desenvolvimento de software envolve a participação de, pelo menos, 
dois grupos distintos de profissionais, normalmente com formação muito distinta: o grupo 
dos clientes ou usuários (do futuro sistema) e o grupo dos desenvolvedores. O grupo dos 
usuários costuma envolver pessoas das mais diversas áreas de atuação profissional, tais 
como, administradores, engenheiros, profissionais de saúde, de educação, técnicos, etc. O 
outro grupo, o dos desenvolvedores, normalmente tem formação em computação – são, 
principalmente, os analistas de sistemas e os programadores. Os analistas consultam os 
 
 
1
 Autoria desconhecida. 
Modelagem de Sistemas Capítulo 1: Introdução 
 
2 
 
clientes e projetam um sistema para atendê-los e os programadores elaboram o software 
necessário ao funcionamento do sistema. 
O cliente nem sempre tem uma ideia clara do que seria uma solução adequada para 
as suas necessidades. Como todo profissional, ele está em contínuo processo de 
aprendizagem, procurando melhorar suas práticas e obter soluções que atendam essas 
necessidades. Além disso, com raras exceções, o cliente não está a par de todas as 
possibilidades que as tecnologias de informação, comunicação e computação oferecem. 
Portanto, o analista não deve aceitar passivamente tudo o que ele propõe, mas sim 
investigar em parceria com o seu cliente, a qualidade da solução sugerida por ele e, juntos, 
confirmar, aperfeiçoar, ou eventualmente chegar a outro tipo de solução. Se o analista não 
adotar essa atitude proativa na definição do sistema, ele corre o sério risco de projetar um 
sistema incapaz de atender os propósitos do cliente. Infelizmente, esse erro é muito comum 
entre analistas inexperientes. 
Essa parceria entre cliente e analista pressupõe alguns requisitos básicos, dos quais, o 
mais importante talvez seja que exista uma linguagem comum capaz de permitir uma 
comunicação efetiva entre as diferentes categorias de profissionais envolvidos. Em 
primeiro lugar, essa linguagem deve incluir os termos e conceitos do domínio de trabalho 
do cliente, para que o analista possa entender os problemas que o cliente enfrenta e espera 
ver resolvidos com o sistema a ser desenvolvido. No entanto, essa linguagem comum 
também precisa incluir termos, conceitos e estruturas próprias das tecnologias de 
informação, comunicação e computação, para que o cliente possa acompanhar e contribuir 
com o analista, na busca pela solução de software capaz de atender plenamente os seus 
anseios. É nesse requisito que o material ora apresentado para estudo pode contribuir. Ele 
apresenta uma proposta de linguagem, que é parte de uma linguagem maior padronizada 
mundialmente sob a denominação de UML (Unified Modeling Language), a ser utilizada 
no levantamento das necessidades dos clientes, na análise dessas necessidades e no projeto 
de uma solução para atendê-las. Com essa linguagem, os analistas constroem modelos que 
vão sendo aperfeiçoados e detalhados aos poucos, parte deles com a ajuda dos clientes, até 
refletirem com razoável precisão o sistema a ser construído. Depois, esses modelos são 
entregues aos programadores para que eles desenvolvam o software conforme projetado. 
Erros introduzidos na definição de um sistema repercutem negativamente em todas 
as etapas posteriores do seu desenvolvimento (isso está ilustrado muito bem na Figura 1.1) 
e tem custo maior de correção. Daí a importância de se conseguir a participação efetiva de 
clientes e desenvolvedores, logo no início do processo. 
[O sistema Restaurante] 
Suponha que você foi contratado para desenvolver um sistema. O que você deve fazer em 
primeiro lugar? 
O primeiríssimo passo no desenvolvimento de qualquer sistema, é o levantamento 
das necessidades que os futuros usuários do sistema esperam ver atendidas – ou seja, é 
preciso levantar os requisitos do sistema. Um bom ponto de partida é entrevistar as pessoas 
que usarão o sistema. No caso do sistema para o restaurante, poderiam ser feitas entrevistas 
com o dono do restaurante, com o gerente do restaurante, com a pessoa que fica no caixa, 
com os garçons e até com alguns clientes habituais. O resultado dessas entrevistas seria 
uma série de anotações como as mostradas Figura 1.2, que servirão de base para a 
modelagem do sistema: 
Modelagem de Sistemas Capítulo 1: Introdução 
 
3 
 
Resumo descritivo do sistema Restaurante 
Deseja-se um sistema para o controle do funcionamento do restaurante. O Caixa do 
restaurante deverá, a cada nova refeição, registrar no sistema os pratos e as bebidas 
solicitadas pelo cliente. Com isso, o Caixa poderá emitir a notinha (ticket) no encerramento 
da refeição, a qual é entregue pelo garçom ao cliente, para que o mesmo possa conferir e 
efetuar o pagamento da refeição. Essa notinha deverá conter o número da mesa onde a 
refeição foi servida, as quantidades e valores de tudo o que foi consumido, e o total a 
pagar. 
Pode acontecer o caso em que o cliente cancela a refeição, antes de ela ter sido 
tomada. Neste caso, o Caixa registra isso no sistema. 
O restaurante possui, dentre todos os clientes, alguns habituais, ou seja, que 
regularmente tomam refeições no restaurante. O sistema deverá manter um registro dos 
clientes habituais. É da responsabilidade do gerente do restaurante eleger e registrar no 
sistema os clientes habituais. A esses clientes é permitida a pendura das notinhas (para 
pagamento posterior  no final do mês, por exemplo), que deve ser registrada no sistema 
pelo Caixa. As notinhas dos clientes habituais devem conter o nome e o telefone do cliente. 
O Caixa é quem registra no sistema o pagamento de uma notinha em aberto (ainda 
não paga ou pendurada). O sistema deverá auxiliar o Caixa computando o valor do troco a 
ser devolvido ao cliente. O restaurante só aceita pagamento em dinheiro. 
O gerente deverá manter um cadastro dos itens de consumo (bebidas e pratos) 
servidos no restaurante, indicando seu preço unitário e sua disponibilidade atual (se o prato 
ou bebida pode ser servido). Além disso, será importante que o gerente possa consultar no 
sistema e repassar ao dono do restaurante, as seguintes informações: 
 O consumo (quantidade de cada prato ou bebida) em um dia de funcionamento do 
restaurante; essas informações ajudarão o gerente a planejar a reposição de 
ingredientes na cozinha do restaurante. 
 A receita (valor monetário) obtida entre duas datas, pelo pagamento de refeições 
nesse período. 
 Informações sobre as penduras (nome do cliente,telefone, valor pendurado, data da 
pendura), bem como o valor total pendurado, entre duas datas. Com isso, o gerente 
poderá efetuar a cobrança das penduras mais antigas, que já deveriam ter sido pagas. 
O restaurante serve, em média, 250 refeições por dia. O restaurante possui, 
atualmente, 30 mesas, mas esse número poderá variar. 
Figura 1.2: Requisitos iniciais do Sistema Restaurante 
A partir desse levantamento inicial dos requisitos do sistema, pode-se analisar e 
propor uma organização e estrutura adequadas para o sistema, que atenda esses requisitos. 
É ai que os modelos entram: eles nos ajudam a planejar e estruturar todas as partes do 
sistema a ser construído. 
O que são modelos? 
Para construir uma casa, primeiro se faz a planta baixa da mesma. A planta baixa vai 
mostrar quantos cômodos a casa tem, de que tipo eles são (quarto, sala, banheiro, ...), como 
eles estão dispostos, como se comunicam, onde estão posicionadas as portas e janelas, etc. 
Trata-se de um modelo da casa; ou seja, não é a casa em si, mas apenas uma representação 
abstrata da mesma. O termo abstração está na essência de qualquer modelo, pois toda 
Modelagem de Sistemas Capítulo 1: Introdução 
 
4 
 
representação (por definição) mostra apenas uma parte das propriedades ou detalhes 
daquilo que representa, ou seja, abstrai muitos detalhes do objeto modelado. É o caso da 
planta baixa da casa, que embora inclua informações importantes sobre a mesma, não 
inclui outras também relevantes, como por exemplo, os materiais a serem utilizados nas 
paredes, pisos, portas e janelas. 
Para o engenheiro que vai construir a casa, ter em mãos somente a planta baixa é 
insuficiente para executar a obra. Ele precisa saber mais detalhes sobre ela. Muito antes de 
construir as paredes, ele deverá se preocupar com a posição, tamanho e composição das 
sapatas de fundação, pilares e vigas que sustentarão a casa. Logo, vemos que serão 
necessários outros modelos para complementar a informações representadas na planta 
baixa. Entre esses modelos, podemos citar a planta de estrutura – responsável por 
descrever (abstratamente) os elementos estruturais da casa, a planta de fachada – que 
fornece uma visão de como será a aparência da casa por fora, a planta elétrica – que 
apresenta todas as informações necessárias à construção da rede elétrica da casa, a planta 
hidráulica, etc. 
Mas porque não colocar tudo em uma única planta e evitar a manipulação de várias 
delas? Simplesmente porque cada planta é utilizada (lida) por um tipo de profissional 
diferente, em momentos diferentes. Por exemplo, para o futuro morador da casa, interessa 
conhecer, principalmente, a disposição e tamanho dos espaços que compõem o interior da 
casa (planta baixa) e como ela será vista por fora (planta de fachada). A menos que seja 
engenheiro, ele dificilmente se interessará (ou compreenderá) a representação dos detalhes 
da estrutura da casa (planta de estrutura). Além disso, uma única planta que contivesse 
todas as informações necessárias à execução da obra tenderia a ser muito complexa e, 
consequentemente, difícil de ser lida e compreendida. 
Resumindo... É comum, nas diversas áreas do conhecimento, representar um objeto 
por um conjunto de visões ou modelos complementares e consistentes entre si. Dois 
modelos são consistentes entre si quando um não contradiz o outro. Na Ciência da 
Computação não é diferente. Os sistemas são materializados a partir de diversos modelos 
que se complementam mutuamente e são consistentes uns com os outros. 
Linguagens x Modelos 
Vimos que modelos são representações ou descrições abstratas de alguma coisa que 
precisamos estudar, compreender e/ou construir. E, para descrever algo, sempre temos de 
lançar mão de uma linguagem. Nossa linguagem natural, o Português, é uma possibilidade. 
Entretanto, para construirmos modelos técnicos, como os empregados em engenharia em 
geral, e na Engenharia de Software em particular, normalmente se utiliza uma linguagem 
especializada, ou seja, mais restrita, com símbolos e regras específicas para o universo de 
discurso da área. Por exemplo, para descrever uma casa, devemos falar de quartos, salas, 
jardins, janelas, portas, vigas, pilares, etc. Normalmente, não precisamos nos referir a 
coisas como carros, livros, laranjas, etc. Por isso, a Engenharia Civil emprega uma 
linguagem especializada, que possui símbolos especiais pré-definidos para representar as 
coisas do seu universo de discurso. A Figura 1.3 mostra a planta baixa de uma residência e, 
em destaque, o símbolo utilizado para representar uma janela da mesma. 
O exemplo da Figura 1.3 evidencia outra característica das linguagens utilizadas nas 
engenharias: são linguagens gráficas, ou seja, que utilizam principalmente símbolos 
gráficos no lugar de textuais. O Português, como qualquer outra linguagem natural, é 
textual, ou seja, os símbolos utilizados são símbolos textuais. Por exemplo, se queremos 
descrever uma casa em Português, utilizamos os símbolos “casa”, “quarto”, “janela”, etc. 
Modelagem de Sistemas Capítulo 1: Introdução 
 
5 
 
Vemos, portanto, que as engenharias levaram ao pé da letra um conhecido provérbio: “uma 
figura vale mais do que mil palavras”. 
 
Figura 1.3: Planta baixa (modelo) de uma residência destacando uma janela 
O paradigma
2
 OO 
Uma linguagem específica para modelar sistemas computacionais deve focar o universo 
das coisas que precisam ser consideradas na descrição desses sistemas. Na década de 1970, 
conceitos tais como fluxos e depósitos (ou arquivos) de dados, processos, rotinas, módulos, 
subsistemas, etc., eram quase sempre empregados nos modelos. Posteriormente, na década 
de 1980, com o surgimento da programação orientada a objetos (POO), logo amplamente 
adotada pela academia e pela indústria de software, passou-se a falar de objetos, classes, 
atributos, métodos, mensagens, pacotes, etc. Na POO, os programas de computador são 
organizados como um conjunto de (tipos ou classes) de objetos que se comunicam 
trocando mensagens. Esses objetos possuem atributos (dados) que podem ser consultados 
ou alterados, e métodos (operações) que podem ser executados, em resposta às mensagens 
enviadas de um objeto para outro. 
Uma das consequências importantes dessa mudança na forma de programar foi a 
revisão dos modelos que, até então, eram utilizados na modelagem de sistemas 
computacionais. Inicialmente, diversos autores propuseram, cada um, o seu próprio 
conjunto de modelos orientados a objetos (modelos OO). Mas essa diversidade de 
propostas exigia dos profissionais mais um passo antes de começar a desenvolver um 
sistema: a escolha criteriosa do conjunto mais adequado de modelos. Além disso, 
dificultava o compartilhamento dos modelos entre equipes acostumadas a trabalhar com 
modelos distintos. 
 
 
2
 Conjunto de ideias que rompe com um estado de coisas vigente e fundamenta um novo caminho para o 
desenvolvimento científico ou tecnológico. 
Modelagem de Sistemas Capítulo 1: Introdução 
 
6 
 
UML 
Em 1996, três dos principais proponentes de modelos OO se juntaram para propor um 
conjunto unificado de modelos que pudesse ser adotado por todos – ou seja, um padrão de 
modelagem OO, a ser compartilhado por todos os desenvolvedores de software. Esse 
padrão deu certo e passou a ser conhecido por UML – Unified Modeling Language, ou 
linguagem de modelagem unificada. A UML é uma linguagem de modelagem 
eminentemente gráfica, sempre presente nos currículos dos cursos de graduação em 
computação, e muito utilizada na indústria de software, razões pelas quais, será descrita em 
detalhe nos próximos capítulos. 
A UMLé uma linguagem para especificar, descrever e representar os artefatos de um 
sistema, especialmente sistemas que envolvem uma componente intensiva de software. Em 
outras palavras, é uma linguagem para descrever modelos de sistemas e, em especial, 
sistemas computacionais. 
A UML é padronizada mundialmente pela OMG (Object Management Group)
3
, que 
se encarrega de mantê-la evoluindo com base na experiência e necessidades da 
comunidade de usuários, que inclui a indústria, universidades, governo, especialistas, etc. 
A UML pode ser utilizada ao longo de todas as etapas do desenvolvimento de um 
sistema de software: modelagem de negócio, requisitos de software, análise e projeto. Ela 
abrange as mais diversas áreas de aplicação, tais como administração, engenharia, 
medicina, etc. 
[Diagramas da UML] 
Todos os modelos em UML tem um forte componente gráfico, já que a linguagem define 
diversos diagramas, divididos em três categorias: diagramas estruturais, diagramas 
comportamentais e, como uma subcategoria dessa última, os diagramas de interação. A 
Figura 1.4 apresenta o conjunto de diagramas da UML. 
 
Figura 1.4: Diagramas da UML 2.4 
 
 
3
 http://www.omg.org 
Modelagem de Sistemas Capítulo 1: Introdução 
 
7 
 
Os diagramas estruturais (de classes, de objetos, de pacotes, de estrutura composta, 
de componentes, de implantação e de perfil) definem os elementos do sistema e suas inter-
relações estruturais. São também chamados de diagramas estáticos, pois eles representam 
visões estáticas do sistema, ou seja, visões que independem do transcurso do tempo. Ou 
seja, a variável tempo não é considerada na elaboração dos diagramas estruturais. 
Dos diagramas estruturais, o mais utilizado é, de longe, o diagrama de classes. Por 
isso, nos concentraremos no estudo dele. Os demais diagramas estruturais podem ser 
facilmente encontrados na literatura sobre UML e, em particular, na bibliografia indicada 
no final deste material. 
Os diagramas comportamentais incluem o diagrama de casos de uso, de atividade, 
de estados e, dentro da subcategoria dos diagramas de interação, o diagrama de 
sequência, de comunicação, de temporização e o de panorama de interação. São também 
conhecidos como diagramas dinâmicos, pois apresentam visões dinâmicas do sistema, ou 
seja, visões que levam em conta a passagem do tempo (variável tempo). 
Dos diagramas comportamentais, os mais utilizados são o diagrama de casos de uso, 
de estados, de atividade, de sequência e de comunicação. Por isso, esses são os diagramas 
tratados neste material de estudo. 
[Ferramentas UML] 
Graças à padronização da UML pela OMG e a grande aceitação que essa linguagem teve e 
tem, muitos são os fabricantes de software que desenvolveram ferramentas computacionais 
para apoiar a modelagem com UML. Isso é muito importante pois, como a UML é uma 
linguagem eminentemente gráfica e normalmente os modelos passam por diversas versões 
antes de atingirem um grau de perfeição aceitável, a elaboração a mão dos modelos fica 
impraticável. 
Existem diversas ferramentas de apoio à elaboração de modelos UML, algumas 
pagas e outras gratuitas. Por exemplo, os modelos apresentados neste material de estudo 
foram desenvolvidos utilizando a ferramenta Astah, na versão gratuita, denominada versão 
Community. Essa ferramenta pode ser encontrada na web. Para utilizá-la basta fazer o 
download do arquivo de instalação e executá-lo. 
[Organização deste material] 
O restante deste material está organizado em mais seis capítulos, dedicados aos principais 
modelos da UML: Capítulo 2 – Modelo de Casos de Uso; Capítulo 3 – Diagrama de 
Classes de Objetos; Capítulo 4 – Diagrama de Estados; Capítulo 5 – Diagrama de 
Sequência; Capítulo 6 – Diagrama de Colaboração; e Capítulo 7 – Diagrama de Atividade. 
Modelagem de Sistemas Capítulo 2: Modelo de Casos de Uso 
 
8 
 
2. Modelo de Casos de Uso 
2.1. Introdução 
Nosso objetivo neste tópico é estudar o modelo de casos de uso (ou, abreviadamente, 
modelo de UCs – do inglês Use Cases) e aprender a utilizá-lo para o levantamento e 
especificação dos requisitos de um sistema de software. 
Um caso de uso (UC) de um sistema, como o próprio nome diz, é uma forma de se 
usar o sistema com o objetivo de realizar algo, segundo o ponto de vista de um usuário do 
sistema. 
A importância desse modelo reside no fato de que ele é, normalmente, o primeiro a 
ser elaborado quando se deseja desenvolver um sistema, servindo de base para os demais 
modelos posteriores. Um modelo de UCs bem feito é meio caminho andado no sentido de 
se ter um bom projeto do sistema a desenvolver (o contrário também é verdade!). Portanto, 
que tal se empenhar ao máximo em aprendê-lo bem? 
[Para que serve] 
O modelo de casos de uso serve para especificar os requisitos funcionais de um sistema, ou 
seja, ele especifica: 
 O que o sistema deve fazer; 
 Que funções os atores (usuários) poderão executar ao utilizar o sistema (por isso o 
nome “casos de uso”). 
Pesquisa: a) Defina requisitos funcionais; b) Que outros tipos de requisitos existem? 
Saiba mais: Casos de uso não se aplicam apenas a sistemas de software, mas também servem para 
descrever um negócio, um equipamento, etc. 
[Composição do modelo] 
Um modelo de UCs é composto de, pelo menos, duas partes: o diagrama de UCs (DUC) e 
o conjunto das descrições dos UCs que aparecem no diagrama. A Figura 2.1 apresenta um 
exemplo de diagrama de UCs simplificado, para o funcionamento do sistema de um 
telefone celular. 
Modelagem de Sistemas Capítulo 2: Modelo de Casos de Uso 
 
9 
 
2.2. Diagrama de UCs 
 
Figura 2.1: Exemplo de diagrama de casos de uso 
O diagrama da Figura 2.1 evidencia os principais elementos gráficos e textuais 
utilizados na elaboração do DUC: 
 Atores: Designam papéis de pessoas ou outros sistemas que interagem com o sistema 
que está sendo modelado. No caso do sistema Celular, temos dois atores – o ator 
Usuário, que representa uma pessoa no papel de quem usa o celular e o ator Rede, 
que representa o sistema da operadora do celular. São atores porque interagem 
diretamente (trocando sinais e/ou informações) com o sistema Celular. 
 Casos de uso: O diagrama contém três UCs – Efetuar chamada, Receber chamada e 
Usar a agenda. Cada UC representa um objetivo a ser alcançado por um ator ao 
utilizar o sistema. 
 Associação de comunicação: É representada por uma linha que une o ator ao UC, 
significando que o ator interage (ou se comunica) com o sistema para realizar aquele 
UC. 
 Fronteira do sistema (com o seu ambiente): É representada pelo retângulo que 
envolve todos os UCs do sistema. O que está dentro do retângulo (os UCs) faz parte 
do sistema, e o que está fora (os atores), constitui o ambiente do sistema. Apresenta, 
no canto superior esquerdo o nome do sistema. 
[UC-Lab1: Atores e stakeholders] 
Identifique os atores do sistema Restaurante, com base na descrição dos requisitos desse 
sistema, apresentada na Figura 1.2. 
Lembre-se, atores são pessoas ou sistemas que interagem diretamente com o sistema 
a ser construído. Por exemplo, podemos dizer que (a pessoa no papel de) Caixa é ator do 
sistema Restaurante, pois ele vai usar diretamente o sistema para realizar diversas funções, 
tais como registrar pedidos, emitir notinhas, etc. E o dono do restaurante? A descrição 
inicial do sistema não indica qualquer ação direta dessa pessoa no sistema. Se esse for 
realmente o caso, então o dono não é um ator e, portanto, não aparecerá no diagrama de 
UCs do sistema. 
Modelagem de Sistemas Capítulo 2: Modelo de Casos de Uso 
 
10 
 
Saiba mais... Se o donodo restaurante não é um ator, o que é então? Resposta: é um stakeholder 
(pronuncia-se “isteiquirrolder”). Esse é um termo em inglês para designar aquelas pessoas que, 
embora não interajam diretamente com o sistema, utilizam ou são afetadas, de alguma forma, pelos 
resultados produzidos por ele. Portanto, devemos incluir os stakeholders também entre as pessoas 
entrevistadas para o levantamento de requisitos do sistema. 
[UC-Lab2: DUC] 
Construa um diagrama de UCs para o sistema Restaurante, com base na descrição dos 
requisitos desse sistema (Figura 1.2) e considerando os atores identificados no laboratório 
anterior (UC-Lab1). 
Lembre-se que os UCs de um sistema são os grandes objetivos que os atores têm ao 
utilizar o sistema. No caso do sistema Restaurante, o ator Caixa vai querer usar o sistema 
para registrar um pedido de refeição. Em outro momento, o mesmo ator utilizará o sistema 
para registrar o pagamento da refeição. Portanto, podemos incluir no diagrama de UCs 
desse sistema o UC “Registrar pedido” e o UC “Pagar a nota”, certo? Que outros objetivos 
o ator Caixa teria ao utilizar o sistema? E os outros atores do sistema? 
Observação: Sempre comece o nome do UC com um verbo no infinitivo (como 
Registrar pedido). Essa padronização é adequada, pois reforça a ideia de que UCs são 
funcionalidades desempenhadas com o uso do sistema. 
2.3. Descrição dos UCs 
Após a identificação dos atores e UCs, e a elaboração do DUC do sistema, deve-se 
descrever os UCs. Existem diferentes níveis de detalhamento para se descrever um UC. 
Para cada UC, a escolha do nível de detalhamento mais adequado depende da 
complexidade do UC e deve resultar de um compromisso entre o esforço requerido para se 
descrever o UC naquele nível e a precisão/clareza que a descrição resultante proporciona 
aos seus leitores-alvo – atores, stakeholders e desenvolvedores. A Figura 2.2 apresenta os 
níveis de detalhamento mais comumente utilizados na descrição de UCs, além de indicar 
uma ordem de utilização desses níveis: primeiramente se faz um sumário do UC, para 
depois, em uma segunda etapa e caso seja necessário, descrever o fluxo de eventos do UC. 
 
Figura 2.2: Níveis mais comuns de detalhamento na descrição de UCs 
Modelagem de Sistemas Capítulo 2: Modelo de Casos de Uso 
 
11 
 
Sumário 
O mais alto nível de descrição de um UC é denominado Sumário. Trata-se de uma breve
4
 
descrição textual de como alcançar o objetivo do UC, através da descrição do uso do 
sistema pelos atores envolvidos no UC. Por exemplo, considere o UC Abrir conta, dentro 
do contexto de um sistema bancário. O sumário desse UC poderia ser: 
“O funcionário consulta o Cliente no sistema, pelo CPF. Se necessário, atualiza os 
dados dele. Após o Cliente informar uma senha, a conta é aberta (criada) pelo Sistema. O 
Funcionário verifica com o Cliente o valor a depositar, obtém esse valor e efetua o 
depósito dele na conta que acabou de ser criada. Por fim, o Sistema emite o cartão da nova 
conta.” 
Observe que esse sumário descreve como abrir uma conta bancária (objetivo do ator 
Funcionário), através da interação entre o sistema e os atores Funcionário e Cliente. 
Considere agora o sistema Restaurante. Possíveis sumários para os UCs Abrir pedido 
e Pagar a nota são: 
Sumário do UC Abrir pedido: 
“O Caixa informa os dados para a abertura do pedido (o número da mesa e os itens 
pedidos, com respectivas quantidades). Uma vez concluída essa entrada de dados, o 
sistema registra o novo pedido em seus arquivos.” 
Sumário do UC Pagar a nota: 
 “O Caixa identifica o pedido a pagar. O sistema exibe o total a pagar e solicita ao 
Caixa que informe a quantia entregue pelo cliente para o pagamento. O Caixa informa essa 
quantia. Se ela for maior do que a quantia a pagar, o sistema calcula e apresenta o troco. 
Após a confirmação do Caixa de que o pagamento foi efetuado, o sistema registra que a 
nota foi paga.” 
[UC-Lab3: Sumário dos UCs] 
Faça o sumário dos demais UCs do sistema Restaurante. 
Fluxo de Eventos 
Para uma descrição mais detalhada de um UC, pode-se utilizar o segundo nível de 
detalhamento, denominado fluxos de eventos. Evento é todo acontecimento gerado por um 
ator ou pelo sistema. Consequentemente, qualquer evento tem como atributo ou 
propriedade a posição da sua ocorrência no tempo, em relação aos demais eventos. O fluxo 
de eventos mostra onde cada evento, de um conjunto de eventos, está posicionado no 
tempo, em relação aos demais eventos do conjunto. 
[Exemplo: UC Pagar a nota (Sistema Restaurante)] 
Para exemplificar fluxo de eventos, considere novamente o UC Pagar a nota, cujo sumário 
está reproduzido abaixo: 
“O Caixa identifica o pedido a pagar. O sistema exibe o total a pagar e solicita ao 
Caixa que informe a quantia entregue pelo cliente para o pagamento. O Caixa informa essa 
quantia. Se ela for maior do que a quantia a pagar, o sistema calcula e apresenta o troco. 
 
 
4
 Normalmente, apenas um parágrafo. 
Modelagem de Sistemas Capítulo 2: Modelo de Casos de Uso 
 
12 
 
Após a confirmação do Caixa de que o pagamento foi efetuado, o sistema registra que a 
nota foi paga.” 
Nesse UC, podemos identificar diversos eventos gerados pelo ator Caixa, tais como: 
 Identifica o pedido a pagar; 
 Informa a quantia (entregue pelo Cliente para pagamento do pedido); 
 Confirma que o pagamento foi efetuado; 
Por sua vez, o sistema gera os seguintes eventos: 
 Exibe o total a pagar; 
 Solicita ao Caixa que informe a quantia entregue pelo cliente para o pagamento; 
 Calcula e apresenta o troco; 
 Registra o pagamento em seus arquivos; 
A descrição do fluxo de eventos desse UC colocaria cada evento na sua posição 
correta no tempo, em relação aos demais: 
1. O Caixa identifica o pedido a pagar; 
2. O sistema exibe o total a pagar; 
3. O sistema solicita ao Caixa que informe a quantia entregue pelo cliente para o 
pagamento; 
4. O Caixa informa a quantia (entregue pelo Cliente); 
5. O sistema calcula e apresenta o troco; 
6. O Caixa confirma que o pagamento foi efetuado; 
7. O sistema registra o pagamento em seus arquivos; 
8. O sistema informa ao Caixa a conclusão com sucesso da operação. 
Figura 2.3: Fluxo de eventos do UC Pagar a nota (Sistema Restaurante) 
[Exemplo: UC Abrir conta (sistema bancário)] 
Outro exemplo é a descrição do fluxo de eventos do UC Abrir conta, cujo sumário foi 
apresentado anteriormente nessa seção: 
1. O Sistema pede o CPF do cliente; 
2. O Funcionário informa o CPF; 
3. O Sistema apresenta os dados cadastrais do Cliente e solicita que o Funcionário os 
atualize, se necessário; 
4. O Gerente atualiza o cadastro do Cliente; 
5. O Sistema pede uma senha de acesso para o Cliente; 
6. O Cliente informa a senha; 
7. O Sistema abre a conta; 
8. O Sistema solicita o valor do depósito inicial; 
9. O Gerente informa o valor e confirma seu recebimento; 
10. O Sistema registra o depósito e emite o cartão da nova conta. 
Figura 2.4: Fluxo de eventos do UC Abrir conta (sistema bancário) 
[Fluxo de eventos com situações alternativas] 
De certa maneira (menos estruturada e, normalmente, menos detalhada), o sumário de um 
UC também dá uma ideia dos eventos gerados pelos atores e pelo sistema, bem como da 
ordem em que os eventos ocorrem. Entretanto, em uma descrição de fluxo de eventos, 
além dessa informação estar melhor estruturada e mais detalhada, também é possível 
Modelagem de Sistemas Capítulo 2: Modelo de Casos de Uso 
 
13 
 
destacar situações alternativas que representam comportamento de caráter opcional, 
excepcional ou alternativo. Por exemplo, considere o fluxo de eventos do UC Pagar a nota 
(Sistema Restaurante– Figura 2.3). E se o cliente entregar (e o Caixa informar ao sistema) 
uma quantia inferior ao valor devido para pagamento da refeição? Como o sistema deveria 
se comportar? Veja na Figura 2.5, uma sugestão de como incluir o tratamento dessa 
situação no fluxo de eventos do UC. 
1. O Caixa identifica o pedido a pagar; 
2. O sistema exibe o total a pagar; 
3. O sistema solicita ao Caixa que informe a quantia entregue pelo cliente para o 
pagamento; 
4. O Caixa informa a quantia (entregue pelo Cliente); 
5. O sistema calcula e apresenta o troco; 
6. O Caixa confirma que o pagamento foi efetuado; 
7. O sistema registra o pagamento em seus arquivos; 
8. O sistema informa ao Caixa a conclusão com sucesso da operação. 
Situações Alternativas: 
A1. Quantia dada para pagamento da nota da refeição é inferior ao valor devido: O 
sistema deve informar ao Caixa essa situação e permitir que ele entre com outra 
quantia ou finalize o UC. 
Figura 2.5: Fluxo de eventos com alternativa (UC Pagar a nota) 
O exemplo acima mostra a descrição do fluxo de eventos de um UC com apenas uma 
situação alternativa. Mas essa não é a regra geral. A seguir, é apresentada uma lista de 
situações alternativas que poderiam estar previstas na descrição do fluxo de eventos do UC 
Retirar dinheiro, de um sistema de terminal de autoatendimento bancário. 
A1. Cartão não pode ser identificado; 
A2. Cliente não pode ser identificado; 
A3. Cliente deseja retirar quantia distinta daquelas pré-definidas; 
A4. Saldo na conta do Cliente insuficiente para retirar a quantia solicitada; 
A5. Limite diário de retirada ultrapassado; 
A6. Link de comunicação com o Sistema do Banco está fora do ar; 
A7. Cartão roubado - o cartão está na lista negra; 
A8. O terminal não tem dinheiro suficiente; 
A9. O cartão agarrou no leitor de cartões do terminal; 
[Cenários de um UC] 
A existência de situações alternativas na descrição de um UC mostra que, a cada realização 
de um UC, uma sequência diferente de eventos pode ocorrer. Por exemplo, no UC anterior 
(Retirar dinheiro), se a quantia solicitada para retirada for superior ao limite diário, então 
em vez de disponibilizar o dinheiro ao usuário, o terminal bancário emitirá uma mensagem 
para esclarecer a situação e permitirá que o usuário escolha outra quantia. Cada sequência 
específica de eventos ocorridos durante a realização de um UC é um cenário do UC. 
Portanto, um UC pode expressar um conjunto de cenários. 
Saiba mais... Existe ainda uma forma mais detalhada de se descrever o fluxo de eventos de um UC, 
denominada fluxo completo de eventos, em contraposição àquela que foi vista nesta seção, que 
normalmente é denominada de resumo (outline, em inglês) de eventos. Entretanto, para a maioria 
dos UCs, o sumário ou a fluxo resumido de eventos é mais do que suficiente. 
Modelagem de Sistemas Capítulo 2: Modelo de Casos de Uso 
 
14 
 
[UC-Lab4: Fluxo de eventos dos UCs] 
Elabore os fluxos (resumidos) de eventos para os UCs do sistema Restaurante, incluindo o 
tratamento de situações alternativas, se houver. 
2.4. Relacionamentos entre UCs 
Vimos que o diagrama de UCs mostra o relacionamento de comunicação entre os atores e 
os UCs, através de linhas que unem cada ator aos UCs com os quais ele troca sinais e 
informações. Agora vamos ver que os UCs também podem se relacionar. Abaixo estão 
listados os três tipos de relacionamentos entre UCs, sendo os dois primeiros os mais 
comuns: 
 Relacionamento de inclusão (um UC inclui o outro); 
 Relacionamento de extensão (um UC estende o outro); e 
 Relacionamento de generalização (um UC generaliza o outro). 
Inclusão 
O relacionamento de inclusão (include, em inglês) entre dois UCs expressa que o 
comportamento (fluxo de eventos) de um UC inclui, incondicionalmente, o comportamento 
(fluxo de eventos) do outro UC. Por exemplo, no diagrama da Figura 2.6, o 
(comportamento descrito no) UC Emitir histórico escolar sempre inclui, em algum ponto 
do seu fluxo de eventos, o (comportamento descrito no) UC Efetuar login. Isso é expresso 
através da seta tracejada partindo do UC que inclui e chegando no UC que é incluído. 
 
Figura 2.6: Representação do relacionamento de inclusão entre UCs 
Extensão 
O relacionamento de extensão (extend, em inglês) entre dois UCs expressa que o 
comportamento (fluxo de eventos) de um UC estende, condicionalmente, o comportamento 
(fluxo de eventos) do outro UC. Por exemplo, no contexto de um sistema de 
videolocadora, o diagrama da Figura 2.7 mostra que o (comportamento descrito no) UC 
Registrar pagamento estende condicionalmente o (comportamento descrito no) UC Fazer 
empréstimo, assim como também estende (condicionalmente) o UC Fazer devolução. Isso 
porque, quando se toma um filme emprestado, o pagamento do empréstimo pode ou não 
ser feito no ato do empréstimo (UC Fazer empréstimo); caso não seja feito, o empréstimo 
deve ser pago no momento em que ele é devolvido (UC Devolver empréstimo) – a decisão 
é do cliente da videolocadora. Consequentemente, os relacionamentos do UC Registrar 
pagamento com os outros dois UCs são do tipo extend; só seriam include se Registrar 
Modelagem de Sistemas Capítulo 2: Modelo de Casos de Uso 
 
15 
 
pagamento devesse ser realizado sempre que Fazer empréstimo e Fazer devolução fossem 
realizados. O relacionamento extend é expresso através de uma seta tracejada partindo do 
UC que estende e chegando ao UC estendido (ou seja, no sentido inverso de um include). 
 
Figura 2.7: Representação do relacionamento de extensão entre UCs 
Saiba mais... O diagrama da Figura 2.7 exibe uma novidade – o relacionamento de herança de 
comportamento entre atores
5
. Herança de comportamento, no contexto do modelo de UCs, significa 
herança de UCs, ou seja, um ator herda a capacidade de realizar os UCs de outro ator. Esse 
relacionamento é desenhado como uma seta contínua e com a ponta fechada, partindo do ator que 
herda o comportamento e chegando no outro ator, aquele que fornece o comportamento herdado. 
Portanto, pela Figura 2.7, podemos dizer que o Cliente online pode realizar todos os UCs ligados 
diretamente a ele (no caso, apenas o UC Reservar filme) e mais os UCs herdados do ator Usuário 
online (UC Consultar acervo). Por sua vez, Balconista pode realizar todos os UCs do sistema, 
graças ao relacionamento de herança entre atores. 
Considerações sobre Include e Extend 
Uma coisa a se ter sempre em mente é que os UCs incluídos em outros UCs, ou aqueles 
que estendem outros UCs, devem poder ser ativados independentemente desses outros 
(melhor dizendo: mesmo que esses outros não estejam sendo realizados). Os UCs das 
Figuras 2.6 e 2.7, que são incluídos em outros (Efetuar login, Consultar acervo), ou que 
estendem outros (Registrar pagamento, Informar filme disponível) satisfazem essa 
condição. Por exemplo, o UC Consultar acervo (Figura 2.7) pode ser ativado (realizado) 
mesmo sem a realização do UC Reservar filme, que o inclui; igualmente, o UC Registrar 
pagamento (Figura 2.7) pode ser ativado mesmo que os UCs Fazer empréstimo e Fazer 
devolução não estejam acontecendo (pois um cliente pode, a qualquer momento, entre o 
empréstimo e a devolução do filme, ir à videolocadora e efetuar o pagamento do filme). 
 
 
5
 Também conhecido como relacionamento de generalização/especialização entre atores. 
Modelagem de Sistemas Capítulo 2: Modelo de Casos de Uso 
 
16 
 
Essa observação é importante porque ela impede a utilização desses relacionamentos para 
fazer, no diagrama de UCs, a decomposição funcional do sistema – um erro frequente entre 
modeladores inexperientes. Essa condição pode ser parcialmente verificada graficamente
6: 
no diagrama, todos os UCs devem estar associados a, pelo menos, algum ator. 
Duas diferenças importantes entre os relacionamentos de inclusão e de extensão são: 
1. No relacionamento de inclusão, a seta aponta o UC cujo comportamento vai ser 
inserido no outro UC, enquanto que no relacionamento de extensão, a seta aponta o 
UC que recebe a inserção (de comportamento) do outro UC. 
2. O relacionamento de inclusão é incondicional, ou seja, sempre ocorrerá a inserção do 
comportamento do UC incluído, no UC que o inclui. Diferentemente, o 
relacionamento de extensão é condicional, ou seja, a inserção do comportamento do 
UC que estende, no UC que é estendido, depende de uma condição ser verdadeira. 
Portanto, a extensão modela comportamento opcional, alternativo ou de exceção. 
[Efeito do include e do extend sobre a descrição dos UCs] 
Você deve estar pensando: Que efeito a introdução (no diagrama de UCs) de um 
relacionamento de inclusão ou de extensão entre dois UCs tem sobre a descrição do fluxo 
de eventos desses UCs? 
A Figura 2.8 mostra que o UC A (aquele que recebe a inserção de comportamento) é 
o responsável por “chamar” o UC B. O fluxo de eventos do UC B (aquele que é incluído 
no UC A) não sofre qualquer alteração. 
 
Figura 2.8: Efeito de A includes B sobre o fluxo de eventos dos UCs A e B 
A Figura 2.9 mostra que o UC B (aquele que estende o comportamento) é o 
responsável por especificar duas coisas: 1ª) A condição que deve ser verdadeira para que a 
 
 
6
 Condição necessária, mas não suficiente, já que as associações entre atores e UCs não esclarecem se um 
ator ativa (inicia) um UC, ou apenas interage (se comunica) com ele. 
Modelagem de Sistemas Capítulo 2: Modelo de Casos de Uso 
 
17 
 
extensão (inserção) ocorra; e 2ª) O ponto do fluxo de eventos do UC A (ponto de extensão) 
em que deve ocorrer a inserção. 
Um ponto de extensão é um rótulo que marca um lugar dentro do fluxo de eventos de 
um UC, de forma que se possa referir a ele quando necessário – por exemplo, quando se 
tem de inserir comportamento naquele ponto do fluxo de eventos. Essa é a única alteração 
necessária no fluxo de eventos do UC A
7
. 
 
Figura 2.9: Efeito de A extends B sobre o fluxo de eventos dos UCs A e B 
O relacionamento de extensão entre UCs, por sua característica de afetar apenas a 
descrição do UC que estende (e não a do UC que é estendido)
8
, é mais adequado do que o 
relacionamento de inclusão como mecanismo de especificação de funcionalidades que são 
introduzidas em uma nova versão de um software pré-existente. Isso porque, nesse caso, 
essas funcionalidades são especificadas através de novos UCs que estendem os já 
existentes, evitando-se, assim, alterar esses últimos. 
Generalização 
Imagine a seguinte situação: Uma empresa planeja desenvolver e comercializar um sistema 
de contabilidade. Entretanto, como essa empresa buscará clientes nos diversos ramos de 
atividade – indústria, comércio e serviços, ela chegou à conclusão que precisará ter uma 
versão do sistema para cada ramo. As três versões do sistema terão muito em comum, se 
diferindo apenas em alguns pontos. Como organizar os UCs do sistema, de forma a refletir 
essa situação? 
 
 
7
 Caso o ponto de extensão ainda não exista. 
8
 Exceto pela introdução de um ponto de extensão, se necessário. 
Modelagem de Sistemas Capítulo 2: Modelo de Casos de Uso 
 
18 
 
Pesquisa: Essa situação exemplifica o conceito de família de sistemas. Procure saber mais sobre 
ele... 
Uma boa opção é lançar mão do relacionamento de generalização (generalization, 
em inglês) entre dois ou mais UCs, que expressa a relação entre um UC geral e os demais 
UCs cujas descrições de comportamento especializam o comportamento descrito no UC 
geral. Ou seja, o sistema da nossa empresa hipotética poderia ser modelado através 
diversos UC gerais descrevendo o comportamento comum (genérico) às três versões do 
sistema, e três outros UCs para cada UC geral (um para cada ramo de atividade), 
responsáveis por descrever o comportamento especializado para cada ramo. Cada UC geral 
estaria então ligado aos seus três UCs especializados, através do relacionamento de 
generalização (Figura 2.10). 
 
Figura 2.10: Representação do relacionamento de generalização entre UCs 
Algumas outras características do relacionamento de generalização entre UCs são: 
 O comportamento exibido na realização de um UC que especializa um UC geral não 
está todo descrito nele, mas resulta de se estender o UC geral com o comportamento 
descrito no UC especializado, em pontos de extensão existentes no fluxo de eventos 
do UC geral. Essa é uma vantagem do relacionamento de generalização: o 
comportamento genérico é fatorado no UC geral, e os UCs que o especializam 
contém apenas o comportamento específico a ser acrescentado ao comportamento 
geral. 
 O UC geral não tem, necessariamente, que ser completo ou poder ser executado, mas 
sim os UCs que o especializam. Este é o caso dos UCs gerais do sistema da nossa 
empresa hipotética, pois não faz sentido ter uma versão executável do sistema que 
incorpore apenas o comportamento comum aos três ramos de atividade (não haverá 
cliente interessado nela, certo?). Mas a Figura 2.11 exemplifica uma situação onde é 
razoável supor que tanto o UC geral quanto o UC especializado poderão ser 
executados. 
 
Figura 2.11: Exemplo de relacionamento generalização entre dois UCs 
Modelagem de Sistemas Capítulo 2: Modelo de Casos de Uso 
 
19 
 
[UC-Lab5: Relacionamentos entre UCs] 
Considere a seguinte descrição do comportamento para a abertura de uma conta bancária: 
“O funcionário consulta o Cliente no sistema, pelo CPF. Se necessário, atualiza os dados 
cadastrais dele. Após o Cliente informar uma senha, a conta é criada pelo Sistema. O 
Funcionário verifica com o Cliente o valor a depositar, obtém esse valor e efetua o 
depósito dele na conta que acabou de ser criada. Por fim, o Sistema emite o cartão da nova 
conta.” 
Em conformidade com a descrição acima, complete o diagrama abaixo introduzindo 
um relacionamento de inclusão e outro de extensão. 
 
Modelagem de Sistemas Capítulo 3: Diagrama de Classes de Objetos 
 
20 
 
3. Diagrama de Classes de Objetos 
3.1. Introdução 
Este capítulo apresenta outro modelo da UML: o Diagrama de Classes de Objetos (ou 
abreviadamente, Diagrama de Classes - DC). Ele é largamente utilizado, em conjunto com 
o Modelo de Casos de Uso, para modelar praticamente todo tipo de sistema. Normalmente, 
o DC é elaborado depois do modelo de UCs, embora isso não seja imprescindível. O mais 
importante é que os dois modelos não se contradigam, isto é, eles devem ser consistentes 
entre si. 
Assim como a planta estrutural de uma casa modela a estrutura da casa, ou seja, os 
elementos que garantem a sua sustentação, o DC modela a estrutura de um sistema – os 
elementos (classes, associações, atributos, operações) que possibilitam a realização do 
comportamento descrito nos UCs do sistema. Daí, sua grande importância. 
[Exemplo de DC] 
 
Figura 3.1: Exemplo de diagrama de classes de objetos 
A Figura 3.1 apresenta um exemplo de diagrama de classes. Nela, pode-se observar os 
principais elementos utilizados na construção desse diagrama: classes (tipos) de objetos, 
atributos e operações de classe, e associações entre classes. Uma leitura de parte desse 
diagrama seria: “Todo (objeto da classe) Carro possuirá (os atributos) modelo, placa e 
potência, e poderá ser solicitado a (executar as operações) imprimirProprietario( ) e 
imprimirDados( ). Além disso, todo (objeto daclasse) Carro estará ligado a um único 
(objeto da classe) Proprietário, enquanto que um (objeto da classe) Proprietário estará 
ligado a um ou mais objetos (da classe) Carro”. 
Modelagem de Sistemas Capítulo 3: Diagrama de Classes de Objetos 
 
21 
 
Um DC nos diz muita coisa sobre a estrutura e o comportamento do sistema que ele 
modela. A estrutura do sistema é definida pelas classes e seus atributos, e pelas associações 
entre as classes; ambos, atributos e associações, representam as informações que o sistema 
armazenará. Já o comportamento previsto nos UCs do sistema, esse deverá resultar da 
execução (possivelmente encadeada) de operações das classes. 
Classe  Objeto 
Como vimos no Capítulo 1, toda representação de alguma coisa, como por exemplo, uma 
pessoa, envolve abstração, ou seja, selecionar as propriedades das pessoas que são 
relevantes para o sistema a ser desenvolvido. Desde a adoção do paradigma da orientação a 
objetos, essas propriedades passaram a incluir, além de propriedades estáticas ou de estado 
(atributos), como por exemplo, nome, data de nascimento, sexo, estado civil, etc., também 
propriedades dinâmicas ou de comportamento (operações ou métodos), tais como nascer, 
casar, etc. Uma classe de objetos é a estrutura formada pelos atributos e operações 
selecionados para representar objetos de um mesmo tipo, no contexto de um dado sistema. 
A Figura 3.2 mostra a representação gráfica de uma possível classe (de objetos) Pessoa: é 
um retângulo dividido em três partes ou compartimentos: o compartimento de cima contém 
o nome da classe, o do meio, os atributos da classe e o inferior, as operações da classe. 
Observe que, juntamente com o nome de cada atributo ou operação, também pode ser 
especificado o tipo (de dados) do valor que o atributo pode receber ou que a operação 
retorna (void se a operação não retorna valor), e a visibilidade dos atributos e das 
operações: 
 “-“ : O atributo (ou operação) é privado(a), ou seja, só pode ser utilizado9 (invocada) 
pelas operações da própria classe; 
 “#”: O atributo (ou operação) é protegido(a), ou seja, só pode ser utilizado 
(invocada) pelas operações da própria classe ou pelas operações de uma subclasse 
dela; e 
 “+”: O atributo (ou operação) é público(a), ou seja, pode ser utilizado (invocada) 
pelas operações de qualquer classe do sistema. 
Em geral, os atributos devem ser privados, e as operações, públicas. Esse esquema de 
visibilidade cria um encapsulamento dos dados da classe, pois qualquer acesso a eles de 
fora da classe só pode ser feito através da invocação de alguma operação nela definida. O 
encapsulamento é importante porque mantém baixo o acoplamento entre as classes e, por 
consequência, o custo de se fazer modificações nas mesmas. Em outras palavras, se uma 
classe está encapsulada, uma modificação nela produz menor propagação de modificações 
em outras classes do sistema. 
A partir da classe Pessoa, pode-se criar (instanciar) objetos com valores específicos 
para os atributos da classe e com o mesmo comportamento invocável (operações) nela 
previsto. Portanto, uma classe funciona como um molde (modelo) para a criação de 
objetos similares – as instâncias ou exemplares da classe. A Figura 3.2 exibe um objeto 
criado a partir a classe Pessoa. 
 
 
9
 Para consultar ou alterar o seu valor. 
Modelagem de Sistemas Capítulo 3: Diagrama de Classes de Objetos 
 
22 
 
 
Figura 3.2: Uma classe (de objetos) Pessoa e um objeto dessa classe 
Todo objeto possui ainda outra característica que independe do seu estado (i.e., dos 
valores dos seus atributos): a sua identidade. Por exemplo, podemos distinguir duas folhas 
de papel A4, mesmo que tenham os mesmos valores dos atributos (identidade no espaço); 
também, se pintarmos uma folha de amarelo (ou seja, mudar um de seus atributos – a cor), 
ela continua sendo a mesma folha de papel (identidade no tempo). 
3.2. Associações entre classes 
Além das classes de um sistema, o DC também mostra as associações existentes entre elas. 
Essas associações são, em sua grande maioria, relações binárias, isto é, relacionam duas 
classes, e estão representadas por linhas que ligam as classes. 
Saiba mais... Também podem aparecer no DC associações ternárias, quaternárias, etc., embora isso 
seja pouco comum. Consulte a bibliografa do curso ou pesquise em sites da Internet se quiser saber 
mais sobre essas associações. 
As associações especificam como os objetos das classes associadas poderão estar 
ligados entre si. Por exemplo, se existe uma associação entre a classe A e a classe B, então 
poderão existir ligações entre os objetos da classe A e os objetos da classe B. Assim como 
um objeto é uma instância de uma classe, uma ligação é uma instância de uma associação. 
A Figura 3.3 apresenta uma associação de nome leciona, entre a classe Professor e a classe 
Curso, cujo significado é Professor leciona em Curso
10
. Portanto, objetos representando 
professores poderão estar ligados a objetos representando cursos, e cada ligação entre um 
objeto-professor e um objeto-curso indicará que o professor leciona naquele curso. Por 
exemplo, o professor p3 está ligado a (ou leciona em) dois cursos (c2 e c3), enquanto que o 
professor p1 só leciona em um curso (c1) e o professor p2 não leciona em nenhum curso. 
Quando representamos uma associação entre duas classes no DC, podemos 
especificar as multiplicidades de cada classe naquela associação, da maneira indicada na 
Figura 3.3. Nela, n e m especificam o número mínimo e máximo de objetos da classe 
Professor que um objeto da classe Curso pode estar ligado, enquanto p e q especificam o 
número mínimo e máximo de objetos da classe Curso que um objeto da classe Professor 
pode estar ligado. A propósito, quais seriam os valores de n, m, p e q na Figura 3.3? 
 
 
10
 Caso exista mais de uma associação entre um mesmo par de classes, elas devem ter nomes distintos (e, 
obviamente, significados distintos). 
Modelagem de Sistemas Capítulo 3: Diagrama de Classes de Objetos 
 
23 
 
 
Figura 3.3: Associação, ligações e multiplicidades 
As multiplicidades que mais aparecem nas associações são as apresentadas a seguir: 
 0..1 : no mínimo zero e no máximo um; 
 1..1 (ou, abreviadamente, 1): no mínimo um e no máximo um (ou: exatamente um); 
esta é a multiplicidade default, ou seja, aquela que vigora quando não se indica nada 
em uma extremidade da associação; 
 0..* (ou, abreviadamente *): no mínimo zero e no máximo vários; 
 1..* : no mínimo um e no máximo vários; 
Existem ainda outras formas de se especificar a multiplicidade, como por exemplo: 
3..5 (no mínimo três e no máximo cinco), ou 1, 3..5 (exatamente um, ou, no mínimo três e 
no máximo cinco). 
[DC-Lab1: Associações e suas multiplicidades (1)] 
Especifique as multiplicidades das associações mostradas na figura a seguir. 
 
[DC-Lab2: Associações e suas multiplicidades (2)] 
Qual das três associações a seguir é a correta? 
Modelagem de Sistemas Capítulo 3: Diagrama de Classes de Objetos 
 
24 
 
 
[DC-Lab3: Atributos x Associações] 
Considere o seguinte: 
 É errado incluir em uma classe um atributo que designa um objeto de outra classe 
presente no DC; o correto nesse caso é introduzir uma associação entre as duas 
classes, com o significado correspondente. 
 Entre um par de classes pode-se ter mais de uma associação (com nomes distintos). 
Com base nas duas observações acima, faça um DC para representar países e suas 
cidades, a capital de cada país, e os nomes dos países e das cidades. 
Associação reflexiva 
Umaassociação pode envolver apenas objetos de uma mesma classe, como mostrado na 
Figura 3.4. Esse tipo de associação recebe o nome de associação reflexiva. 
 
Figura 3.4: Associação reflexiva e papéis 
Em uma associação reflexiva, uma outra propriedade das associações se torna 
bastante útil: o papel (do objeto) de cada classe, na associação. Por exemplo, o DC da 
Figura 3.4 nos diz que, se existir uma ligação entre duas pessoas segundo a associação ter, 
uma delas estará no papel de pai e a outra no papel de filho. 
Classe de associação 
Uma associação também pode ter atributos e operações. Por exemplo, considere a 
associação matriculado entre objetos da classe Aluno e da classe Disciplina. A nota que é 
obtida por um determinado aluno em uma disciplina na qual está matriculado, não é 
atributo da classe Aluno nem da classe Disciplina, mas sim da associação entre elas (ou 
seja, a nota não descreve um aluno ou uma disciplina isoladamente, mas sim a associação 
do aluno com a disciplina). Nesse caso, a associação ganha status de classe – uma classe 
de associação, já que ela não apenas associa dois tipos de objetos, mas também representa 
ou descreve um novo tipo de objeto que possui estado (atributos) e comportamento 
Modelagem de Sistemas Capítulo 3: Diagrama de Classes de Objetos 
 
25 
 
(operações). A Figura 3.5 mostra como se desenha uma classe de associação no DC. A 
classe de associação recebe o mesmo nome da associação que a origina. Essa figura 
também mostra uma classe de associação derivada de uma associação reflexiva. 
Figura 3.5: Exemplos de classes de associação 
Agregação e Composição 
O que existe de diferente entre uma associação entre as classes Aluno e Disciplina e outra 
entre as classes Time e Jogador? Uma resposta razoável seria: um jogador é parte de um 
time, mas o mesmo não se pode dizer com relação à associação entre disciplina e aluno 
(uma disciplina não é parte de um aluno, nem um aluno é parte de uma disciplina). Esse 
tipo especial de associação que relaciona o todo a suas partes, com o significado de que o 
todo contém as (ou é constituído pelas) partes, recebe o nome de agregação. A Figura 3.6 
mostra dois exemplos de agregação e como diferenciar uma associação comum de uma 
agregação: colocando um losango na extremidade correspondente à classe que representa o 
“todo”. 
[Agregação] 
 
Figura 3.6: Exemplos de associações do tipo agregação 
[Composição] 
As situações modeladas na Figura 3.6 têm características em comum, mas também se 
diferem em alguns aspectos. Primeiramente, tanto um time é constituído por jogadores, 
quanto um pedido é constituído por itens de pedido (produtos, com suas quantidades e 
preços unitários). Entretanto, um jogador pode existir sem estar ligado a um time; por 
exemplo, um jogador de futebol com passe livre ou desempregado. Já um item de pedido 
não pode existir sem estar ligado a um pedido. Além disso, um mesmo jogador pode 
participar de mais de um time, como quando faz parte do time de um clube de futebol mas 
também do time da seleção brasileira, o que não acontece com um item de pedido, que só 
Modelagem de Sistemas Capítulo 3: Diagrama de Classes de Objetos 
 
26 
 
pode fazer parte de um único pedido. E mais: se um time for desfeito (deixar de existir), 
faz sentido que os jogadores continuem a existir, certo? Mas, e os itens de um pedido, se o 
pedido for apagado? Portanto, percebemos que as duas situações modeladas da mesma 
forma (através de agregação) na Figura 3.6 são, de fato, diferentes. Levando em conta isso, 
a UML definiu um tipo especial de agregação, denominado composição, que traduz as 
características de uma agregação mais forte, como é o caso da agregação entre Pedido e 
Item de pedido. A Figura 3.7 mostra exemplos de composição. Observe que, graficamente, 
uma composição se difere de uma agregação pelo preenchimento do losango com a cor 
preta. 
 
Figura 3.7: Exemplos de associações do tipo composição 
[Comparação entre Agregação e Composição] 
Outra característica tanto da agregação quanto da composição é que uma ação sobre 
o todo tende a se propagar nas partes. Por exemplo, se um time viaja, os jogadores também 
viajam. Entretanto, tem um tipo de ação que só se propaga na composição: apenas na 
composição, a eliminação do todo resulta, necessariamente, na eliminação das partes. Em 
outras palavras, enquanto na composição o tempo de vida dos objetos-parte é sempre no 
máximo igual ao tempo de vida do seu objeto-todo, na agregação um objeto-parte pode 
durar mais do que o seu objeto-todo (ou seja, pode continuar a existir mesmo depois do 
objeto-todo ser eliminado). Por exemplo, quando se um time deixa de existir, normalmente 
os jogadores que compunham aquele time permanecem existindo. Por outro lado, quando 
um pedido é eliminado, os itens que compunham aquele pedido não têm porque continuar 
a existir. Igualmente no relacionamento entre Empresa e Departamento (Figura 3.7), 
quando a empresa deixa de existir, não faz sentido querer manter os seus departamentos 
existindo. Essa diferença entre composição e agregação se reflete na multiplicidade do lado 
da classe-todo: enquanto na agregação essa multiplicidade normalmente é 0..1 (veja na 
Figura 3.6), na composição ela será sempre 1 (isto é, 1..1 – veja na Figura 3.7). A 
multiplicidade do lado da classe-parte pode variar, tanto na agregação quanto na 
composição. Normalmente, considera-se que um objeto-todo possa ser criado antes da 
criação dos seus objetos-parte (multiplicidade 0..*, ou simplesmente *). 
A seguir é apresentado um quadro comparativo entre agregação e composição. 
Tabela 3.1: Comparação entre agregação e composição 
Característica Agregação Composição 
Relação todo-parte Tem Tem 
Propagação de ação no objeto-todo a seus objetos-
parte (exceto, eliminação do objeto-todo) 
Sim Sim 
Modelagem de Sistemas Capítulo 3: Diagrama de Classes de Objetos 
 
27 
 
Característica Agregação Composição 
Propagação de eliminação do objeto-todo a seus 
objetos-parte 
Não Sim 
Existência do objeto-parte independentemente do seu 
objeto-todo 
Sim Não 
Tempo de vida do objeto-parte em relação ao seu 
objeto-todo 
Pode ser maior Menor ou igual 
Participação do (mesmo) objeto-parte na composição 
de mais de um objeto-todo 
Pode Não pode. 
Multiplicidade (usual) no lado da classe-todo 0..1 ou 0..* 1 
Multiplicidade (usual) no lado da classe-parte * * 
 
[DC-Lab4: Agregação e composição] 
Considere as classes Microcomputador, Monitor, Teclado e Gabinete. Desenhe um DC 
com essas classes e estabeleça as associações entre elas que julgar pertinentes (justifique). 
Generalização/especialização 
Existe ainda um outro tipo de associação entre classes, denominada associação de 
generalização/especialização. Quando duas ou mais classes são muito semelhantes, para se 
evitar a declaração dos mesmos atributos e operações repetidamente em cada classe, cria-
se uma classe geral onde são declarados os atributos e operações comuns a todas as classes 
envolvidas, as quais são então declaradas como especializações da classe geral. Em cada 
classe especializada ficam apenas os atributos e operações específicas dela, já que ela 
herda todos os atributos e operações declarados na classe geral à qual está associada. Essa 
é uma medida que, normalmente, contribui para melhorar a legibilidade e a compreensão 
do DC. Veja na Figura 3.8, exemplos desse tipo de associação entre classes. 
Na Figura 3.8, o diagrama da esquerda estabelece que Conta poupança é uma 
especialização de Conta corrente; consequentemente, herda todos os atributos (agencia e 
nrConta) e todas as operações (depositar( ) e obterSaldo(