Modelagem

Utilizando a
UML
©2018 Copyright ©Católica EAD. Ensino a distância (EAD) com a qualidade da

Apresentação 

Fonte: https://goo.gl/bTYwhL

Nesta aula, serão revistos alguns assuntos que

estudou na disciplina de Engenharia de Software.
Um deles é a modelagem utilizando a UML –
Unified Modeling Language. Ela é composta de
um conjunto de diagramas que permitirá a você
representar e modelar os diversos contextos que
envolvem o desenvolvimento de um sistema.
Cada um dos componentes deve ser detalhado,
em conformidade com as reais necessidades do
cliente. Portanto, para que um implementador
 possa construir os componentes, é muito
importante detalhá-los com a maior riqueza de
informações possível.

Serão revistos também alguns conceitos

importantes de Orientação a Objetos, para que os
mesmos, conciliados com a UML, possam
permitir a você analisar e projetar o software
que o cliente necessita.

Bons estudos!

Áudio 

0:00 / 1:21
©2018 Copyright ©Católica EAD. Ensino a distância (EAD) com a qualidade da

Conteúdo 
Introdução
Conforme estudou na disciplina de Engenharia de Software,
a UML – Unified Modeling Language é uma especificação que
foi criada por Grady Booch, James Rumbaugh e Ivar Jacobson,
que a definem como uma linguagem-padrão, que pode ser
utilizada na elaboração da estrutura dos projetos que
envolvem software, representando visualmente o seu
funcionamento, especificando a construção por meio de
artefatos documentados que tenham foco em sistemas mais
complexos de software a serem desenvolvidos.

Atenção, a UML é uma linguagem de modelagem, e não uma

metodologia de desenvolvimento. Isso significa que ela não
dirá para você "o que fazer" ou "como projetar um sistema",
mas o ajudará a visualizar seu projeto e a comunicação entre
os objetos que o compõem. Basicamente, a UML permite que
os desenvolvedores visualizem o seu produto em diagramas
padronizados.

Como a UML é uma linguagem, ela possui símbolos próprios,

vocabulário e permite a comunicação de informações,
sentidos, ideias úteis, de forma gráfica e textual. É de fácil
acepção e possui um padrão de comunicação, na qual todos
aqueles que se dispõem a aprendê-la são capazes de se
comunicar de forma eficaz.

A utilização dessa linguagem-padrão economiza tempo,

dinheiro e diminui riscos, pois a concepção de um projeto se
torna mais eficiente, em vez de partir diretamente para o
código. A correta conjunção desses aspectos permite
medição e controle eficiente do projeto. Portanto, veja que
compreender a UML é de suma importância para a indústria de
desenvolvimento de software!
A UML permite a visualização de modelos por parte dos
envolvidos no projeto, estimula a interação de novos membros
com outros já participantes do desenvolvimento, além de ser
capaz de reter o conhecimento, quando alguém deixa o
projeto. A utilização da modelagem facilita a comunicação
entre os envolvidos, na medida em que os símbolos da UML
possuem uma semântica própria, bem definida e de fácil
compreensão. Assim, os analistas de requisitos, projetistas de
software, programadores e gerentes de projetos conseguem
dirimir as diferenças de entendimento do domínio do
problema por meio dos modelos existentes na UML. Com ela,
conseguimos especificar modelos de forma precisa, com
todas as informações necessárias para um completo
entendimento, sem espaço para duplicidade de conceitos.

As ferramentas UML trabalham de maneira padronizada, de

acordo com o que é definido na linguagem. Isso permite a
utilização dos mesmos modelos em várias ferramentas CASE
diferentes. Essas ferramentas geram códigos em diversas
linguagens de programação, como Java, C++, e até tabelas de
banco de dados, por meio de mapeamento. Elas também
permitem a engenharia de produção, que consiste em
transformar modelo UML em código-fonte e também a
engenharia reversa. O que deve ficar claro é que a engenharia
reversa não leva a implementação para dentro do modelo, mas
apenas as declarações.

É muito importante que a equipe de desenvolvimento tenha

como manter seus artefatos (modelos), para que eles possam
servir de base para a medição do software, controle e também
comunicação, mesmo depois da implantação do sistema. A
UML também facilita esse processo de documentação.

Em julho de 2017, a versão disponível da UML era a 2.5, que

pode ser baixada na página da OMG – Object Management
Group . A OMG é um grupo formado por membros ao redor
do mundo, uma comunidade interessada em desenvolver e
integrar padronizações empresariais a respeito das
especificações UML, além de CORBA e BPMN, entre outras.

Por fim, devemos lembrar que a UML é uma linguagem

