ENGENHARIA DE SOFTWARE II

CAPÍTULO 1 – POR QUE PROJETAR

SOFTWARE ORIENTADO A OBJETOS COM
UML?
Halley Wesley Alexandre Silva Gondim

-1-
Introdução
O Paradigma Orientado a Objetos (POO) trouxe mais facilidade na modelagem de sistemas, pois por meio dele, é
possível abstrair, de forma mais natural, as regras de negócio de um problema a ser resolvido para objetos (com
suas características e ações). O motivo dessa naturalidade é que o conceito de objeto está ligado diretamente ao
nosso cotidiano, já que uma classe representa um grupo ou categoria de objetos (entidade) do mundo real e os
objetos são membros dessas categorias, contendo suas características e ações. Por exemplo, quando definimos
Veículo como uma classe que poderá conter diferentes objetos (instâncias), de diversas marcas e modelos. Por
outro lado, para complementar o POO, pode-se utilizar uma notação que é bastante difundida e utilizada e está
diretamente ligada à orientação a objetos (OO). Esta notação é a UML (Unified Modeling Language).
A UML é uma linguagem gráfica que serve para especificar, visualizar, construir e documentar artefatos
(arquivos), primariamente, de um sistema de software. Ela é independente do processo de desenvolvimento e é
bastante utilizada por conta de sua facilidade de comunicação e do entendimento por parte de todos os
envolvidos (stakeholders e equipe técnica).
Deve ficar claro que a UML não é uma linguagem de programação, e sim, uma linguagem de modelagem, cujo
objetivo é auxiliar os engenheiros de software a definirem as características do software, tais como seus
requisitos, seu comportamento, sua estrutura lógica, a dinâmica de seus processos e, até mesmo, suas
necessidades físicas, em relação ao equipamento sobre o qual o sistema deverá ser implantado.
Logo, ao se juntar OO e UML, podemos projetar softwares mais efetivos e funcionais. Isso porque, ambos
fornecem mecanismos para observar o comportamento e interação de um sistema, antes mesmo, de se escrever
uma única linha de código. Além disso, o mercado absorveu bastante os dois conceitos e atualmente é imperativo
conhecê-los.
Nesse capítulo, descreveremos os conceitos principais de OO, bem como de UML.
Acompanhe com atenção e bons estudos!

1.1 Modelos de projeto

Como futuro desenvolvedor, você deve estar se perguntando, por que modelar um software? Não podemos pular
essa etapa e começar a codificação? A resposta é simples: não sabemos, de cabeça, qual a necessidade do sistema.
Ao nos deparar com essa questão podemos, simplesmente, pensar em outra: por que devemos projetar uma
casa? Um mestre de obra não é capaz de construí-los? Quanto mais simples for a casa, podemos dizer que sim,
mas na medida em que a casa se torna um prédio, a complexidade de construção aumentará e gerará um erro
catastrófico e, sem dúvida, uma situação bastante difícil.
Continuando nessa linha de raciocínio, como vamos prever custos se não sabemos o tamanho que o software
terá? Quando não modelamos, corremos o risco de descobrir os erros somente em fases que possuem um custo
maior para a correção (GALLOTTI, 2017). Logo, é essencial sempre modelar para conhecer o que construiremos,
pois a correção nessa fase é bem-vinda.
A modelagem de projeto é o processo pelo qual são construídos modelos abstratos do software e cada modelo
pode apresentar uma perspectiva ou visão particular/diferente do sistema. Esse processo não envolve o
desenvolvimento de código-fonte, mas, sim, o uso de notações gráficas (visualizações), como é o caso da UML. A
modelagem de um sistema de forma gráfica permite que a equipe técnica e os stakeholders (partes interessadas)
entendam as funcionalidades e realizem uma comunicação mais simples, pois, por meio de uma visualização,
pode-se aumentar a percepção cognitiva do todo (problema) ao contrário de somente textos e planilhas
(PFLEEGER, 2004).
A modelagem do sistema pode ocorrer, principalmente, nas primeiras fases de um processo de desenvolvimento
de software, pois é mais viável e barato modificar a estrutura de um software antes da codificação. E como dito

anteriormente, as visões de um modelo podem ignorar alguns detalhes do sistema para focar em outros. Em

-2-
anteriormente, as visões de um modelo podem ignorar alguns detalhes do sistema para focar em outros. Em
consequência, deve-se usar um conjunto de diagramas que se complementem e demonstrem a essência do
sistema. Logo, uma boa modelagem do sistema deve-se preocupar com algumas perspectivas/visões
(SOMMERVILLE, 2011). Para conhecê-las, clique nas abas a seguir.
Interação
Modelar as relações/interações entre sistemas e seus componentes.
Externa
Modelar o ambiente para o qual o sistema se encontra.
Comportamental
Modelar a forma como o sistema responde a eventos.
Estrutural
Modelar a organização estrutural dos componentes de um sistema.

VOCÊ SABIA?
A UML surgiu da união de três métodos de modelagem de diferentes autores, sendo o OMT (
Object Modeling Technique) de Jacobson, OOSE (Object-Oriented Software Engineering) de
Rumbaugh e, por fim, o de Booch. Esse processo de junção contou com a participação do
Rational Software (IBM), a partir de 1990.

E é nesse contexto que a UML pode nos oferecer uma série de recursos gráficos que permitem observar o
sistema em diferentes pontos de vista (visões/perspectivas). A Linguagem de Modelagem Unificada possui, ao
todo, 14 diferentes tipos de diagramas e, basicamente, está dividida em duas categorias: as estruturais e
comportamentais (GUEDES, 2011). Para conhecer essas categorias, clique nos itens a seguir.
Diagramas estruturais: representam aspectos estáticos do sistema, ou seja, a estrutura do sistema. Eles não
levam em conta a interação dos componentes.
Diagramas comportamentais: representam aspectos dinâmicos do sistema, como os processos e
funcionalidades que se relacionam.
Diagramas de interação: enfatizam o controle de fluxo e dados no sistema.
Para complementar seus conhecimentos sobre este tema, veja que a figura a seguir apresenta os diferentes
diagramas da notação.

