***********Aula 4 UML E DIAGRAMA DE CASO

DE USO ********

Descrição: - O que é UML

- Modelo Orientado a Objetos
- Técnicas de Construção do Diagrama de Caso de Uso
- Componentes de um Diagrama de Caso de Uso
- Analisando um Exemplo de Diagrama de Caso de Uso

**Nesta aula, vamos conversar sobre a Unified Modelling Language (UML)**

**TEMA 1 – O QUE É UML?

Para falar de UML é preciso conhecer o Object Management Group (OMG), uma
organização internacional que aprova padrões reconhecidos pela área de tecnologia
da informação (TI) para aplicações orientadas a objetos,

A notação UML começou a ser criada em outubro de 1994, quando James Rumbaughq se
juntou a Grady Booch na Rational Software Corporation, uma grande empresa de
software da época. O constante crescimento da Rational fez com que surgisse a
necessidade de organizar e definir as etapas de desenvolvimento adotadas em seus
projetos, elaborando-se um ciclo de vida para desenvolvimento de softwares. Foi
concebido, assim, o processo de desenvolvimento unificado denominado Rational
unified process (RUP).

A UML é uma linguagem ou notação de diagramas que serve para especificar,

visualizar e documentar modelos de software desenvolvidos sob os preceitos da
orientação por objetos. Como a UML não é um método de desenvolvimento, ela não diz
o que fazer primeiro, o que fazer depois ou como desenhar o sistema, mas ajuda a
visualizá-lo e a comunicá-lo aos outros. A UML é controlada pelo OMG e considerada
como a norma da indústria de software para descrevê-lo graficamente.

Segundo Pressman e Maxim (2016), “a UML fornece uma gama de diagramas que podem ser
usados para análise e projeto tanto em nível de sistema quanto de software”. A
existência de um modelo visual facilita a comunicação e faz com que os envolvidos
na construção do software tenham a mesma visão e conhecimento sobre o sistema.

1.1 - O que são modelos?

Um modelo de processo de desenvolvimento de software, ou, simplesmente, modelo de
processo, pode ser visto como uma representação ou abstração dos objetos e
atividades envolvidas no processo de criação de um software.

Algumas facilidades que podem ser alcançadas pela modelagem do software são que:

-Os modelos ajudam a visualizar o sistema como ele é ou como desejamos que
seja, mostrando visualmente suas interfaces e modo de funcionamento.
-Os modelos permitem especificar a estrutura ou o comportamento de um sistema.
Existem vários tipos de modelos, cada um com um objetivo e focando uma parte do
software.
-Os modelos proporcionam um guia para a construção do sistema, possibilitando
analisar a melhor solução possível para o software em questão.
-Os modelos documentam as decisões de projeto tomadas e apoiam a tomada de uma
melhor decisão com base em oferta de soluções possíveis para o problema que se quer
resolver.
-Os modelos permitem visualizar o sistema em diversos níveis de abstração. Por
isso, os diversos modelos criados para um software precisam ser coerentes entre si,
se complementarem e darem uma visão completa de como o software deve ser construído
e de como ele funcionará.
-Os modelos facilitam a comunicação entre os membros da equipe de formulação do
software, pois, na UML, os modelos expressam duas visões diferentes, porém
complementares:
1.visão estrutural: os modelos criados tentam capturar a estrutura do
sistema, ou seja, quais elementos compõem a estrutura do sistema e como eles se
relacionam;
2.visão comportamental: os modelos criados tentam capturar a dinâmica do
sistema, ou seja, como os elementos que compõem o sistema se comunicam e como se
comportam e respondem a diversos estímulos.

1.2 Modelos de UML:

Resumindo, modelos são abstrações ou uma simplificação da realidade que vai ser
automatizada por meio de um software; e a UML é a linguagem mais conhecida no mundo
da TI para fazer modelagem de softwares. A UML é composta por muitos elementos e
por diferentes modelos, que representam as partes de um sistema de software.

Os elementos UML são usados para criar diagramas que representam uma determinada
parte ou um ponto de vista do sistema. Os diagramas mostram visualmente a solução
definida para a construção do software. A UML é muito rica e dispõe de vários
diagramas diferentes, com objetivos próprios. Como já foi explicado, o OMG é
responsável por manter e fazer evoluir a UML, mediante novas versões lançadas
periodicamente. A versão atual da UML é a 2.0 e pode ser encontrada no site da
própria empresa.

A seguir, alguns tipos de diagramas previstos na UML 2.0:

a.Diagramas estruturais ou estáticos

