1

UML (Unified Modeling Language) – Visão Geral

1. Introdução
• A UML é uma linguagem visual utilizada para modelar sistemas computacionais por meio do
paradigma de Orientação a Objetos.
• A UML tornou-se, nos últimos anos, a linguagem padrão de modelagem de software adotada
internacionalmente pela indústria de Engenharia de Software.
• A UML não é uma linguagem de programação e sim uma linguagem de modelagem.
• O objetivo da UML é auxiliar os engenheiros de software a definir as características do software:
o requisitos;
o comportamento;
o estrutura lógica;
o dinâmica de processos;
o necessidades físicas (equipamento), etc.

2. Engenharia de Software
• Envolve fatores como levantamento e análise de requisitos, prototipação, tamanho do projeto,
complexidade, prazos, custos, documentação, manutenção e reusabilidade, entre outros.
• Possui, em geral, as seguintes etapas: Levantamento de requisitos, Análise de requisitos, Projeto,
Codificação, Testes e Implantação.

2.1 Levantamento de requisitos

• O Engenheiro de Software busca compreender as necessidades do usuário e o que ele deseja que o
sistema a ser desenvolvido realize.
• Feito por meio de entrevistas, onde o Engenheiro tenta compreender como funciona atualmente o
processo a ser informatizado e quais serviços o cliente precisa que o software forneça.
• Devem ser realizadas tantas entrevistas quantas forem necessárias para que as necessidades do
usuário sejam bem compreendidas.
• Durante as entrevistas o Engenheiro deve auxiliar o cliente a definir quais informações deverão
ser fornecidas, quais informações deverão ser produzidas e qual o nível de desempenho exigido do
software.
• Problema de comunicação: dificuldade em compreender um conjunto de conceitos vagos,
abstratos e difusos, que representam as necessidades e desejos dos clientes, e transforma-los em
conceitos concretos e inteligíveis.
• Outro problema é que, muitas vezes, os clientes não sabem exatamente o que querem ou não
enxergam o real potencial de um sistema de informação.
• Muitas vezes os Engenheiros precisam sugerir muitas características e funções do sistema que o
cliente não sabia como formular o sequer havia imaginado.

2.2 Análise de requisitos

• Analisar as necessidades apresentadas pelo cliente:
o verificar se as necessidades foram realmente bem compreendidas;
o verificar se os requisitos foram especificados corretamente;
o verificar se algum tópico deixou de ser abordado;
o verificar se algum conceito precisa ser mais bem explicado;
o determinar as reais necessidades do sistema de informação.
• Propor uma reestruturação na maneira como as informações são geridas e utilizadas pela empresa,
apresentando novas maneiras de combiná-las e apresenta-las para que possam ser melhor
aproveitadas pelos usuários.
• Deve gerar as informações necessárias para a construção de um protótipo.
 2
2.3 Prototipação
• A prototipação é técnica bastante popular e de fácil aplicação.
• Consiste em desenvolver um “rascunho” do que seria o sistema de informação.
• Apresenta basicamente a Interface do software a ser desenvolvido.
• Ilustra como as informações seriam inseridas e recuperadas do sistema. Mostra também o
comportamento do sistema.
• Apresenta alguns exemplos com dados fictícios e mostra os resultados, principalmente os
relatórios gerados pelo sistema.
• O protótipo pode evitar que, após meses de desenvolvimento, se descubra que o software não
atende completamente as necessidades do cliente devido principalmente a falhas de comunicação
na fase de levantamento de requisitos.
• Ferramentas: Delphi, C++ Builder, Visual Basic, etc.

2.4 Prazos e Custos

• Os protótipos, geralmente, induzem o cliente a acreditar que o software se encontra em um estágio
bastante avançado de desenvolvimento.
• Muitas vezes, o cliente não compreende e nem aceita prazos longos e valores altos para o
desenvolvimento do sistema, pois para ele, o “esboço” apresentado já é o próprio sistema
praticamente acabado, precisando apenas de alguns ajustes, quando na verdade o desenvolvimento
ainda não foi realmente iniciado.
• Uma boa modelagem do sistema ajuda a estimar:
o a quantidade de profissionais necessários para o desenvolvimento;
o o custo do desenvolvimento;
o a complexidade do desenvolvimento;
o o prazo de entrega do sistema.
• Estimativas podem ser feitas analisando-se a documentação de outros sistemas já desenvolvidos
pela empresa.
• Estimativas erradas provocam:
o descontentamento do cliente pelo prazo não cumprido;
o prejuízos à empresa que desenvolve o sistemas, pois tem que manter a remuneração de
seus profissionais por um tempo maior que o previsto e fica impedida de iniciar novos
projetos por não ter profissionais disponíveis.