-3-
 Figura 1 - Diagramas da UML.
Fonte: Elaborada pelo autor, 2018.

Apesar de existirem todos os diagramas, alguns usuários acreditam que somente os diagramas de atividade,
casos de uso, sequência, classe e estado podem representar a síntese de um sistema (SOMMERVILLE, 2011). Ao
longo desse capítulo, discutiremos sobre cada um deles.

VOCÊ QUER VER?

Bons filmes para se compreender o funcionamento de uma grande empresa de
desenvolvimento de software são: Os Estagiários (VAUGHN; STERN, 2013), cuja história se
passa na empresa Google, e A rede social (SORKIN, 2010), que conta a formação do Facebook).
Ambos os filmes trazem algo do cotidiano das maiores empresas de TI do mundo, mostrando a
dinâmica da criação de projetos e o estilo de profissionais desejados.

Para facilitar o desenvolvimento dos diagramas, vamos utilizar um programa chamado Astah Professional, com
licença de estudante (ASTAH PROFESSIONAL, 2018). Ele possui uma versão open-source, que permitirá a
construção de nossos diagramas de maneira fácil e gratuita.

-4-
1.1.1 Modelo de contexto
A fronteira (limite) da aplicação deve ser a primeira iniciativa de análise na criação de um sistema. Nela deve-se
observar quais funcionalidades deverão ser incluídas, o que será criado ou obtido por outros sistemas, quais
ações serão manuais ou automatizadas, dentre outros. Em consequência, após essa avaliação deve-se definir o
contexto de nossa aplicação, levando em consideração as suas dependências e o ambiente no qual se encontra. E
uma forma de se representar esse contexto é por meio de um modelo arquitetural simples, a qual é possível ter
uma ideia macro (alto nível) de todo o sistema, possibilitando visualizar a sua fronteira de forma rápida e
objetiva.
A representação gráfica de um modelo de contexto mais simples é feita por meio de retângulos que interligam os
diversos sistemas entre si (figura a seguir). Essas ligações podem representar troca/geração de dados, uns com
os outros. Essa representação, por ser tão simples, deve ser associada a outros tipos de modelo, como o de
processos de negócio BPMN e o diagrama de atividades (que veremos mais adiante). Por meio desses modelos é
possível representar, de forma detalhada, o contexto do sistema.
Na figura a seguir, podemos ver um exemplo de um diagrama de contexto, que mostra em alto nível um sistema
de atendimento a pacientes (ao centro) com os outros sistemas externos (outras caixas). As linhas indicam que
os sistemas trocam informações entre si.

Figura 2 - Sistema de atendimento de pacientes e seu relacionamento com outros sistemas.

Fonte: SOMMERVILLE, 2011, p. 84.

Na próxima seção avançaremos para mais um diagrama da UML. Ele é bastante conhecido e utilizado e é um dos
primeiros diagramas a serem criados na elaboração de um software, estamos falando do diagrama de casos de
uso.

-5-
1.1.2 Modelo comportamental: diagrama de casos de uso
Casos de uso é mais um diagrama definido pela UML. Ele é bastante utilizado no início da modelagem de um
sistema (MEDEIROS, 2004). Permite representar de maneira simples e objetiva as funcionalidades (requisitos)
principais que serão implementadas no futuro software. Ele pode ser apresentado durante as fases de elicitação
(descoberta) de requisitos, com o intuito de ser um canal facilitador entre os clientes e a equipe técnica. Além
disso, esse diagrama também permite identificar os usuários (papeis) envolvidos no sistema, juntamente com a
interação com o mesmo.
Basicamente, a sua representação gráfica é por meio de uma elipse que conterá um texto informando a sua
funcionalidade. O conteúdo (texto) da elipse deve ser uma ação (conter verbo) com o mínimo de palavras
possível.
Para complementar o diagrama tem-se um outro componente gráfico, que são os atores (GUEDES, 2011). Eles
são representados por meio de um desenho de um boneco e podem se relacionar entre si e com as elipses por
meio de uma linha. Veja na figura abaixo, um exemplo de um diagrama de casos de uso para comprar um
produto na internet.

Figura 3 - Diagrama de Casos de Uso - Sistema de compra de produtos.

Fonte: Elaborada pelo autor, 2018.

Ao observar a figura acima, temos três atores (bonecos). Eles assumem, respectivamente os papeis de vendedor,
cliente e gerente. Quando há uma linha ligando um ator a um caso de uso, estamos dizendo que aquele papel
deve executar a ação relacionada a ele. Além disso, ao observar melhor o diagrama anterior, temos três linhas
diferentes. A primeira está ligando cliente a vendedor, tal ligação informa que o cliente deve herdar todos os
relacionamentos de vendedor com os casos de uso. O uso de herança evita a poluição visual do diagrama, ou seja,
inclusão de linhas desnecessárias.
Agora, as outras linhas (tracejadas) representam um estereótipo, ou seja, uma espécie de extensão da notação
UML para dar mais riqueza de detalhes ao diagrama. O <<extend>> representa um caso de uso opcional,
enquanto que o <<include>> é obrigatório. A leitura do diagrama (da figura acima) pode ser assim: o gerente

pode visualizar relatórios, caso perceba que há falta de um produto “poderá” (opcional) pedir produtos para o