Diagrama de classes.
Diagrama de componentes.
Diagrama de implantação.
Diagrama de objetos.
Diagrama de pacotes.
Diagrama de estrutura da composição.
Diagrama combinado componentes/implantação.
b.Diagramas comportamentais ou dinâmicos
Diagrama de caso de uso.
Diagrama de sequência.
Diagrama de atividades.
Diagrama de estados.
Diagrama de comunicação (antigo diagrama de colaboração da UML 1.4).
Diagrama de visão geral da interação.
Diagrama de tempo.

-Diagrama de classes: é o principal diagrama de análise e projeto OO (visão

estrutural). Nele, são mostradas as classes do sistema, seus relacionamentos
(herança, associação, composição e agregação), seus atributos (informações
relacionadas com cada classe) e seus métodos (ações que podem ser realizadas com
cada classe).

-Diagrama de componentes: modela as partes do software no ambiente onde ele está

sendo implementado, ou seja, no seu ambiente de desenvolvimento (códigos-fonte,
dynamic-link library – DLL, executáveis, hypertext markup language – HTML,
cascading style sheets – CSS, Java archive – JAR, class, bibliotecas, componentes
específicos etc.).

-Diagrama de implantação: modela o hardware de cada um dos ambientes utilizados, ou

seja, modela o hardware segregado em ambientes de desenvolvimento, de teste, de
homologação e de produção.

-Diagrama de objetos: modela instâncias reais das classes e seus relacionamentos,

ou seja, modela fatos reais ou exemplos do dia a dia. Usado como complemento do
diagrama de classes.

-Diagrama de pacotes: mostra como os elementos estão organizados em pacotes e as

dependências entre esses pacotes.

-Diagrama de estrutura da composição: modela um comportamento ou estrutura complexa

em que as classes e/ou os componentes estão envolvidos e os pontos de interação
usados para acessar os recursos dessa estrutura.

-Diagrama combinado componentes/implantação: une os modelos de componentes e

implantação mostrando como os componentes de software estão distribuídos nos
componentes do hardware.

-Diagrama de caso de uso: nele são especificados e detalhados os requisitos

funcionais, com descrição dos cenários nos quais os atores interagem com o sistema.
São bastante úteis na comunicação entre todos os envolvidos na construção do
software, incluindo os usuários.

-Diagrama de sequência: é o modelo mais usado para apoiar a visão dinâmica de um

sistema. É empregado na análise de projeto para modelar a interação entre os
diversos objetos de uma linha de tempo.

-Diagrama de atividades: normalmente usado para modelagem de processos de negócio

ou para detalhamento da lógica de negócio. Também pode ser utilizado para descrever
casos de uso. Permite a modelagem de fluxo de controle e de dados.

-Diagrama de estados: modela como os estímulos ou eventos externos causam mudanças

no estado de um objeto, no decorrer do seu ciclo de vida.

-Diagrama de comunicação: é equivalente ao diagrama de sequência, mas sem o foco

temporal (algumas ferramentas UML geram diagrama de comunicação com base no
diagrama de sequência). O diagrama de comunicação também pode ser chamado de
diagrama de colaboração.

-Diagrama de visão geral da interação: usa o mesmo layout do diagrama de

atividades. Entretanto, ao invés de modelar atividades, são modelados blocos de
interação associados ao diagrama de sequência, ou seja, tem-se com ele uma visão
macro, ao invés de uma visão detalhada da interação

-Diagrama de tempo: como o diagrama de estados, também modela mudanças no estado de

um objeto. Entretanto, enfatiza a questão do tempo durante o ciclo de vida da
informação.

TEMA 2 – MODELO ORIENTADO A OBJETOS:

entidade física: um carro, uma pessoa, um livro;

entidade conceitual: um diagrama de um sistema;
entidade de software: um checkbox em uma página web.

Algumas outras características dos objetos são também fundamentais para se garantir
uma boa análise do software, como:
Identidade de um objeto: é o que identifica univocamente um objeto, dentre os
demais existentes. A identidade permite que um objeto seja referenciado.
Características de um objeto: descrevem propriedades do objeto. São mutáveis,
ao longo do tempo, e também chamadas de atributos do objeto.
Comportamentos de um objeto: determinam como um objeto reage a estímulos do
mundo real ou de outros objetos. Também são chamados de métodos do objeto.

2.1 Conceitos da orientação a objetos:

-Abstração: a abstração consiste em se concentrar nos aspectos essenciais, próprios
de uma entidade, e em se ignorar suas propriedades acidentais, ou seja, dar foco a
aspectos relevantes para um determinado propósito. Esse conceito é muito importante
para simplificar os conceitos complexos.