independente de processo de desenvolvimento. Além disso,
não é restrita à modelagem de software. Durante algum tempo,
ela pode, inclusive, ser utilizada em outros domínios, como por
exemplo, a modelagem de processos de negócio, embora
atualmente já exista uma linguagem específica para isso.

A seguir, a Figura 1 contém uma visão dos diagramas que

compõem a UML 2.5. Observe com atenção!

Figura 1 – Taxonomia da Estrutura dos Diagramas

da UML.

Fonte: OMG Unified Modeling Language – versão 2.5 (disponível em:

http://www.omg.org/spec/UML/2.5/ )

Os diagramas que compõem a versão 2.5 da UML são:

Diagrama de Casos de Uso

Diagrama de Atividades
Diagrama de Classes
Diagrama de Comunicação
Diagrama de Componentes
Diagrama de Estrutura Composta
Diagrama de Implantação
Diagrama de Visão Geral de Interação
Diagrama de Objetos
Diagrama de Pacotes
Diagrama de Perfil
Diagrama de Máquina de Estados
Diagrama de Sequência
Diagrama de Tempo

Nesta disciplina, esses diagramas não serão abordados em

detalhes, visto que você já os estudou na disciplina de
Engenharia de Software.
 Para Refletir 

Conforme abordado anteriormente, existem vários

diagramas que podem ser utilizados para representar
diversas etapas do desenvolvimento de sistemas.

Quando estamos projetando um sistema, as

funcionalidades são representadas por casos de uso e
os atores que os utilizam. Na sequência, temos as
classes, com os seus atributos e métodos, que são
utilizadas para representar os cenários dos casos de uso
e suas operações. Qual é o diagrama que deve ser
utilizado para representar esse cenário?

Os componentes do diagrama de caso de uso são os atores,

os casos de uso, os seus relacionamentos e a fronteira do
sistema, portanto, ele representará os casos de uso e atores.
Já, o diagrama de classes tem como componentes as classes
com seus atributos e métodos e os relacionamentos entre as
classes. Ela representará os objetos que estão agrupados em
classes que pertencem ao sistema que está sendo
desenvolvido.

Princípios Fundamentais de
Modelagem
Para que você seja capaz de compreender conceitos sobre
abstração e níveis de abstração, revisaremos também os
blocos que compõem a UML, envolvendo itens,
relacionamentos e diagramas. A seguir, são abordados itens
estruturais (classe, objeto, atributos, operações, visibilidade,
encapsulamento, interface, casos de uso e artefato), itens
comportamentais (interação, a máquina de estado e a
atividade), itens anotacionais e itens de agrupamento.

Abstração
A abstração é um conceito inerente ao desenvolvimento do
software como um todo. Ela é amplamente utilizada e não
restrita apenas ao paradigma de Orientação a Objetos. É uma
habilidade que a maioria dos stakeholders aplica em algum
momento do desenvolvimento do sistema, mesmo de maneira
intuitiva.

Em linhas gerais, no âmbito do desenvolvimento de software,

abstração consiste na capacidade de se concentrar nos itens
essenciais a respeito de um problema, deixando de lado os
detalhes, a fim de encontrar a melhor solução para resolver
aquele problema.

Começamos a aplicar a abstração no momento em que o

cliente/usuário começa a expor seu problema. Ele fala de suas
dificuldades e de como o sistema poderia ajudá-lo a melhorar
o seu trabalho. Estamos empregando a abstração enquanto
pensamos, em alto nível, em como resolver aquele
determinado problema. Neste momento, a nossa preocupação
está destinada apenas aos quesitos essenciais que auxiliariam
na resolução do problema relatado pelo usuário.

Níveis de Abstração
O processo de abstração continua à medida que
aprofundamos o nosso conhecimento sobre a realidade do
usuário. Começamos em um plano mais geral e depois vamos
aprofundando o nível de abstração, pois vamos acrescentando
mais detalhes específicos, a cada vez que pensamos sobre
aquele problema. Este processo de refinamento faz com que o
nosso entendimento sobre aquele assunto evolua com o
passar do tempo. Assim, dependendo do nível de abstração,
conseguimos caracterizar o problema inicial com mais ou
menos detalhes, aumentando nossa capacidade de encontrar
a melhor solução para a satisfação do usuário.

Elementos da UML
Agora que aprendemos o que é abstração, podemos aplicar
esse conhecimento para compreender melhor a UML.
Segundo Booch, Rumbaugh e Jacobson  (2005), para que
tenhamos capacidade de formar um modelo conceitual,
precisamos compreender inicialmente quais são os blocos de
construção básicos da UML. Esses blocos de construção
envolvem os itens, os relacionamentos e os diagramas. A
seguir iremos nos aprofundar nos itens.

Itens
Os itens equivalem às abstrações do domínio de um problema.
Essas abstrações devem ser identificadas pela equipe de
projeto, para que sejam colocadas no modelo UML. Veremos a
existência de quatro tipos de itens que podem ser usadas na
UML: itens estruturais, itens comportamentais, itens de
agrupamentos, e itens anotacionais.

Itens Estruturais
Itens estruturais são aqueles que dizem respeito à estrutura do
sistema. São as partes estáticas, representam aqueles
elementos fundamentais, conceituais, que podem ser
representados fisicamente. Os itens estruturais são chamados
de classificadores.

a) Classe
O primeiro item estrutural que veremos é a classe. As classes
são os itens mais importantes de um sistema orientado a
objetos. Ela pode ser encarada como uma descrição, um
modelo, em que podem ser criados vários objetos. Essas
classes são possuidoras de atributos, operações e
relacionamentos semelhantes, e que detêm uma mesma
semântica. Em um primeiro momento, na análise, toda
entidade que for relevante para o domínio do problema é uma
classe em potencial, inclusive atores que interagem com o
sistema.