2.5 Manutenção e Documentação

• Representa de 40 a 60% do custo total do projeto.
• Um dos objetivos da modelagem é diminuir a manutenção do sistema devido a erros.
• Porém, mudanças são sempre necessárias, devido à evolução do sistema para atender as novas
necessidades da empresa.
• Neste caso, a modelagem serve para facilitar a compreensão do sistema para quem tiver que
mantê-lo ou ampliá-lo.
• Pior problema: código escrito por diferentes profissionais, que não se encontram mais na empresa,
cada um com um estilo diferente e que geraram código sem documentação.

2.6 Documentação
• A documentação auxilia na reutilização de rotinas, funções e algoritmos, pois permite responder
questões do tipo:
o Onde as rotinas se encontram?
o Para que foram utilizadas?
o Em que projetos estão documentadas?
o Se elas são adequadas para o software atualmente em desenvolvimento?
o Qual o nível de adaptação necessário para que essas rotinas possam ser utilizadas no
sistema atual?
 3
• A documentação de projetos anteriores também é utilizada no levantamento de prazos e custos de
um novo projeto, pois ajuda a responder questões do tipo:
o Qual a média de custo de modelagem?
o Qual a média de custo de desenvolvimento?
o Qual a média de tempo despendido até a finalização do projeto?
o Quantos profissionais são necessários para o desenvolvimento do projeto?

3. Os diagramas da UML
• A UML é um conjunto de diagramas que permite fornecer múltiplas visões o sistema a ser
modelado, analisando-o e modelando-o sob diversos aspectos.
• Cada diagrama analisa o sistema, ou parte dele, sob uma determinada ótica. Alguns diagramas
enfocam o sistema de forma mais geral, apresentando uma visão externa do sistema (Diagramas
de Casos de Uso, por exemplo). Outros diagramas oferecem uma visão de uma camada mais
profunda do software, apresentando um enfoque mais técnico (Diagramas de Classes, por
exemplo). Cada diagrama complementa os demais.

3.1 Diagrama de Casos de Uso

• É o diagrama mais geral e informal da UML.
• Utilizado nas fases de Levantamento e Análise de Requisitos, embora seja consultado durante
todo o processo de desenvolvimento e sirva de base para outros diagramas.
• Apresenta uma linguagem simples e de fácil compreensão, para que os usuários possam ter uma
idéia geral de como o sistema irá se comportar.
• Procura identificar os atores (usuários, outros sistemas, hardware especial), que irão interagir com
o software de alguma forma. Também identifica os serviços (ações) que o sistema disponibilizará
aos atores. Esses serviços, neste diagrama, são conhecidos como “Casos de Uso”.

Figura 1 – Diagrama de Casos de Uso

 4

3.2 Diagrama de Classes

• É o diagrama mais utilizado e o mais importante da UML.
• Serve de apoio para a maioria dos outros diagramas.
• Define a estrutura das classes utilizadas pelo sistema.
• Determina os atributos e métodos de cada classe.
• Estabelece como as classes se relacionam e trocam informações entre si.

Figura 2 – Diagrama de Classes

3.3 Diagrama de Objetos

• Este diagrama está amplamente relacionado ao Diagrama de Classes, sendo praticamente um
complemento deste.
• Fornece uma visão dos valores armazenados pelos objetos de um Diagrama de Classes em um
determinado momento da execução de um processo de software.
• Tornou-se um diagrama independente na UML 2. Antes era considerado uma extensão do
Diagrama de Classes.

Figura 3 – Diagrama de Objetos

 5

3.4 Diagrama de Estrutura Composta

• Descreve a estrutura interna de um classificador, como uma classe ou componente, detalhando as
partes internas que o compõem, como estas se comunicam e colaboram entre si.
• Também é utilizado para descrever uma Colaboração onde um conjunto de instâncias cooperam
entre si para realizar uma tarefa.
• É um dos três novos diagramas propostos pela UML 2.