-Encapsulamento: consiste na separação dos aspectos externos de um objeto,

acessíveis por outros objetos, dos detalhes internos da implementação daquele
objeto, que ficam ocultos dos demais objetos. Ou melhor: significa separar o
software em partes o mais isoladas possível. A ideia é tornar o software mais
flexível, fácil de modificar e de criar novas implementações. É uma forma de
restringir o acesso ao comportamento interno de um objeto. Cada objeto possui uma
interface, que é o que ele conhece e o que ele sabe fazer, sem descrever como é
feito.

-Herança: é o compartilhamento de atributos e operações entre objetos, com base em

um relacionamento hierárquico. Permite que uma estrutura comum seja compartilhada
por diversos outros objetos relacionados, sem redundâncias. Cada objeto, em um
nível de hierarquia, herda as características dos objetos dos níveis acima.

3.1 Características de um diagrama de casos de uso:

Conforme discutido anteriormente, após a identificação dos requisitos de um
software, é preciso especificá-los, ou melhor, detalhá-los. Uma técnica comumente
adotada para especificação dos requisitos é a modelagem de casos de uso (use
cases).

As principais características de um diagrama de caso de uso são:

-ele pode ser consultado por qualquer stakeholder, pois utiliza um padrão fácil
de ser compreendido mesmo por quem não é de TI;
-o seu foco é a definição do problema e não a solução computacional; por isso,
ele representa os requisitos funcionais do software;
-o diagrama de caso de uso permite registrar de fato o que o sistema deve fazer
e como as funcionalidades do software se relacionam entre si;
-por ser um modelo de análise, o diagrama de caso de uso é independente da
abordagem de desenvolvimento;
-ele pode ser descrito com diversos níveis de detalhamento, facilitando a
compressão no nível macro do software e também nos níveis de detalhe que permitam
visualizar todo o relacionamento entre as funcionalidades identificadas para o
software.

TEMA 4 – COMPONENTES DE UM DIAGRAMA DE CASO DE USO:

Os componentes de um diagrama de caso de uso, também chamados de elementos,
fornecem a identidade visual do modelo. Para entender um diagrama, é preciso
entender a linguagem utilizada na sua construção. A linguagem tomada como base é a
linguagem UML, já estudada por nós. Vamos conhecer, então, cada um dos elementos de
um diagrama de caso de uso.

4.1 Ator e caso de uso:

O ator representa o papel executado por uma entidade que interage com o sistema em
questão. Um ator modela algo fora da fronteira do sistema e precisa trocar
informações com esse sistema, como indivíduos e outros sistemas, ou seja, o ator
interage com o sistema, mas ele não faz parte do sistema. Um usuário pode executar
o papel de vários atores diferentes e um determinado ator pode ser representado por
vários usuários. Dessa forma, é preciso esclarecer que ator não é o mesmo que
usuário.
Reforçando o conceito:

-Um ator representa um papel exercido por um usuário ao interagir com

determinado caso de uso.
-Usuários podem desempenhar mais de um papel no sistema.
-Em modelagem de software, como a UML é a linguagem utilizada, é preciso
conhecer a notação, ou melhor: os símbolos que representam graficamente os
elementos do diagrama de caso de uso.

Um ator é representado por um boneco e um rótulo com o nome do ator. Um ator é um

usuário do sistema, que pode ser um usuário humano ou um outro sistema
computacional.

Os atores podem ser classificados em diferentes tipos, como:

Ator primário – é o interessado que acessa o sistema para utilizar diretamente
um serviço.
Ator secundário (ou ator de suporte) – interage com o sistema fornecendo algum
tipo de serviço ou informação. Por exemplo, um sensor de temperatura, um sistema de
cartão de crédito ou um sistema de contabilidade. Os atores secundários são úteis
para identificar o que o sistema deverá prover em termos de protocolo de troca de
dados e interfaces externas.

Os atores podem ainda pertencer a categorias diferentes, e algumas das mais comuns
são:

Usuários: usuários finais, administradores, gerentes, entre outros.

Aplicações: processos individuais, rotinas automatizadas e sistemas de software
externos ao sistema modelado.
Dispositivos: sensores ou qualquer outro hardware que tenha interação com o
sistema modelado.
Eventos externos: controlador de tempo, escalonador de processos ou qualquer
outro evento que dispare uma funcionalidade do sistema modelado.