No decorrer do desenvolvimento, são descobertas várias

outras classes. A gama de classes de um sistema não está
restrita a entidades. Podemos utilizar, como exemplo de
classe, um carro. A classe Carro possui características
comuns como cor, marca e modelo que podem ser
classificados como atributos. Também possui operações
comuns, como ligar, desligar, trocar marchas, entre outras.
Graficamente, podemos representar uma classe como um
retângulo apenas com seu nome dentro, desta maneira:
 Figura 2 – Classe carro

Outra maneira, mais completa, de representar uma classe na

notação UML, é por meio de um retângulo dividido em três
partes. Na parte de cima está localizado o nome da classe, no
centro da classe estão relacionados os atributos e na parte
inferior da classe estão listadas as operações (métodos). Uma
classe tem maior significância na UML se estiver conforme
apresentada na Figura 3, diferentemente do primeiro exemplo,
no qual estão suprimidos os nomes dos atributos e métodos.

Figura 3 – Classe Carro

Os nomes são os identificadores das classes. Para não haver

conflitos, seu nome deve ser único em um pacote – o conceito
de pacote será visto mais à frente. Preferencialmente, um
sistema não deve possuir classes com nomes repetidos,
mesmo que estejam em pacotes diferentes. Isso porque pode
haver problema de entendimento por parte dos
desenvolvedores usuários das classes. Os nomes das classes
podem ser classificados como nomes simples e nomes
qualificados. São simples quando são apresentados de forma
única, e qualificados quando apresentados antecedidos dos
nomes dos pacotes.

Nome simples: Carro

Nome qualificado: veículo:Carro

Geralmente, os nomes de classe são sequências de
caracteres, substantivos ou expressões breves, oriundos do
domínio do problema. São documentadas com o primeiro
caractere maiúsculo seguido dos outros em minúsculos.
Quando são nomes compostos, a primeira letra dos nomes
subsequentes também é maiúscula, seguida das outras letras
minúsculas. Observe os exemplos a seguir:

Carro, Automovel, CarroPasseio, AutomovelCarga

b) Objeto
O objeto é a representação física de uma classe na memória
do computador. Podemos dizer que um objeto é a instância de
uma classe. Enquanto a classe é uma abstração, uma
descrição responsável por agrupar atributos e
comportamentos, o objeto é a expressão concreta,
manifestação tangível dessa classe na memória.

Por meio do objeto, temos condição de acessar os atributos e

métodos definidos na classe. Caso o objeto não tenha sido
criado na memória, não é possível acessar os
comportamentos e as características definidas na classe, a
não ser que esses sejam definidos como estáticos, o que
estudará mais adiante, quando se tratar especificamente de
atributos e métodos.

Para visualizar o uso dos objetos, podemos utilizar, por

exemplo, a classe Carro. Vamos supor que essa classe possua
um atributo denominado chassi. Quando criarmos um objeto
da classe Carro, podemos preencher o atributo chassi, por
exemplo, com o valor 9GXZ06; assim, podemos identificar
aquele objeto específico, enquanto que a classe continuará
sendo a descrição.

c) Atributos
Um atributo pode ser entendido como uma variável da classe,
uma propriedade, um lugar capaz de reter valores. Ali você
consegue verificar o estado do objeto, por meio dos seus
respectivos valores. Não há limites para o número de atributos
de uma classe, ela pode possuir vários, ou mesmo não ter
nenhum.
Um atributo pode ser declarado juntamente com o seu tipo.
Isso significa que ele só conseguirá armazenar valores daquele
tipo. Por exemplo, não será possível armazenar
valores String em um atributo que seja do tipo inteiro.