-6-
pode visualizar relatórios, caso perceba que há falta de um produto “poderá” (opcional) pedir produtos para o
estoque. Por outro lado, ao comprar um produto o vendedor/cliente terá (obrigatório) que gerar a Nota Fiscal.
Devemos observar as direções das setas para não nos confundir, pois uma é o contrário da outra.
O diagrama de casos de uso, geralmente, é acompanhado por uma descrição da ação a ser executada, para
fornecer mais detalhes. A seguir, clique nas abas para conhecer um exemplo de como descrever um caso de uso,
mas não limitada a essa (SOMMERVILLE, 2011).
Atores
Inserir todos os atores (papéis) envolvidos na ação.
Descrição
Descrever de forma clara e sem ambiguidade a ação que o caso de uso faz.
Dados
Informações envolvidas no caso de uso.
Estímulos
Quais são as interações realizadas pelos atores.
Resposta
Informações que os atores devem receber.
Comentários
Inserir alguma informação importante para o caso de uso.
A UML possui alguns mecanismos extras além de diagramas. Para conhecê-los, clique nos itens a seguir.

•
Estereótipo
(<< x >>) Estende o significado de um determinado elemento do diagrama, podendo ser gráficos
ou textuais.
•
Notas explicativas
Comenta ou esclarece alguma parte do diagrama.
•
Tagged values
Pré-definir propriedades para determinados elementos.
•
Restrições
Podem ser formais (especificação OCL - Linguagem para Especificação de Restrições), ou informais.
•
Pacotes
Agrupa elementos semanticamente relacionados.

A seguir, conheceremos algumas das mais usadas técnicas para obtenção de objetos a partir da descrição de um
problema. Por meio dessas técnicas, poderemos selecionar os possíveis objetos do sistema de forma mais precisa
e eficiente.

1.2 Identificação dos objetos de classes

A orientação a objetos está fixada sobre três pilares: o encapsulamento (esconder a complexidade de métodos e
atributos), herança (herdar atributos e métodos de outras classes) e o polimorfismo (métodos com a mesma
assinatura com comportamentos diferentes). Entretanto, antes mesmo de compreender esses conceitos é
importante entender os termos: classes, atributos, métodos, instâncias e objetos. Estes termos estão relacionados
/presentes na composição de qualquer solução orientada a objetos. Para facilitar a representação de uma classe

podemos utilizar diagramas da UML, que por exemplo, pode ser o diagrama de classes. Ao longo das próximas

-7-
podemos utilizar diagramas da UML, que por exemplo, pode ser o diagrama de classes. Ao longo das próximas
seções, vamos estudar mais detalhes sobre cada um desses conceitos e apresentaremos quais técnicas podem
auxiliar na obtenção/seleção de objetos relevantes contidos em nosso problema.

1.2.1 Identificação de objetos

Pode-se definir que um objeto, na OO, é uma abstração de alguma entidade (imaterial ou concreta) do mundo
real. Por exemplo, carro, aluno, casa, conta-bancária, etc. Basicamente, todos os objetos compartilham dois
conceitos em comum, que são seus estados (atributos/características) e comportamentos (ações) (PFLEEGER,
2004). O objeto “aluno” pode conter um atributo chamado matrícula com o valor “12345 “e uma ação
“trocar_numero_telefone”. Logo, o valor “12345” representa um estado do objeto “aluno” e que o
“trocar_numero_telefone” é um exemplo de seu comportamento, indicando uma ação.
Para conhecer mais sobre este tema, clique nas setas.
Uma dica simples para se identificar qual entidade do mundo real se tornará um objeto de nosso sistema é
observar o contexto do problema a ser desenvolvido e selecionar todos os substantivos relacionados. Por
exemplo, em um software de locação de veículos, devemos separar: carro, locatário, agenda, sinistro, etc. Em
consequência, alguns desses substantivos potencialmente farão parte de nossos objetos. Já as operações e
serviços de cada substantivo serão propriamente ditas em verbos (SOMMERVILLE, 2011).
Outra dica é tentar trazer para a realidade observando as entidades e seus relacionamentos. Por exemplo, eu sou
um usuário que deseja ir até uma loja de locação de veículos para agendar um veículo do período x até o y. Ou
seja, o seu cotidiano lhe mostrará quais são as entidades envolvidas no sistema, que nesse contexto são: usuário,
empresa, agenda, veículo, locação, etc. Pode-se também usar uma análise com base em cenários, na qual a
medida que forem sendo realizados uma equipe observa quais entidades estão envolvidas (SOMMERVILLE,
2011).
Apesar dessas dicas, deve-se utilizá-las em conjunto e compreender o mais rápido possível o domínio do sistema
(regras de negócio).
A identificação exata de todos os objetos de um sistema só será possível por meio da análise de requisitos. No
primeiro momento, na Elicitação e Análise de Requisitos tem-se que efetuar as atividades de descoberta de
requisitos, classificação e organização dos requisitos e, por fim, a priorização e negociação de requisitos. Na
medida em que os envolvidos evoluem/amadurecem no sistema, as entidades vão se tornando cada vez mais
evidentes, o termo muito usado é a evolução no domínio da aplicação (PRESSMAN, 2016).

-8-
CASO
Matheus é um jovem desenvolvedor e recebeu a seguinte demanda: uma empresa deseja
construir um software que registre os preços, diariamente, de um conjunto de produtos em
diferentes supermercados da cidade. Deverão ser registrados: o nome do produto; código de
barras; descrição; preço; qual supermercado que se encontra; dia de cadastro; o colaborador
que o cadastrou; nome, endereço e telefone do estabelecimento. Entretanto, há preços
distintos para pessoas físicas e pessoas jurídicas.
Matheus, ao se deparar com esse cenário, se lembrou que os possíveis objetos poderiam ser os
substantivos contidos na descrição do texto. E, com base nisso, ele encontrou: produto;
supermercado; coleta; colaborador; pessoa física; e pessoa jurídica. Com mais uma refinada,
ele se deparou com os seguintes objetos: produto; estabelecimento (pois não se limita somente
a supermercado); registro de preço (ato de pegar o preço do produto no supermercado);
colaborador; pessoa; pessoa física; e pessoa jurídica. Com base nesse simples refinamento, ele
pôde perceber que a modelagem está ficando cada vez mais próxima do que realmente deve
ser. Entretanto, ele sabe que, ao longo do tempo, a estrutura pode mudar, pois os envolvidos na
construção do sistema e clientes podem mudar de visão, ou alterar o escopo da aplicação.