Figura 4 – Diagrama de Estrutura Composta

3.5 Diagrama de Seqüência

• Preocupa-se com a ordem temporal em que as mensagens são trocadas entre os objetos envolvidos
em um determinado processo.
• Em geral, baseia-se em um “Caso de Uso”.
• Utiliza o diagrama de classes para determinar os objetos envolvidos em um processo.
• São funções do Diagrama de Seqüência:
o identificar o evento gerador do processo modelado;
o identificar o ator responsável por esse evento;
o determinar como o processo deve se desenrolar e ser concluído por meio da chamada de
métodos disparados por mensagens trocadas entre os objetos.

Figura 5 – Diagrama de Seqüência

 6

3.6 Diagrama de Colaboração (Comunicação na UML 2)

• Este diagrama está amplamente associado ao Diagrama de Seqüência, complementando-o.
• As informações contidas nestes dois diagramas são praticamente as mesmas, porém o Diagrama
de Colaboração não há preocupação com a temporalidade do processo, concentrando-se em como
os objetos estão vinculados e quais mensagens trocam entre si.

Figura 6 – Diagrama de Colaboração

3.7 Diagrama de Gráfico de Estados (Máquina de Estados na UML 2)

• Este diagrama acompanha as mudanças sofridas por um objeto dentro de um determinado
processo.
• Da mesma forma que o Diagrama de Seqüência, este diagrama muitas vezes baseia-se em um
“Caso de Uso” e apóia-se no Diagrama de Classes.
• Usado para:
o acompanhar os estados por que passa uma instância de uma classe;
o representar os estados de um “Caso de Uso”;
o representar os estados gerais de um sub-sistema ou de um sistema completo.

Figura 7 – Diagrama de Gráfico de Estados

 7

3.8 Diagrama de Atividades

• Era considerado um caso especial do antigo Diagrama de Gráfico de Estados e se tornou
independente na UML 2.
• Este diagrama descreve os passos a serem percorridos para a conclusão de uma atividade
específica, concentrando-se na representação do fluxo de controle.
• Esta atividade específica muitas vezes representa um método com certo grau de complexidade e
não um processo completo como nos diagramas de Seqüência ou Colaboração.

Figura 8 – Diagrama de Atividades

3.9 Diagrama de Componentes

• Este diagrama está amplamente associado à Linguagem de Programação que será utilizada para
desenvolver o sistema modelado.
• Representa os componentes do sistema quando este for implementado m termos de módulos de
código-fonte, bibliotecas, formulários, arquivos de ajuda, módulos executáveis, etc.
• Determina como estes componentes estarão estruturados e como irão interagir para que o sistema
funcione de maneira adequada.

Figura 9 – Diagrama de Componentes

 8
3.10 Diagrama de Implantação
• Determina as necessidades físicas do sistema: hardware, servidor, estações, topologias e
protocolos de comunicação, etc.
• Os diagramas de Componentes e de Implantação são bastante associados, podendo ser
representados em conjunto ou separadamente.

Figura 10 – Diagrama de Implantação

3.11 Diagrama de Pacotes

• Tem por objetivo representar os subsistemas englobados por um sistema, de forma a determinar as
partes que o compõem.

Figura 11 – Diagrama de Pacotes

3.12 Diagrama de Tempo

• Descreve a mudança no estado ou condição de uma instância de uma classe ou seu papel durante o
tempo.
• Tipicamente utilizada para demonstrar a mudança no estado de um objeto no tempo em resposta a
eventos externos.
• Foi criado na UML 2.

Figura 12 – Diagrama de Tempo

 9
3.13 Diagrama de Interação Geral
• É uma variação do Diagrama de Atividades que fornece uma visão geral dentro de um sistema ou
processo de negócio.

Figura 13 – Diagrama de Interação Geral

3.14 Síntese Geral dos Diagramas

Figura 14 – Síntese Geral dos Diagramas

 10

UML e Orientação a Objetos

1. Classes de Objetos
• As Classes são utilizadas para representar objetos que possuem as mesmas características e que se
comportam de maneira semelhante.
• As classes são representadas na UML por um retângulo que pode possuir até três divisões:
o a primeira divisão armazena o nome pela qual a classe é identificada.
o a segunda divisão enuncia os possíveis atributos (características ou propriedades)
pertencentes à classe;
o a terceira divisão mostra os possíveis métodos que a classe possui.