Se voltarmos à figura da classe Carro, no compartimento do

meio, poderemos observar os atributos cor, marca e modelo.
No primeiro momento, quando iniciamos a análise, o nível de
abstração ainda é alto; assim, podemos optar por não colocar
os tipos dos atributos e deixar nosso modelo mais genérico.
Podemos colocar os tipos depois. Na medida em que
aprofundamos a análise, o entendimento sobre o domínio do
problema vai aumentado, o nível de abstração vai diminuindo e
então podemos realizar refinamentos sucessivos em nossos
modelos, para deixá-los cada vez mais completos.

Os atributos são declarados na classe, mas, em regra, para

colocarmos valores neles, é necessário que tenhamos uma
instância da classe, ou seja, isso deve ser feito por meio de um
objeto. Assim, atributos da mesma classe terão valores
diferentes quando forem de objetos diferentes. Cada instância
de atributo pertence a uma determinada instância da classe.
Em determinado momento podemos observar o estado do
objeto, que consiste em visualizarmos quais são os valores
que ele possui em seus atributos naquele momento.

Os atributos podem ser definidos como estáticos.

Diferentemente da regra explanada acima, um atributo estático
pertence à classe. Assim, todos os objetos daquela classe
compartilham o valor daquele atributo e não é necessário que
se tenha uma instância da classe – objeto em memória – para
podermos acessar o valor desse atributo.

Podemos citar como exemplo uma classe aluno, que contém

os atributos matrícula, nome, endereço e telefone. Todos os
objetos que pertencem a essa classe sempre terão esses
atributos, portanto, eles são estáticos. O que modifica é
quando instanciamos diferentes objetos. Na primeira
instanciação, temos um aluno que possui os seguintes valores:
matrícula= 12345, nome-Paula, endereço=SQN 705, bloco A
apto 701 e telefone=998761234. Na segunda instanciação,
teremos os mesmos atributos com valores diferentes, como
apresentado a seguir: matrícula= 135432, nome-Roberto,
endereço=SHS 307, casa 12 e telefone=981237131.
d) Métodos/Operações
Operações também são conhecidas como métodos ou
mensagens. Depois de definirmos a regra de negócio e o
correto fluxo dos acontecimentos, devemos modelar as
operações nas classes. Os algoritmos, códigos-fonte
propriamente ditos, serão, obviamente, colocados apenas na
programação efetiva. Mas, na modelagem, conseguimos expor
as definições e a dinâmica do funcionamento. Nela somos
capazes de prever os comportamentos das operações, definir
o fluxo das informações e, assim, melhoramos o
entendimento, possibilitando que a solução seja discutida com
outros projetistas. Desta forma, enviaremos ao programador
algo já definido, sendo necessário apenas preparar
efetivamente os códigos.

A vantagem dessa abordagem é que documentamos a

solução em um lugar diferente da implementação,
possibilitando o acesso mais rápido a uma solução que será
mais difundida entre os envolvidos no projeto.

As operações podem, ou não, retornar algum valor. Essa

questão deverá estar explícita na declaração do método,
implementado em uma linguagem de programação orientada a
objetos. Essa prática também deve ser levada em
consideração ao definir se a operação terá ou não parâmetros,
que são as variáveis existentes apenas no escopo do método.
Quanto mais detalhes um modelo possuir, melhor será para a
equipe de implementação.

Na Figura 3, referente à classe Carro, é possível observar, no

compartimento inferior do retângulo, os métodos ligar(),
desligar() e trocarMarchas(). Repare que o projetista, ao
modelar, já previu alguns comportamentos da classe Carro. O
projetista será capaz de pensar em novas operações com o
processo de refinamento sucessivo da análise, bem como os
tipos de retorno e também os parâmetros.

Os métodos também podem ser estáticos e seu

funcionamento é semelhante ao atributo estático no que
concerne a sua utilização. Não é necessário que tenhamos
uma instância da classe para conseguirmos acessar um
método estático. Isso porque ele será um método da classe;
assim, não é preciso um objeto na memória para chamarmos
este método.

Da mesma forma como mostramos os atributos de uma

classe, vamos supor que em uma classe exista o método
inserir-aluno(), quando for necessário persistir os dados de um
aluno acionamos esse método passando os seguintes valores
inserir-aluno(12345, Paula, SQN 705, bloco A apto 701,
998761234). Os valores apresentados entre os parênteses
indicam os atributos que ele manipulará para realizar aquilo
que foi definido para o método, ou seja, criar um objeto aluno
dentro da base de dados, persistindo essa informação para
que ela esteja disponível quando necessária.