A seguir, será apresentado o conceito que permite definir um molde para os objetos, definindo atributos e ações.

1.2.2 Especificação de classes: atributos e operações

Vimos que os objetos representam entidades do mundo real. Entretanto, necessitamos de um conceito que
permita criar objetos que tenham a mesma estrutura e que, ao mesmo tempo atuem como um molde para a
criação de objetos. Tal conceito é a própria definição de uma classe. As classes são essenciais para a criação dos
objetos, pois permitem a padronização de atributos e operações. Os atributos são as informações que um objeto
pode ter. Veja o exemplo de uma classe “Pessoa”, seus possíveis atributos são: cor dos olhos, altura, data de
nascimento, peso, etc. Perceba que podemos definir inúmeros atributos, pois o que limita a criação é um outro
conceito chamado abstração. Isto é, quais atributos são essenciais para o nosso atual contexto. Se o sistema a ser
desenvolvido for uma locação de veículos não há necessidade de obter a coloração dos olhos dos clientes.

VOCÊ O CONHECE?
O cientista da informação Ole-Johan Dahl (1931-2002) e o matemático Kristen Nygaard (1926-
2002) foram os desenvolvedores da programação orientada a objetos no Centro Norueguês de
Computação, em Oslo (Noruega), por meio da linguagem Simula, em 1967. Em 2001, eles
receberam o prêmio Turing, por sua contribuição à criação da programação orientada ao
objeto, com o projeto das linguagens de programação: Simula I e Simula 67 (LEITE, 2006).

Por outro lado, as classes também definem quais serão as operações (ações) sobre os objetos. Imagine na classe

-9-
Por outro lado, as classes também definem quais serão as operações (ações) sobre os objetos. Imagine na classe
“Televisor” com uma operação simples como ligar/desligar. Logo, tais ações podem modificar o estado de nossos
atributos ou realizar outros tipos de tarefas. Geralmente, os nomes das operações devem sempre representar
uma ação e usar verbos. Ao criarmos uma classe, todos os seus (instâncias) objetos deverão possuir os mesmos
atributos e métodos, a diferença se dá nos dados contidos em cada atributo (PRESSMAN, 2016).
Já na UML, uma classe é representada graficamente pelo diagrama de classes (figura a seguir). Ele pode ser
representado de forma simplificada (classe Aluno), ou por sua versão completa (Televisor), que é dividida em
três partes: identificação, atributos e ações.

Figura 4 - Diagrama de classe – representação de uma classe.

Fonte: Elaborada pelo autor, 2018.