Figura 1 – Exemplo de uma classe com atributos e métodos

2. Atributos ou Propriedades
• Representam características dos objetos de uma classe (Cor de um carro, por exemplo).
• Dois objetos de uma mesma classe podem ser diferenciados através de suas propriedades.
• Os atributos são apresentados na segunda divisão da classe e, geralmente, contêm duas
informações: o nome do atributo e o seu tipo (caractere, inteiro, etc.).
• Não é possível trabalhar diretamente com as classes. É necessário criar uma instância da classe
para poder manipulá-la.
• Todas as instâncias de uma classe possuem os mesmos atributos, porém com valores diferentes.

3. Métodos ou Comportamentos
• Um método representa uma atividade que um objeto de uma classe pode executar.
• Toda vez que um método é invocado, um conjunto de instruções correspondente àquele método é
executado.
• Um método, assim como uma função escrita em uma linguagem de programação como C ou C++,
pode (ou não) ter parâmetros e pode (ou não) retornar um valor.

4. Visibilidade
• A visibilidade é utilizada para indicar o nível de acessibilidade de um determinado atributo ou
método.
• A visibilidade é indicada por um símbolo à esquerda do nome do atributo ou método.
• Existem três modos de visibilidade:
o Pública – é representada por um símbolo de mais (+) e significa que o atributo ou método
pode ser utilizado por qualquer classe;
o Privada – é representada por um símbolo de menos (–) e significa que somente a classe
possuidora do atributo ou método pode utilizá-lo;
o Protegida – é representada por um símbolo de sustenido (#) e significa que somente a
classe possuidora do atributo ou método, ou suas subclasses, podem ter acesso ao mesmo.
 11
5. Herança
• Uma das características mais poderosas e importantes da Orientação a Objetos (junto com o
polimorfismo).
• Permite reaproveitamento de atributos e métodos, otimizando o tempo de desenvolvimento,
diminuindo a quantidade de linhas de código e facilitando a manutenção.
• Uma Superclasse, ou Classe Mãe, é a classe que possui outras classes derivadas dela, chamadas de
Subclasses ou Classes Filhas.
• As classes filhas herdam as características (atributos e métodos) da classe mãe.
• Nas classes filhas não é necessário redeclarar atributos e métodos já declarados e implementados
na classe mãe. A reutilização do código é automática. Só é necessário se preocupar com os
atributos e métodos exclusivos da subclasse.
• A Herança Múltipla ocorre quando uma subclasse herda características de mais de uma
superclasse.

Figura 2 – Exemplo de Herança

Figura 3 – Exemplo de Herança Múltipla

6. Polimorfismo
• É a redeclaração de métodos herdados por uma classe.
• Esses métodos, embora semelhantes, diferem de alguma forma da implementação utilizada na
superclasse, sendo, portanto necessário reimplementá-los na subclasse.

Figura 4 – Exemplo de Polimorfismo

 12

Diagrama de Casos de Uso

1. Introdução
• É o diagrama mais abstrato da UML e, portanto, o mais flexível e informal.
• Por meio de uma linguagem simples, possibilita a compreensão do comportamento externo do
sistema por qualquer pessoa. Apresenta o sistema através de uma perspectiva do usuário.
• Apresenta uma visão geral das funções e serviços que o sistema deverá oferecer aos usuários, sem
se preocupar em como essas funções serão implementadas.
• É utilizado principalmente nas fases de Levantamento e Análise de Requisitos.
• Na Análise de Requisitos, ajuda a especificar, visualizar e documentar as características, funções e
serviços desejados pelo usuário.
• Este diagrama tenta identificar os tipos de usuário que irão interagir com o sistema, quais papéis
esses usuários irão assumir e quais funções serão requisitadas por cada usuário específico.
• É Consultado e modificado durante o processo de engenharia. Serve de apoio para outros
diagramas.
• Deve ser apresentado durante as reuniões iniciais com o cliente, de forma a ilustrar o
comportamento do sistema, facilitar a compreensão do usuário e detectar possíveis falhas na
especificação.

2. Atores
• Representam os papéis desempenhados pelos diversos usuários que poderão utilizar de alguma
maneira os serviços e funções do sistema.
• Eventualmente, um ator pode representar um hardware especial ou mesmo um outro software que
interaja com o sistema.
• Portanto, qualquer elemento externo que interage com o sistema é um ator.
• Os atores são representados por símbolos de “bonecos magros” com uma descrição de seu papel
logo abaixo.

3. Casos de Uso
• São os serviços, tarefas ou funções que podem ser utilizados pelos atores.
• São utilizados para expressar e documentar os comportamentos pretendidos para as funções do
sistema.
• Muitas vezes, pode-se associar um Caso de Uso à uma Tela do sistema (às vezes são várias telas;
às vezes é apenas uma parte de uma tela).
• São representados por elipses contendo um texto que descreve o serviço.

• Os Casos de Uso, geralmente, possuem uma documentação que fornece informações do tipo:
o como será seu funcionamento;
o quais atividades deverão ser executadas;
o qual evento forçará a sua execução;
o quais atores poderão utilizá-lo;
o quais suas possíveis restrições e validações.
 13
4. Documentação dos Casos de Uso
• Não existe um formato específico de documentação definido pela UML.
• Em geral, utiliza-se uma linguagem simples para que usuários leigos possam entendê-la.

• O ator principal é aquele que mais interage com o sistema e que está interessado em obter
resultados.

5. Associações
• As associações representam as interações ou relacionamentos:
o entre os Atores que fazem parte do diagrama;
o entre os Atores e os Casos de Uso;
o entre os Casos de Uso e outros Casos de Uso.
• Uma associação entre um Ator e um Caso de Uso demonstra que o Ator utiliza-se, de alguma
maneira, da função do sistema representada pelo Caso de Uso, seja requisitando a execução
daquela função, seja recebendo o resultado produzido por ela a pedido de outro Ator.
• A associação é representada por uma reta unindo o Ator ao Caso de Uso.
• O sentido em que as informações trafegam em uma associação é indicado através de setas nas
extremidades da reta. Se não houver setas, as informações são transmitidas nas duas direções.
• A associação pode possuir uma descrição própria quando há necessidade de esclarecer a natureza
da informação que está sendo transmitida ou quando se quer apenas dar um nome à associação.

6. Associação de Especialização/Generalização
• O relacionamento de Especialização/Generalização é uma forma de associação entre Casos de Uso
na qual existem dois ou mais casos com características semelhantes.
• Facilita a documentação, evitando a repetição de informações.
 14
• Caso de Uso Geral – descreve características compartilhadas por todos os casos.
• Caso de Uso Específico – herda toda a estrutura do Caso de Uso Geral e define as características
específicas. Herda inclusive associações de Inclusão, de Extensão e com Atores que o Caso de
Uso Geral venha a possuir.
• Este tipo de associação é representado por uma reta com uma seta mais larga apontando para o
Caso de Uso Geral.
• Este tipo de relacionamento também pode ser aplicado a Atores.

7. Associação de Inclusão
• Esta associação é utilizada quando existe um serviço, situação ou rotina comum a mais de um
Caso de Uso.
• Evita descrever uma mesma seqüência de passos em vários Casos de Uso.
• Os relacionamentos de Inclusão indicam obrigatoriedade. Quando um determinado Caso de Uso
possui um relacionamento de Inclusão com outro, a execução do primeiro obriga também a
execução do segundo.
• Pode ser comparado à chamada de uma sub-rotina.
• É representada por uma reta tracejada contendo uma seta em uma das extremidades, apontando
para o Caso de Uso incluído.
• Costuma apresentar o estereótipo <<include>>.

8. Associação de Extensão
• As associações de extensão descrevem cenários opcionais de um Caso de Uso, que serão
executados apenas se uma determinada condição for satisfeita.
• Exigem um teste para determinar se é necessário executar também o Caso de Uso Estendido.
• Também são representadas por uma reta tracejada contendo uma seta em uma das extremidades,
apontando para o Caso de Uso que usa o Caso de Uso Estendido.
• Possui o estereótipo <<extend>>.
 15

9. Exemplo: Sistema de Controle de Apólices de Seguro

• Todos os Casos de Uso descritos como “Manter ...” referem-se a cadastros simples com funções
do tipo: inclusão, alteração, exclusão, consulta, etc.
• Manter Clientes e Manter Veículos – Cliente fornece informações pessoais e do veículo. Corretor
insere informações no sistema. Note que a navegabilidade do Cliente é unidirecional.
• Verifica Veículos – Vistoriador verifica estado do veículo e passa seu parecer ao Corretor.
• Verifica Valor Seguro – Corretor consulta Matriz para obter valores e condições do seguro.
• Gerar Apólice – Corretor informa ao Cliente os valores da apólice. Cliente decide em quantas
parcelas quer pagar. A apólice é gerada. Faz chamada ao Caso de Uso “Manter Parcelas a
Receber”.
• Manter Parcelas a Receber – Registra o valor de cada parcela, data de pagamento, se a mesma já
está quitada ou não, etc. Passa as informações ao Ator “Contas a Pagar e Receber”.
• Manter sinistro – Recebe as informações de sinistro do Cliente e informações adicionais do
Vistoriador. Os dados são inseridos no sistema pelo Ator “Secretária”. Note que o Ator
“Vistoriador” aparece duas vezes no diagrama para evitar congestionamento.
• Quitar Parcela – Cliente paga parcela. Secretária recebe notificação de pagamento. O Caso de Uso
“Manter Parcelas a Receber” é atualizado.
• Existem três momentos distintos no processo: cliente solicita apólice de seguro, cliente informa
sinistro e cliente paga parcela. Porém, o Diagrama de Casos de Uso não se preocupa com a
questão da temporalidade, pois existem outros diagramas específicos para isto.
 16
10. Exemplo: Sistema de Controle Bancário

• Retângulo representa a Fronteira do Sistema, que separa Atores externos dos serviços e funções do
software. Atores externos representam o ambiente onde o sistema será executado (Contexto do
Sistema).
• Cliente pode solicitar a abertura de três tipos de conta:
o Conta comum – não permite saque maior do que o saldo;
o Conta Especial – permite saque extra até um determinado limite;
o Conta Poupança – rende juros quando o dinheiro depositado não é movimentado.
• Abertura de Conta (Comum, Especial ou Poupança) – Cliente fornece informações para abertura
de conta e faz depósito inicial. Funcionário realiza abertura e faz manutenção no cadastro do
cliente se for necessário.
• Manter Clientes – utilizado frequentemente pelo funcionário. Quando uma conta é aberta, às vezes
é necessária a inclusão do cliente (se ele ainda não é cliente do banco) ou a atualização de seu
cadastro. Quando a conta é encerrada, pode ser necessária atualização. Associações de Extensão.
• Depósito – É obrigatório na abertura de conta. Associação de Inclusão.
• Encerrar Conta – antes de encerrar a conta precisamos:
o Verificar o Saldo. Associação de Inclusão.
o Efetuar Saque, se o saldo for positivo. Associação de Extensão.
o Efetuar Depósito, se o saldo for negativo. Associação de Extensão.
o Atualizar cadastro do Cliente. Se for a única conta, o cliente passa a ser inativo.
Associação de Extensão.
• Saldo, Depósito, Saque e Extrato – podem ser utilizados diretamente pelo Cliente através de um
Funcionário ou através de um Caixa Eletrônico, por exemplo, representados pelo Ator Banco.
• Os serviços de Saque e Depósito precisam “Registrar Movimento”. Associação de Inclusão.
 17

11. Elementos comuns a todos os Diagramas da UML

11.1 Notas
• Apresenta um texto explicativo a respeito de um determinado elemento do diagrama.
• As Notas são representadas por retângulos com uma dobra no canto superior direto e ligados ao
elemento do diagrama através de uma linha tracejada.

11.2 Pacotes
• Permitem organizar elementos em grupos.
• Utilizados em modelagem de sistemas muito extensos, principalmente quando existem vários
sistemas ou subsistemas integrados.
• Demonstram os limites de cada subsistema e como eles se inter-relacionam.
• São representados por retângulos contendo uma aba no canto superior esquerdo.
• A principal forma de relacionamento dos pactos é a de Dependência, representada por uma seta
tracejada apontando para o pacote que depende do outro.

11.3 Estereótipos
• São utilizados para destacar algum componente do diagrama, especificando o seu tipo ou função.
• A maioria dos estereótipos são textos que aparecem entre os sinais de << e >>.

• O estereótipo acima deixa claro que “Abertura de Conta” é um processo.

• O estereótipo acima é gráfico e representa uma fronteira (boundary) do sistema. Indica que o
componente é uma interface dos usuários externos com o sistema.