e) Visibilidade
Outro conceito importante quando falamos de classes é o de
modificador de visibilidade. Geralmente, essa definição vale
para os classificadores que contêm instâncias. Serve para
definirmos qual será a política de visualização, principalmente
dos atributos e métodos. Utilizamos um modificador com
frequência em classes e interfaces. Eles estão divididos em
quatro níveis.

Public (público): significa dizer que os itens classificados

com esse modificador são visíveis por todas as classes
do sistema. O modificador public utiliza o símbolo +.
Protected (protegido): itens com modificadores
protegidos são aqueles que podem ser visualizados por
suas subclasses. O modificador de
visibilidade protected utiliza o símbolo #.
Private (privado): o modificador privado restringe a
visualização dos itens apenas à própria classe. O
visualizador private é representado pelo símbolo –.
Package (pacote): a visibilidade package faz com que os
itens classificados com esse modificador sejam
visualizados apenas dentro do pacote em que a classe,
detentora desses classificadores, está localizada. A
visibilidade pacote é representada pelo símbolo ~.

Observe, na Figura 4, uma classe modelada com a definição

dos tipos de atributos, tipos de retornos dos métodos e
modificadores de visibilidade.
 Figura 4 – Classe carro.

f) Encapsulamento
Agora, que já falamos sobre classes, métodos e atributos,
temos condições de entender melhor sobre este importante
conceito. O encapsulamento consiste na habilidade de
esconder os detalhes. A classe encapsula outros itens
fundamentais para o seu funcionamento: os atributos e os
métodos.

Em termos gerais, atributos são as características da classe e

as operações ou métodos ditam o comportamento da classe.
No mundo Orientado a Objetos, um sistema funciona com a
interação de diversas classes. A comunicação é feita por meio
de classes que requerem serviços oferecidos por outras
classes. A correta conjunção dessas chamadas possibilita ao
sistema atender ao seu propósito.

O encapsulamento é responsável por fazer a classe possuir

fronteiras específicas para a sua interconexão com as outras
classes. Assim, uma classe não tem acesso direto às
características de outra classe, ela apenas solicita ou oferece
um serviço específico, a fim de fazer uso do seu
comportamento. Segundo Pressman  (2006), o
encapsulamento oferece algumas vantagens ao
desenvolvimento de sistemas, conforme exposto a seguir:

Os detalhes internos, a implementação das

características e comportamentos ficam escondidos do
mundo exterior. Com isso, há uma redução dos efeitos
colaterais devido a ocorrências de modificações.
A estrutura de dados, atributos e as operações, métodos,
são alocados em uma única entidade denominada
classe. Essa prática facilita bastante a reutilização da
 classe.
As fronteiras existentes entre os objetos são
simplificadas. Um objeto que solicita um serviço não
precisa conhecer como aquela operação foi
implementada. O acoplamento entre as classes tende a
ser reduzido.

g) Interface
As interfaces são itens de estrutura em que é estabelecida
uma espécie de contrato entre elas e as classes. São tipos
abstratos de dados que apenas definem comportamentos;
portanto, são compostas por declarações de métodos. Pode
ser visualizada como uma classe totalmente abstrata.
Diferentemente das classes normais, não é possível colocar
implementações concretas dentro das interfaces.

O fato é que as classes implementam as interfaces. Significa

dizer que uma classe vai colocar os algoritmos dentro das
operações definidas nas interfaces. Essas classes também
podem ter outras operações, não definidas nas interfaces, o
importante é que todos os métodos definidos nas interfaces
devem possuir escopo na classe implementadora. Algumas
dessas classes podem representar entrada ou saída de
informações no sistema, sendo consideradas como abstratas.

Outra característica importante das interfaces é que elas não

possuem atributos, com exceção de esses atributos serem
constantes. Uma constante é um atributo com um valor que
não é possível modificar. Por exemplo, se você tem em seu
sistema um valor de sequência de caracteres, ou inteiro, ou
outro tipo qualquer que é utilizado em vários locais e não dá
ao usuário a possibilidade de ele ser alterado, você pode
colocar esse valor em uma constante e, para utilizá-la, basta
chamar a referência da constante. Essa prática evita que
valores absolutos fiquem espalhados pelo código, facilitando o
controle e a manutenção do sistema.

Uma interface é caracterizada na UML, da mesma forma que

uma classe, porém, acrescida do estereótipo de interface.

Estereótipo é um mecanismo para estender a UML. Por meio

dele, é possível classificar elementos semelhantes. Assim, os
criadores da UML entendem que também é possível a
utilização desta notação em outros contextos diferentes da
engenharia de software.