Em um diagrama de classes, temos a visibilidade dos atributos e métodos por meio dos qualificadores. Em nosso
exemplo (figura acima), há o símbolo/qualificador (-) precedendo o nome de nossos atributos. Este símbolo
representa que os atributos/métodos/classes serão privados, ou seja, não serão acessíveis/visíveis a outros
objetos. Já o símbolo (+) indica que são públicos e que podem ser acessados/visíveis de qualquer parte do
sistema.
Existem mais dois outros tipos: a protegida (#) que determina que, além da própria classe, as suas subclasses
podem ter visibilidade e o pacote (~) que permite que o atributo, ou método, seja acessível a qualquer classe
dentro do pacote (GUEDES, 2011).

- 10 -
 Figura 5 - Diagrama de pacotes contendo diagramas de classes para representar a visibilidade de classes,
atributos e métodos.
Fonte: Elaborada pelo autor, 2018.

Observe o exemplo do diagrama de classes anterior. Temos dois pacotes: o serviço (terá regras de negócio) e o
modelo (representação dos objetos). Vejamos o atributo nome (público) da classe pessoa, todas as classes do
diagrama terão acesso (vão visualizá-lo). Já o CPF é (#) protegido, quem terá a visibilidade dele será somente a
própria classe Pessoa e as suas filhas (no caso, Aluno). O atributo endereço é privado (-), logo, somente a classe
Pessoa é capaz de acessá-lo. Por fim, os atributos curso (Aluno) e contato (Contato) são atributos de pacote (~) e
eles são acessíveis a todas as classes que estão contidas no pacote “modelo”.

VOCÊ SABIA?
O diagrama de classes e de casos de uso são os diagramas mais utilizados na representação de
sistemas. Independente do processo de desenvolvimento eles sempre estão presentes. São
facilmente encontrados em metodologias ágeis, como Scrum e XP.

As classes também podem se relacionar e a sua representação se dá por meio de uma linha ligando as classes que
possuem relação. Na figura a seguir, há um exemplo de relacionamento entre a classe Pessoa e Contato. Note que
existem alguns números atribuídos à ligação. Nesse exemplo, podemos ler: uma pessoa pode ter de zero a muitos
contatos e um contato está associado a uma pessoa, esses números agregados às linhas, são chamados de
multiplicidade.

Figura 6 - Diagrama de classe – relacionamento entre classes.

Fonte: Elaborada pelo autor, 2018.

- 11 -
 Fonte: Elaborada pelo autor, 2018.

A título de padronização, os nomes das classes devem estar no singular e a sua primeira letra sempre em
maiúsculo, já os atributos e métodos devem sempre ser minúsculos.
A seguir, conheceremos o conceito de herança que facilitará o desenvolvimento de nossas aplicações.

1.3 Hierarquia e herança de classes

Mesmo após construir um diagrama de classes, com suas classes recheadas de atributos e métodos, é necessário
certificar-se que a disposição dessas informações em classes está mapeada de forma satisfatória e correta. Para
isso, existem técnicas de refinamento de classes, que serão abordadas na seção a seguir.
Por outro lado, um outro conceito bastante interessante é a da herança. A herança é uma das características mais
poderosas da OO, pois, por meio dela, é possível reaproveitar partes do código (atributos/métodos)
possibilitando uma melhor manutenção e proporcionando uma considerável diminuição do número de linhas do
código-fonte. Pela definição de herança podemos introduzir outro conceito bastante utilizado que é o
polimorfismo, nesse caso em especial, a sobrescrita. Este conceito permite que classes filhas sobrescrevam
métodos contidos nas classes mães.
Vamos estudar mais detalhes, agora, sobre os possíveis relacionamentos entre classes na UML. Acompanhe!

1.3.1 Refinamento de classes

Nem sempre conseguimos identificar, de forma clara, quais serão as nossas classes do sistema. Para isso,
devemos refiná-las (refatorar) até chegar em um estado desejado. Um exemplo bem simples de refinamento é a
decomposição de tarefas em subtarefas, por meio das diferentes visões/perspectivas do sistema
(SOMMERVILLE, 2011).
Pode-se refinar uma classe por meio de duas abordagens, por seus atributos, ou pelos métodos. Pela primeira,
podemos adicionar novos atributos, transformá-los em uma nova classe, mesclá-los ou, até mesmo, tornar um
atributo em vários outros. A mesma regra pode ser aplicada aos métodos.
Caso você tenha algum conhecimento de banco de dados, podemos comparar essa fase com as normalizações de
banco de dados, com o objetivo de definir uma entidade mais fiel ao mundo real.

VOCÊ QUER LER?

A normalização tem como objetivo aplicar uma série de regras às tabelas, com o intuito de
evitar falhas e redundâncias no projeto. Um ótimo autor que descreve, passo a passo, a
aplicação de uma normalização em um banco é o cientista da computação Abraham
Silberschatz, no livro em Sistema de Banco de Dados (SILBERSCHATZ, 2016).

Também podemos refatorar nossas classes com o objetivo de torná-las mais efetivas e funcionais possíveis,
visando sempre a simplicidade. E, para isso, podemos usar diferentes estruturas de relacionamentos do
diagrama de classe. Logo, criar um diagrama que represente bem o sistema é essencial para um melhor

desenvolvimento das outras fases do projeto. Para isso, vamos conhecer melhor os diagramas de classes,

- 12 -
desenvolvimento das outras fases do projeto. Para isso, vamos conhecer melhor os diagramas de classes,
aprofundando alguns conceitos. A princípio, começaremos com tipos de relacionamentos (GUEDES, 2011).
Clique nos itens para conhecê-los.

Associação

É a ligação mais comum, a que vimos até o momento. Ela indica que uma instância de um elemento
está ligada à instância de outro elemento. Podemos incluir a multiplicidade com direcionamento
de leitura (linhas com setas).
•

Dependência

Classe cliente é dependente de algum serviço da classe fornecedora (usa algum método) – seta
tracejada que aponta para a classe independente.
•

Agregação

As partes têm existência própria. Diamante vazio na extremidade, referente ao todo. O objeto pode
se relacionar com outro. Exemplo: a roda vive sem um carro.
•

Composição

As partes não têm existência própria. Linha com diamante cheio. Na composição, o todo tem
sempre a cardinalidade 1. Já o item, necessariamente, está associado a um e somente um todo.
•

Generalização/especialização (herança)

As classes filhas herdam os atributos e métodos das classes superiores (será mais explorada na
próxima seção). A ponta da seta sempre ficará apontada para a classe mãe.
•

Relacionamento de realização

Um elemento realiza (implementa/executa) o comportamento que o outro elemento especifica.

Linha traceja com um triângulo na ponta, igual a herança, mas com a linha tracejada.

A figura abaixo apresenta o diagrama de classe.

- 13 -
 Figura 7 - Diagrama de classe – tipos de relacionamento.
Fonte: Elaborada pelo autor, 2018.

A seguir, discutiremos mais sobre o uso da herança apresentando os conceitos de generalização e

especializações.

1.3.2 Hierarquia e herança

A herança, como o nome já diz, está se referindo a algo que será herdado. Ao se referir a herança, no diagrama de
classes, temos dois tipos de classes: as filhas, ou especializações; e as classes mães/superclasses/generalizações.
A classe superior/mãe/superclasse deve conter atributos e métodos que são comuns aos seus filhos. Enquanto
que as classes filhas possuem métodos e atributos mais específicos.
Ao se declarar que uma classe está herdando outra, indicamos que os atributos e métodos da classe superior
serão acessíveis às classes filhas. Um exemplo bem simples é o caso de Pessoa, Pessoa Física e Pessoa Jurídica. Na
qual, alguns atributos são comuns, enquanto que outros exigem uma especificação. É possível observar a
herança na figura a seguir.

- 14 -
 Figura 8 - Diagrama de classe – herança.
Fonte: Elaborada pelo autor, 2018.

Ao se falar em herança, também falamos em polimorfismo. O polimorfismo indica que podemos possuir várias
formas/comportamentos diferentes para um mesmo método. Quando dizemos que um método possui uma
assinatura igual, estamos afirmando que teremos o mesmo nome, quantidade, ordem e tipo de parâmetros.
Entretanto, tem-se a seguinte diferença. Clique nos itens e confira quais são elas.

Polimorfismo estático

(Sobrecarga ou overloading) - nome do método igual com parâmetros diferentes. A decisão é feita
no tempo de compilação de acordo com os parâmetros. Consiste basicamente em criar variações
de um mesmo método, ou seja, a criação de dois, ou mais métodos, com nomes totalmente iguais
em uma classe com a diferença dos parâmetros: na quantidade, tipo e ordem.
•

Polimorfismo dinâmico

(Sobrescrita/inclusão/por herança/redefinição/overriding) - nome e parâmetros iguais. Ou seja, a

subclasse redefine o método da superclasse.

Vejamos um exemplo de um diagrama de classes de um sistema acadêmico simplificado (figura a seguir). Para
começar, temos uma herança de Aluno para Pessoa e Professor para Pessoa. Perceba que todos os atributos em
comum (ambos) são fixados em Pessoa, enquanto que as especializações são mantidas em cada classe filha. O
mesmo conceito é aplicado para os métodos, porém, para facilitar a visualização do diagrama, os omitimos.
Uma leitura do diagrama poderia ser assim: uma Disciplina Oferecida possui turma, horário, sala juntamente
com uma única Disciplina e um professor associado. Na qual, na volta (leitura inversa à seta), poderia ficar: um
professor está associado a nenhuma, ou várias Disciplinas Oferecidas e uma Disciplina pode estar em uma
Disciplina Oferecida, ou em várias. Já a classe Aluno se relaciona com uma Disciplina Oferecida por meio da

classe AlunoDisciplina. Essa classe foi criada, pois a relação de Aluno e Disciplina Oferecida seria de n para n (*..

- 15 -
classe AlunoDisciplina. Essa classe foi criada, pois a relação de Aluno e Disciplina Oferecida seria de n para n (*..
*) e gostaríamos de incluir o conceito (por meio da ponderação das notas obtidas) que o aluno tirou na
disciplina. O aluno terá o registro de suas notas por meio da classe Notas. Note que o relacionamento entre
AlunosDisciplina e Notas é uma composição, ou seja, não faz sentido as Notas existirem sem a instância de
AlunoDisciplina.

Figura 9 - Diagrama de classe – sistema acadêmico simplificado

Fonte: Elaborada pelo autor, 2018.

Quanto mais você conhecer sobre os componentes que o diagrama oferece, mais detalhes poderão ser incluídos
e, em consequência, uma melhor abstração.

- 16 -
1.4 Modelos dinâmicos
Vimos, anteriormente, um exemplo de um modelo estático o diagrama de Classes. Nele não estávamos
interessados em saber como os objetos vão trocar mensagens e se interagir, apenas nos preocupamos com a
estrutura. Porém, é interessante que também possamos ter uma outra visão do sistema, mas, para isso, devemos
escolher diagramas que permitam visualizar o tráfego de mensagens e a interação entre si. Pense nos diagramas
da UML como complementos uns dos outros. Não existe uma regra de quais diagramas utilizar, a escolha
dependerá do tipo de sistema, bem como da necessidade de se visualizar alguma informação.
A seguir, conheceremos alguns modelos mais utilizados que permitem a visualização dinâmica das informações.

1.4.1 Modelo de sequência

É um diagrama de interação que captura o comportamento de um único cenário mostrando interação entre
objetos, atores e mensagens, que são trocadas dentro do caso de uso. Ele tem como objetivo complementar o
diagrama de classes, pois verifica a troca de mensagens entre os objetos (GUEDES, 2011). O diagrama possui dois
eixos: horizontal (objetos envolvidos - lifeline) e vertical (tempo em que a ação ocorre) que é representado por
uma linha tracejada (linha de vida), conforme a figura a seguir.

Figura 10 - Diagrama de Sequência – Classe Aluno.

Fonte: Elaborada pelo autor, 2018.

No exemplo da figura acima, temos uma instância aluno (objeto) da classe Aluno, que será um lifeline. Já a linha
tracejada, abaixo do objeto, será a linha de vida, ou, simplesmente, o tempo de vida, que o objeto possui dentro
da aplicação.
A figura a seguir apresenta um possível cenário a qual o cliente deseja comprar produtos pela internet. Ao olhar
no lifeline (horizontal) temos um ator (cliente), a interface web do site de compras, o controlador da página web
e uma classe chamada Carrinho de Compras. Os objetos se comunicam por meio de mensagens (setas). Também
é possível observar mensagens de retorno que é o caso da instância car01 retornar ao controlador uma
mensagem de adicionado com sucesso. Outro recurso interessante é o fragmento de interação Efetuar Pagamento
, o texto “ref” indica referido e quer dizer que para simplificar o nosso diagrama estamos referenciando outro
diagrama de sequência. Por outro lado, o alt é uma alternativa que possui uma condição entre colchetes.

- 17 -
 Figura 11 - Diagrama de sequência – exemplo de compra da internet.
Fonte: Elaborada pelo autor, 2018.

Vimos que é por meio do diagrama de sequência que é possível observar a troca de mensagens entre os artefatos
ao longo do tempo e, para complementá-lo, podemos utilizar o próximo diagrama, que é o modelo de estado. Por
meio dele podemos definir um conjunto de estados respondendo a uma série de eventos.
Assista ao vídeo abaixo e veja como projetar, a partir de um diagrama, um sistema de vendas de ingressos online.
https://cdnapisec.kaltura.com/p/1972831/sp/197283100/embedIframeJs/uiconf_id/30443981/partner_id
/1972831?iframeembed=true&playerId=kaltura_player_1546675090&entry_id=1_uvzaj6dw
Dando sequência aos seus estudos, aprenda, no próximo tópico, sobre o modelo de estado.

1.4.2 Modelo de estado

O modelo tem como objetivo mostrar o comportamento de um elemento/estado, por meio de um conjunto finito
de possibilidades (transições). Geralmente, esse elemento é uma instância de uma classe. Logo, conhecer o
estado é saber como o objeto está no momento, no qual podem: esperar a ocorrência de eventos, satisfazer uma
condição, executar alguma atividade, etc. O exemplo da figura a seguir é uma configuração de um forno micro-
ondas. Nele, os retângulos-arredondados representam os estados.
Vejamos o estado inicial (Aguardando), a primeira parte, do retângulo, indica a situação na qual se encontra o
estado, já, na segunda parte, indica as ações que serão realizadas ao entrar no estado em si. Uma rápida leitura
do diagrama seria: ao iniciar, entraríamos no estado (Aguardando), pois não há nenhuma restrição do ponto
inicial para ele. Mas, ao entrar no estado (Aguardando) realizaríamos a tarefa de mostrar o relógio no display do
micro-ondas até que alguém selecione a potência média ou total.
Dependendo de qual potência selecionada cairíamos em seu respectivo estado. Imagine que o usuário tenha
pressionado potência total. Nesse caso, a potência seria alterada para 600, em seu conjunto de ações. Estando
neste estado, aguardaríamos a mudança de estados após a ocorrência de um novo estímulo e, assim,
sucessivamente. Perceba que temos poucas opções de estímulo (conjunto finito) para mudar para outros
estados. Logo, identificar os possíveis estímulos garantem que haja um rígido controle sobre cada estado e, em
consequência, construir modelos mais robustos.

- 18 -
 Figura 12 - Modelo de estado – configuração de um micro-ondas.
Fonte: SOMMERVILLE, 2011, p. 96.

Esse diagrama é bastante semelhante ao próximo modelo, o modelo de atividade. Vamos acompanhar em
seguida.

1.4.3 Modelo de atividade

O modelo de atividade enfatiza a sequência das atividades (conjunto de ações) e suas condições para determinar
o comportamento de baixo nível (detalhista) de um algoritmo, método, ou sistema completo. O modelo é
bastante semelhante aos fluxogramas, nos quais é possível definir, de forma gráfica, cada passo (fluxo de
controle) de uma série de ações (GUEDES, 2011).
O diagrama de atividades conterá diversas ações e poderá representar dois tipos de fluxo: o de controle e o de
objetos. As ações que compõem uma atividade são representadas por nós. Graficamente, o nó é um retângulo
com cantos arredondados contendo um resumo de uma ação (verbo), conforme pode ser visto na figura a seguir.

Figura 13 - Modelo de atividade – exemplo de um nó.

Fonte: Elaborada pelo autor, 2018.

Dando sequência, o fluxo de controle é uma linha que conecta os nós, na qual uma seta aponta para o próximo
item da sequência. Esse conector pode associar alguma descrição, condição ou restrição. Veja no exemplo da
figura a seguir, a conexão entre dois nós. No primeiro nó o usuário informa seu CPF e, na sequência, o próximo
nó realiza uma consulta ao SPC.

- 19 -
 Figura 14 - Modelo de atividade – conexão entre dois nós.
Fonte: Elaborada pelo autor, 2018.

Com essa representação, podemos inferir uma troca de mensagens entre as ações e uma sequência que é
definida por meio do direcionamento da seta. No entanto, para criar condições mais complexas podemos utilizar
uma estrutura de decisão (condicional) que é feita pelo “nó de decisão”. Esse nó divide o fluxo do diagrama para
atender uma certa condição e a sua representação se dá por um losango. Ao reformular o exemplo da figura
anterior, introduzindo a verificação do CPF, é checado se ele está digitado de forma correta, acrescentamos o nó
de decisão com as condições de guarda (dentro de colchetes).

Figura 15 - Modelo de atividade – estrutura de decisão.

Fonte: Elaborada pelo autor, 2018.

Note na figura acima, a existência de um círculo preenchido no final da condição do “CPF inválido”. Ele
representa o fim do fluxo, ou seja, para aquele ramo (fluxo), ao identificar um CPF inválido, nenhum tratamento
será realizado e o algoritmo teria seu término ali (só o algoritmo, não toda a atividade).

- 20 -
VOCÊ QUER LER?
Para você que gostou de modelar em UML, um ótimo livro para se aprofundar é o do cientista
da computação Gilleanes Guedes, “UML 2 Uma Abordagem Prática”. Ele traz diversos exemplos
dos diferentes diagramas da UML. A linguagem utilizada é bastante simples e fácil de
compreender. No final do livro é possível ver a evolução de um sistema, ao se utilizar os
diversos diagramas da UML (GUEDES, 2011).

Na próxima figura, introduziremos um diagrama de atividades que tem como objetivo criar um novo cartão de
crédito para um cliente e, para isso, utilizaremos diversas outras estruturas desse modelo. A primeira é a
partição de atividade, ela representa a atividade passando por diversos departamentos de uma empresa,
facilitando a visualização da ação de cada departamento. Pode-se dizer que ela nos lembra raias de uma piscina,
em nosso caso, temos duas partições: uma é o cliente e o outro é o cadastro.
Na primeira partição (cliente) temos um círculo preenchido indicando o início da atividade e um círculo com um
‘x’ ao centro, indicando o fim de toda a atividade. Já na segunda partição, “cadastro”, logo após a verificação do
CPF, introduzimos um nó de bifurcação (barra), no qual o fluxo é dividido paralelamente para duas novas ações:
“consultar CPF no SPC”; e “consultar CPF em instituições financeiras”. Perceba que após a execução das ações é o
fluxo concorrente é mesclado para um fluxo único, que, aqui, é o nó de união.
Em sequência, ao verificar que o cliente não possui nenhuma pendência, é executada uma ação de chamada de
comportamento. Mas, neste caso, não sabemos como é feita a atividade “Gerar cartão de crédito”, por esse
motivo que o nó possui uma notação diferente, como uma espécie de tridente. Por fim, tem-se o evento de tempo,
que aguarda um certo tempo para dar continuidade as ações. Ele é representado por uma espécie de ampulheta.

- 21 -
 Figura 16 - Modelo de atividade – exemplo de uma solicitação de cartão de crédito.
Fonte: Elaborada pelo autor, 2018.

Um sistema que trabalha de forma solitária é bastante difícil, pois em sua grande maioria, os sistemas se
relacionam com outros sistemas, ou diversos outros componentes. Para que isso ocorra são definidas as
interfaces. Vamos entender isso melhor a seguir.

1.4.4 Especificação de interface

Em qualquer processo de projeto, temos que definir a interface (comunicação) entre os diversos componentes
do projeto. O motivo de se definir uma interface é que você permitirá que outros sistemas, componentes, ou
classes, possam ser projetados em paralelo (SOMMERVILLE, 2011).
Vejamos um exemplo de interface (entre classes) na figura a seguir. Definimos uma interface UsuarioDAO (Data
Access Object), para registrar as funcionalidades que queremos implementar, relacionadas à manipulação de
banco de dados da classe Usuário. Note que, na interface inserimos um estereótipo <<interface>> e definimos
apenas a assinatura dos métodos, isto é, na interface não criamos o corpo do método, pelo contrário, definimos
somente a assinatura (retorno, nome, parâmetros) para que outra classe a implemente (crie o corpo do método).
Por outro lado, a classe UsuarioDAOImpl implementará (veja a notação da seta de realização) a nossa interface,
essa classe terá que criar o corpo de cada assinatura criada na interface, definindo as conexões com o banco, os
sqls, assim por diante.

- 22 -
 Figura 17 - Definição de uma interface entre classes – persistência de dados.
Fonte: Elaborada pelo autor, 2018.

Vejamos o impacto de se criar uma interface. Imagine que o prazo para o desenvolvimento do sistema está
bastante crítico e que teremos que realizar tarefas paralelas. Uma equipe ficou destinada para criar as regras de
negócio (UsuarioService) e, posteriormente, desejam que o objeto usuário seja salvo no banco (UsuarioDAOImpl
). Entretanto, note que relacionamos diretamente o UsuarioService a interface, perceba que com essa ligação a
classe service já possui acesso as funções básicas de persistência dos dados.
Nesse momento, não me importa se o corpo dos métodos está finalizado, mas poderemos imaginar que para
salvar os dados de usuário só basta chamar os métodos que estão na interface. Logo, permitindo que duas
atividades possam ser realizadas em paralelo. Assim, uma equipe precisa saber quais são os métodos que ela
deverá chamar (UsuarioDAO) e a outra implementa, de fato, o que os métodos vão fazer (UsuarioDAOImpl).
Quando criamos uma estrutura assim, dizemos que a classe está menos acoplada, o que significa que se
realizarmos algumas mudanças dentro da classe UsuarioDAOImpl não será refletida de fato para UsuarioService.

Síntese
Chegamos ao final deste capitulo! Estudamos, aqui, a parceria entre a orientação a objetos e a notação UML, que
torna os projetos de softwares mais eficientes, antevendo seu comportamento antes de se começar a escrever as
linhas de código. Vimos que, por meio disso, podemos modelar um sistema obtendo diferentes visões e
perspectivas. Assim, compreendemos os requisitos e as suas relações, possibilitando criar aplicações de forma
efetiva. Essa parceria entre POO e UML tem sido bem aceita no mercado, como uma boa solução para a
engenharia de software.
Neste capítulo, você teve a oportunidade de:
• recapitular o conceito de OO, para o qual apresentamos os seus pilares (Encapsulamento, Herança e
Polimorfismo) e sua facilidade de mapeamento, devido a seus conceitos estarem diretamente ligados ao
nosso cotidiano;

• conhecer a UML, que é amplamente utilizada, independentemente do processo de desenvolvimento

- 23 -
 • conhecer a UML, que é amplamente utilizada, independentemente do processo de desenvolvimento
adotado, como ágeis ou ortodoxos;
• aprender as anotações usadas em seus principais diagramas. Vimos que os diagramas mais utilizados em
uma modelagem de software são: diagrama de casos de uso, classes, sequência, modelo de estado e de
atividades.

Bibliografia
ASTAH PROFESSIONAL. Download. Portal Astah, 2018. Disponível em: <http://astah.net/download>. Acesso
em: 25/11/2018.
GALLOTTI, G. M. A. Qualidade de Software. Bibliografia Universitária Pearson. São Paulo: Pearson, 2017.
GUEDES, G. T. A. UML2 – Uma Abordagem Prática. 2. ed. São Paulo: Novatec, 2011.
LEITE, M. Técnicas de programação: uma abordagem moderna. São Paulo: Brasport, 2006.
MEDEIROS, E. Desenvolvendo Software com UML 2.0 Definitivo. São Paulo: Pearson Makron Books, 2004.
PFLEEGER, S. L. Engenharia de Software - Teoria e Prática. 2. ed. São Paulo: Pearson Addison Wesley, 2004.
PRESSMAN, R. S. Uma Abordagem Profissional. 8. ed. São Paulo: Bookman, 2016.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Addison Wesley, 2011.
SORKIN, A. A Rede Social. Direção: David Fincher. Produção: Scott Rudin; Dana Brunetti; Michael De Luca; Ceán
Chaffin. cor; 121 min. Estados Unidos, 2010.
SILBERSCHATZ, A. Sistema de Banco de Dados. 6. ed. Rio de Janeiro: Elsevier, 2016.
VAUGHN V.; STERN, J. Os estagiários. Direção: Shawn Levy. Produção: Vince Vaughn; Shawn Levy. 119 min. Cor.
Estados Unidos, 2013.

- 24 -