4.2 Relacionamentos:
Os relacionamentos mostram a ligação entre os elementos de um diagrama de caso de
uso, ou seja, a ligação dos atores com os casos de uso e dos casos de uso entre si.
Os relacionamentos ajudam a compreender o funcionamento do software, demonstrando
quais atores têm acesso a cada caso de uso e como os casos de uso se relacionam,
apresentando a dinâmica de interação entre eles, focando no entendimento do
funcionamento dos processos de negócio.

Vamos nos aprofundar nos diferentes tipos de relacionamento que podem ser
encontrados em um diagrama de caso de uso.

4.2.1 Relacionamento entre atores: generalização

O único relacionamento possível entre os atores é a generalização. Esse
relacionamento é identificado quando temos dois atores semelhantes, mas com um
deles realizando algo a mais que o outro. A generalização é usada para identificar
funcionalidades comuns entre atores e pode ser sempre lida como [algo] é um tipo
de. Ela deve ser identificada e validada com cuidado, para não modelar
relacionamentos desnecessários a um determinado ator ou, mesmo, não demonstrar
relacionamentos que não devem ocorrer para garantir o bom funcionamento do
software. Os relacionamentos precisam representar exatamente as ligações corretas
para o software, nem mais e nem menos.

4.2.2 Relacionamento entre um ator e um caso de uso: associação:

O relacionamento de associação define uma funcionalidade do sistema do ponto de
vista do usuário, mostrando visualmente a quais casos de uso cada ator tem acesso.
A associação representa a interação do ator com o caso de uso, por meio de envio e
recebimento de mensagens. Associações são representadas por uma linha sólida,
ligando o ator ao caso de uso. Se o ator inicia um caso de uso, ele pode se
comunicar com vários atores depois. As associações servem para mostrar quais atores
se comunicam com o caso de uso em questão.

A direção do relacionamento de associação também é importante para compreender o

funcionamento dos casos de uso. Dessa forma, é preciso compreender os seguintes
pontos:

-Cada ator de uma associação tem uma propriedade de navegabilidade, que indica
quem inicia a comunicação na interação.
-A direção é representada no diagrama por uma seta: se a seta apontar para um
caso de uso, o ator inicia a interação; se a seta apontar para o ator, o sistema
inicia a interação.
-A navegabilidade de duas direções é mostrada por uma linha sem setas. Também é
possível usar setas bidirecionais.

4.2.3 Relacionamento entre casos de uso:

O relacionamento entre casos de uso pode ser:

-Include: um relacionamento include de um caso de uso A para um caso de uso B

indica que B é essencial para o comportamento de A. Pode ser dito também que B
is_part_of A.
-Extend: um relacionamento extend de um caso de uso B para um caso de uso A
indica que o caso de uso B pode ser acrescentado para descrever o comportamento de
A, mas não lhe é essencial. Nesse sentido, o ponto de extensão, em um caso de uso,
é uma indicação de que outros casos de uso poderão ser adicionados a ele. Quando o
caso de uso for invocado, ele verificará se suas extensões devem ou não ser
invocadas.

TEMA 5 – ANALISANDO UM EXEMPLO DE DIAGRAMA DE CASO DE USO:

Vamos, agora, voltar ao nosso estudo de caso, analisando como seria a modelagem de
diagrama de casos de uso para o sistema proposto. Vamos relembrar nosso estudo de
caso, que é o seguinte: fomos contratados por nosso cliente para modelar o processo
de vendas on-line de livros. Nosso cliente tem uma livraria virtual, que vende
produtos diretamente aos seus clientes, em um site próprio. O diferencial dessa
livraria é ter um estoque próprio, o que garante uma entrega mais rápida de livros
a seus clientes; aceitar vários tipos de pagamento, como cartão de crédito, cartão
de débito e boleto bancário; administrar um programa de fidelidade que fornece
desconto de 10% aos clientes que compram R$ 500,00, ao longo de 1 ano.

Reforçando o que já foi dito nas aulas anteriores, não existe uma única forma de
modelar esse estudo de caso. Sendo assim, o diagrama de caso de uso que
construiremos é apenas uma forma de modelar o sistema proposto. O estudo de caso
proposto, nessa solução, possui os seguintes casos de uso:

fazer login;
efetuar compra;
selecionar livros;
selecionar forma de pagamento;
efetuar pagamento;
utilizar programa de fidelidade;
atualizar status do pedido;
atualizar programa de fidelidade;
enviar dados do pedido;
 enviar pesquisa de satisfação.

Os atores identificados no levantamento de requisitos são:

consumidor;
área de vendas;
sistema de estoque;
sistema financeiro;
sistema contábil.

**