O estereótipo pode ser identificado por meio dos sinais

duplicados de maior e menor: <<nome_do_estereótipo>>.

Figura 5 – Interface.

Na Figura 5 você observou uma interface representada por um

retângulo, semelhante à classe, e com o
estereótipo <<interface>>. Porém, a interface também pode ser
representada de outra forma. Na Figura 6, observe como
representar uma classe que implementa uma interface, vista
em forma de círculo, usando a UML.

Figura 6 – Interface.

h) Casos de Uso
Um caso de uso é uma descrição, de maneira sequencial, das
ações a serem realizadas em uma determinada
funcionalidade. Na UML, um caso de uso é representado por
uma elipse com um nome, conforme a Figura 7.

Figura 7 – Caso de uso.

Perceba que um caso de uso é iniciado por um ator, alguém ou
outro sistema que interage com o caso de uso. Observe, na
Figura 8, como representar uma interação de um ator com um
caso de uso.

Figura 8 – Caso de uso.

Na Figura 8, temos a representação de um ator com o papel

de Funcionário que interage com o caso de uso Cadastrar
Cliente.

Neste momento, vale a pena falar de dois relacionamentos

importantes para o contexto de casos de uso. São os
relacionamentos de inclusão e extensão de caso de uso.

Inclusão de Caso de Uso

O relacionamento de inclusão de caso de uso consiste em
executar um caso de uso diferente, no momento em que um
primeiro está sendo executado. Uma determinada condição é
atingida durante a realização de um caso de uso. Quando essa
condição exige a realização de outro comportamento, definido
em outro caso de uso, o primeiro caso de uso não prossegue,
enquanto essa condição não for satisfeita, caracterizando um
relacionamento obrigatório.

Por exemplo, suponhamos que faremos um sistema de

controle de estoque, no qual, entre outras coisas, são
efetuadas vendas de produtos. No momento de realização da
venda, o sistema deve abrir uma opção de pesquisa para
encontrar o cliente que deve estar previamente cadastrado.
Esse comportamento de localizar o cliente não é
particularmente descrito no caso de uso realizar venda, mas,
sim, em um caso de uso particular. No entanto, sempre que
uma venda precisar ser efetuada, a funcionalidade de localizar
cliente, descrita em outro caso de uso, será executada.

A notação do relacionamento de inclusão de caso de uso é

parecida com a de relação de dependência, ou seja,
caracteriza-se por uma linha pontilhada com uma seta aberta
na extremidade. O sentido parte do caso de uso base para o
caso de uso que está sendo incluído, conforme pode observar
na Figura 9.

Figura 9 – Inclusão de Caso de uso.

Extensão de Caso de Uso

Enquanto o relacionamento de inclusão de caso de uso,
anteriormente abordado, caracteriza-se por ser obrigatório, a
extensão de caso de uso caracteriza-se por ser evitável. É um
caso de uso que chama ou não, dependendo do caso, a
funcionalidade de outro caso de uso, e isso não é obrigatório.

Levando em consideração o exemplo anterior, suponha que o

cliente não exista no cadastro. A opção de cadastrar o cliente
é disponibilizada para o vendedor. Ele pode chamar a
funcionalidade dali, ou pode cancelar a venda, ir até a
funcionalidade referente ao cadastro do cliente, e depois
voltar para a opção de realizar a venda. Repare que, de
qualquer forma, o vendedor precisará pesquisar o cliente para
realizar a venda. O relacionamento de extensão é
caracterizado por uma seta pontilhada e tem o sentido
contrário ao de inclusão, ou seja, o sentido é do caso de uso
estendido para o caso de uso base, conforme a Figura 10.
 Figura 10 – Extensão de Caso de uso.

i) Artefato
O artefato também é um item estrutural. Artefato é qualquer
elemento físico com informações a respeito do sistema
gerado pelos envolvidos no projeto. Por conta disso, um
artefato pode ser um modelo, um documento de caso de uso,
código-fonte, um arquivo com scripts de banco de dados, ou
seja, qualquer fonte de informações que seja relevante para o
sistema.

Figura 11 – Artefato.

Existem ainda outros itens estruturais, não menos importantes,

como as colaborações, classes ativas, componentes e nós. Os
três últimos são semelhantes a classes e, provavelmente, você
os verá com uma frequência muito menor do que os itens
abordados anteriormente. Por isso, não serão abordados com
detalhes.

Itens Comportamentais
Agora que já conhece os itens estruturais, conhecerá os
comportamentais. Como o próprio nome diz, esses itens são
responsáveis pelo comportamento do sistema. Podemos
chamá-los de partes dinâmicas do modelo. Eles indicam
ações, por isso seus nomes são representados pelos verbos.
Os principais itens comportamentais são
a interação, a máquina de estados e a atividade.
 A interação consiste nas mensagens trocadas entre os
objetos de um determinado assunto para atingir um
objetivo. É onde especificamos o comportamento de um
objeto. Na UML, uma interação tem o formato de uma
linha contínua com uma seta na extremidade junto com
o nome da operação, conforme a Figura 12.

Figura 12 – Interação.

A máquina de estados especifica os estados os quais um

objeto passa durante a sua vivência, bem como as
respostas aos eventos transcorridos por ele. O
comportamento de uma determinada classe, bem como
seu ciclo de vida, pode ser modelado utilizando a
máquina de estados. Graficamente, na UML um estado é
representado por um retângulo de cantos arredondados
e seu respectivo nome dentro do retângulo, conforme a
Figura 13.

Figura 13 – Máquina de Estados.

Outro item importante é a atividade. Ela dita a sequência, o

fluxo de trabalho executado por um determinado processo.
Um processo pode ser mapeado pelas suas atividades. Uma
atividade pode ser encarada como uma ação. Na UML, uma
atividade é simbolizada por um retângulo de cantos
arredondados com seu respectivo nome dentro do retângulo,
semelhante a um estado. O que os diferencia é o contexto em
que cada um atua.

Figura 14 – Atividade.
Itens de Agrupamento
Os itens de agrupamento são úteis para conseguimos manter a
organização de nosso sistema. A rigor, o principal item de
agrupamento usado pelos projetistas de software é o pacote.
Na medida em que o sistema cresce, há a necessidade de
organizá-lo de maneira eficiente, para manter um bom
entendimento e conseguir facilidade de manutenção. Sob a
ótica da execução propriamente dita, os pacotes não têm
influência, pois os objetos existem e são executados na
memória do computador, independentemente de como foram
organizados os pacotes. Além dos pacotes, podemos citar,
como itens de agrupamento:
os modelos, subsistemas e frameworks, que não deixam de
ser variações de pacote. Observe na Figura 15 o exemplo de
representação de pacote.

Figura 15 – Pacote.

Itens Anotacionais
Esses itens existem somente para deixar registrada uma
anotação. Frequentemente, os projetistas necessitam explicar
alguma coisa em formato de texto, fazer uma ponderação,
descrever o funcionamento de um determinado componente,
ou mesmo realizar um tipo qualquer de anotação. Isso deve
ser colocado em uma nota. Esse é um símbolo que deve ser
utilizado para breves explicações. A forma gráfica de uma nota
é definida como a Figura 16.
 Figura 16 – Anotação.

Para fazer a modelagem, podemos utilizar uma ferramenta

CASE de modelagem. Sugerimos o Astah Community, pelo
simples fato de ser free. Em julho de 2017, a versão disponível
era a 7.1.0 (Professional) ou a 6.4.4 (Community).

Para que você consiga baixar a versão Professional como

estudante basta informar o seu e-mail acadêmico. Já, a versão
Community não necessita dessa informação.

Acesse e adquira o software:

Astah Community 6.4.4 

Astah Professional 7.1  (com licença para estudante)

Para Refletir 

Nesta aula, você estudou o conceito de abstração, que

tem como foco principal olhar para um determinado
contexto, entendendo e imaginando tudo o que compõe
aquela situação, e transcrevê-la do mundo real para o
contexto computacional. Observe os veículos
apresentados a seguir. Como você irá transcrevê-los do
contexto do mundo real para o contexto computacional?

Figura 17 – Classe Veículo.

Levando em consideração os conceitos estudados até o
momento em relação à orientação a objetos, a transcrição dos
Fonte: Adaptado de Sobrecarga e sobreposição de métodos .
objetos do mundo real para classes existentes no mundo
computacional, teríamos a Figura 18.

Figura 18 – Classe Veículo.

Fonte: Adaptado de Sobrecarga e sobreposição de métodos .

Percebe-se que temos uma superclasse Veículo com dois

métodos e as subclasses Carro e Avião, que herdam os
métodos da superclasse. Esse assunto será aprofundado nas
próximas aulas, nas quais trabalhará efetivamente a
transcrição das classes do mundo real de um sistema
solicitado pelo cliente para o mundo computacional.

Finalizando... 

Nesta aula, você fez uma revisão de

conceitos e modelos que serão
importantíssimos para que consiga
Analisar e Projetar corretamente o
software que foi detalhado nos Requisitos
de Software. Na próxima aula,
compreenderá o que compõem as visões
estáticas e dinâmicas de um software. Até
lá!
©2018 Copyright ©Católica EAD. Ensino a distância (EAD) com a qualidade da

Na Prática 
"Prezado(a) estudante,

Esta seção é composta por atividades que objetivam

consolidar a sua aprendizagem quanto aos conteúdos
estudados e discutidos. Caso alguma dessas atividades seja
avaliativa, seu (sua) professor (a) indicará no Plano de
Ensino e lhe orientará quanto aos critérios e formas de
apresentação e de envio."

Bom Trabalho!

Atividade 01 

Para trabalhar na fase de Análise e Projeto de Software, é muito

importante que você entenda qual é o ferramental que estará
disponível para você trabalhar a modelagem do sistema. Para
isso, contamos com a UML. A versão 2.5 conta com 14
diagramas que podem ser utilizados durante todo o ciclo de vida
de desenvolvimento de software. A figura a seguir apresenta a
Taxonomia da Estrutura dos Diagramas da UML.

Fonte: OMG Unified Modeling Language – versão 2.5 (disponível no

link: http://www.omg.org/spec/UML/2.5/ )
 Perceba que nessa figura temos Diagramas de Estrutura,
Diagramas Comportamentais e Diagramas de Interação. Para
exercitar os assuntos abordados, é sugerido que inicialmente,
faça uma pesquisa e identifique o porquê de serem chamados
dessa forma. Em seguida, monte em seu caderno um quadro,
separando quais são os diagramas que podem ser utilizados em
cada um desses três contextos.

Atividade 02 

A abstração é uma forma de entender um determinado contexto do

mundo real, traduzindo-o para o mundo computacional, que é o
nosso foco específico. Observe a figura a seguir, com diversos tipos
de veículos motorizados.

Fonte: http://files.sorocabairros.webnode.com/200001102-2a7fe2c73f
/veiculos.png 

Faça a transcrição, via abstração da representação dos componentes

dessa figura para o mundo computacional, conforme exemplos que
foram apresentados a você nessa aula.

Atividade 03 

Em seu caderno, complete a tabela a seguir, para fazer uma

revisão dos principais elementos que você tem à disposição para
modelar a análise e projeto de software utilizando a UML.

ELEMENTO DESCRIÇÃO

Classe

Objeto

Atributos

Métodos/Operações

Visibilidade

Encapsulamento

Interface

Polimorfismo

Interface

Caso de Uso
©2018 Copyright ©Católica EAD. Ensino a distância (EAD) com a qualidade da

Saiba Mais 
Para ampliar seu conhecimento a respeito desse assunto, veja
abaixo a(s) sugestão(ões) do professor:

Para conhecer um pouco mais a respeito da UML, leia o

artigo: A aplicação da linguagem de Modelagem Unificada
(UML) para o suporte ao Projeto de Sistemas
Computacionais dentro de um Modelo de Referência , de
Carlos Alberto Costa.

Para conhecer um pouco mais a respeito da UML, assista ao

vídeo Introdução à UML – 1ª parte , do Prof. Kleber Veloso.

Leia as explicações sobre os assuntos abordados na

especificação da UML, que pode ser baixada do site da OMG
.

Amplie seus conhecimentos sobre os conceitos de

orientação a objetos, assistindo ao vídeo Conceito orientado
a objeto .
©2018 Copyright ©Católica EAD. Ensino a distância (EAD) com a qualidade da

Referências 
BOOCH, Grady; RUMBAUGH, James; JACOBSON,
Ivar. UML:guia do usuário. 2. ed. Rio de Janeiro: Campus,
2005.

COAD, Peter; YOURDON, Edward. Projeto baseado em

objetos. Rio de Janeiro: Campus, 1993.

GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES,

Johnson. Padrões de projeto: soluções reutilizáveis de
software orientado a objetos. Porto Alegre: Bookman, 2000.

GARLAN, David; SHAW, Mari. An Introduction to Software

Architecture, School of Computer Science Carnegie Mellon
University, 1994. Disponível em: <https://www.cs.cmu.edu
/afs/cs/project/vit/ftp/pdf/intro_softarch.pdf>. Acesso em:
25 jul. 2017.

KRUTCHEN, Philippe. Introdução ao RUP: Tational Unified

Process. Rio de Janeiro: Editora Ciência Moderna, 2003.

PRESSMAN, Roger S. Engenharia de software. 6. ed. Rio de

Janeiro: McGrawHill, 2006.

PRESSMAN, Roger S. Engenharia de software: uma

abordagem profissional. 7. ed. São Paulo: McGraw-Hill, 2011.

SOMMERVILLE, Ian. Engenharia de software. 9. ed. São

Paulo: Pearson Addison Wesley, 2011.