Aula MODELAGEM DE SISTEMAS (CCT07593619865) 9002

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Aula 01
Desenvolvimento de sistemas
O desenvolvimento de sistemas é um processo intelectual e progressivo, em que os profissionais envolvidos adquirem mais conhecimento do sistema à medida que avançam no entendimento da realidade em que o sistema está inserido.
Tomemos como exemplo a criação de um sistema que gerencie as atividades de um estacionamento de veículos:
No início do processo, é preciso conversar com os profissionais envolvidos no negócio em questão para compreender a realidade e o funcionamento do mesmo. No primeiro dia, nada conhecemos do negócio estacionamento, no quinto dia de estudo, por exemplo, o conhecimento da realidade é mais apurado.
Para representar a realidade e entender o que se passa no contexto do sistema a ser construído, precisamos traduzir a realidade em modelos.
No contexto de desenvolvimento de sistemas, o que são modelos?
Nada mais são que diagramas gráficos que representam a realidade e ajudam os desenvolvedores a compreendê-la. Portanto, modelar um sistema consiste em criar um conjunto de modelos sob a forma de diagramas, que representam a estrutura e o comportamento de um sistema.
Para entender um pouco mais sobre a modelagem de sistemas, clique no botão abaixo:
Podemos citar como exemplo o caso de uma construtora que, quando idealiza um empreendimento, constrói uma maquete que representa a realidade, ou seja, ela constrói um modelo da realidade. Pela maquete, tanto a equipe de construção como os clientes têm a noção do que será o empreendimento (disposição no terreno, área comum etc.), diminuindo, consideravelmente, a abstração e aproximando-o da realidade. Da mesma forma, um diagrama gráfico representa o sistema, sob determinada visão.
Mas a maquete não é o único modelo usado para uma construção civil. São necessárias, também, diferentes plantas que descrevam as características de cada etapa da construção, tais como planta baixa, planta hidráulica, planta elétrica e outras. Analogamente a essas plantas, temos, no contexto da modelagem de sistemas, outros diagramas, que ajudarão os técnicos a especificar como o sistema deve ser construído.
Conceitos do Paradigma Orientado a Objetos
Podemos dizer que a representação da realidade ocorre por meio de paradigmas.
Paradigma é uma forma de abordar um problema.
Até o final dos anos 1980, prevaleceu o paradigma imperativo ou estruturado, caracterizado pelo uso das técnicas de Análise Estruturada e Análise Essencial, que foram eficientes para sistemas de pequeno porte.
À medida que os sistemas tornaram-se mais complexos e robustos, uma nova abordagem se fez necessária para estudar, entender e modelar o sistema a ser desenvolvido. Surgia o paradigma Orientado a Objetos, também chamado paradigma OO.
Na modelagem sob o enfoque da orientação a objetos (OO), a tarefa principal passa a ser a identificação dos objetos do mundo real envolvidos no contexto do sistema e a relação entre eles. Ao identificar os objetos, são identificados também os dados (atributos) e as funcionalidades (funções) inerentes àquele objeto, conforme ilustrado na equação abaixo.
OBJETO = DADOS + FUNÇÕES
Na medida em que são identificados todos os objetos pertinentes a um sistema, já teremos os dados e os procedimentos relacionados.
Considerando o contexto de um sistema bancário (ilustrado pela imagem a seguir), podemos citar os objetos agência, cliente e conta, e a relação “Cliente possui uma conta em uma agência”.
Ao identificar os objetos, são identificados, também, os dados (atributos) e as funcionalidades (funções) inerentes àquele objeto, conforme ilustra a imagem. O objeto cliente possui os dados nome, endereço, telefone e CPF e, sobre ele, podem ser realizadas, por exemplo, as funções de Incluir Novo Cliente, Excluir Cliente Inativo, Inativar Cliente.
Orientação a Objeto (OO)
Um modelo OO tem com entidade fundamental o Objeto, que recebe e envia mensagens, executa procedimentos e possui um estado que, por proteção, apenas ele próprio pode modificar. Nesse processo, problemas são resolvidos, por meio de objetos, que enviam mensagens uns aos outros.
O Modelo OO é formado por alguns elementos básicos:
Objeto
É o principal elemento do modelo OO. Representam as “coisas” a serem modeladas do mundo real. Um objeto pode ser algo concreto como um carro, um aluno ou algo abstrato como uma disciplina, um curso. Cada objeto possui os dados inerentes a ele, como por exemplo, Nome (José) e Matrícula (201101272201) de um objeto Aluno e possui as operações que ele executa, como incluir novo aluno ou alterar dados de um aluno existente.
Mensagem
Quando um objeto deseja que seja executada uma operação de responsabilidade de outro objeto, ele manda uma mensagem a esse objeto informando o que ele deseja que seja feito. A operação desejada será implementada por meio de um método da classe que recebe a mensagem, conforme a imagem abaixo:
Atributos
São dados que caracterizam o objeto.
Metodos
É um procedimento (implementado por uma rotina ou função) que executa uma operação em um objeto, que define parte de seu comportamento.
Classes
É um conjunto de objetos com as mesmas características (atributos e métodos). Conforme ilustrado na imagem a seguir, Maria e Pedro são objetos da classe PESSOA, cujas características em comum são:
• Atributos: Nome, Endereço, Telefone, Idade e Altura.
• Métodos: Registrar( ), Matricular( ), Pagar( ), Estudar( ) e Cadastrar( ).
Podemos dizer, portanto, que “Objeto é uma instância de uma classe”, isto é, a classe é o molde e o objeto, a “coisa real”. 
Existe uma diferença entre os conceitos de classes e objetos. Para visualizar um exemplo dessa diferença, clique no botão ao lado: 
Diferença entre o conceito de classes e objetos
A seguir, um exemplo da diferença entre o conceito de classes e objetos, ou seja, é
habitual dizermos que “Objeto é uma instância de uma classe”, isto é a classe é o
molde e o objeto a “coisa real”.
Os pilares do paradigma Orientado a Objetos
A orientação a objetos tem como alicerce alguns princípios fundamentais. Juntos, eles permitem que classes sejam reaproveitadas, otimizando tempo e custo de desenvolvimento, além da segurança no reuso das classes já usadas e testadas. Observe:
Encapsulamento
Encapsular significa esconder, ou seja, o objeto esconde seus dados (atributos) do acesso indevido de outros objetos. Os dados somente devem ser acessados por métodos (funcionalidades que implementam o comportamento do objeto) da própria classe, o que pode ser visualizado na figura abaixo:
Herança
Mecanismo para derivar novas classes a partir da definição de classes existentes através de um processo de refinamento. 
Polimorfismo
A palavra polimorfismo, deriva do grego, e significa “muitas formas”. A partir do momento em que uma classe herda atributos e métodos de uma (herança simples) ou mais (herança múltipla) classes base, ela tem o poder de alterar o comportamento de cada um desses procedimentos (métodos). 
Visibilidade
Outro conceito fundamental, é a visibilidade entre as classes. A visibilidade diz respeito ao que uma classe pode visualizar da outra. Como princípio, devemos garantir o encapsulamento, ou seja, os atributos devem ser privados (acessíveis apenas por métodos da própria classe) e determinados métodos públicos (acessíveis por todas as classes), e acessar esses dados. 
Para conhecer um pouco mais sobre os pilares da Orientação a Objetos, clique no botão ao lado:
Os pilares do paradigma Orientado a Objetos
Dentre as principais características do paradigma orientado a objeto (OO),
destacamos:
Encapsulamento:
Encapsular significa esconder. O objeto esconde seus dados (atributos) do acesso
indevido de outros objetos. Os dados somente devem ser acessados por métodos
(funcionalidades que implementam o comportamento do objeto) da própria classe,
o que pode ser visualizado na figura abaixo (Encapsulamento).
O encapsulamento é uma técnica para minimizar a interdependências entre as
classes, pois
apenas os métodos da respectiva classe podem alterar seus dados
(atributos), facilitando a identificação de erros e a alteração dos programas.
Herança:
Mecanismo para derivar novas classes a partir da definição de classes existentes
através de um processo de refinamento. Uma classe derivada ou descendente
herda os dados (atributos) e comportamento (métodos) da classe base ou ancestral
ou ascendente. 
Conforme ilustrado na figura abaixo, as classes ContaPoupança e
ContaInvestimento herdam da classe Conta, os atributos e métodos que são
permitidos. A classe Conta é chamada Classe base, uma vez que é a base da
herança. Veja:
A implementação da herança garante a reutilização de código, que além de
economizar tempo e dinheiro, propicia mais segurança ao processo de
desenvolvimento, posto que as funcionalidades da classe base já foram usadas e
testadas.
Polimorfismo:
A palavra polimorfismo, deriva do grego, e significa “muitas formas”. A partir do
momento em que uma classe herda atributos e métodos de uma (herança simples)
ou mais (herança múltipla) classes base, ela tem o poder de alterar o
comportamento de cada um desses procedimentos (métodos). Isso amplia o poder 
do reaproveitamento de código promovido pela herança, permitindo que se
aproveite alguns métodos e se altere (redefina) outros.
Dessa forma, um método com mesmo nome, em classes distintas, pode ter
diferentes comportamentos. Acompanhe o exemplo da figura abaixo, onde
identificamos uma herança: Pagamento em Dinheiro, Pagamento em CC (Cartão de
crédito) e Pagamento em Cheque herdam da classe Pagamento, o atributo o
método Pagar_Conta (Valor: double, troco: double). Observe que em cada classe
filha (Pagamento em Dinheiro, Pagamento em cartão e pagamento em Cheque)
escreve novamente o método Pagar, com as respectivas particularidades
necessárias a cada forma de pagamento. Essa possibilidade ocorre pelo princípio do
polimorfismo.
Visibilidade:
Outro conceito fundamental é a visibilidade entre as classes. A visibilidade diz
respeito ao que uma classe pode visualizar da outra. Como princípio, devemos
garantir o encapsulamento, ou seja, os atributos devem ser privados (acessiveis
apenas por métodos da própria classe) e determinados métodos públicos (acessíveis
por todas as classes), e acessar esses dados.
Por outro lado, se mantivermos todos os métodos como sendo privados, a classe
perde o sentido, pois nenhuma outra poderá usar seus métodos. Então, devemos
usar a visibilidade com equilíbrio e sabedoria. 
Outra visibilidade possível, além de privada e pública, é a protegida, onde os
atributos e os métodos somente pode ser vistos dentro da estrutura de herança, ou
seja, pelas classes filhas.
Na figura que vimos acima, o atributo Valor e o método Pagar_Conta (Valor :int) da
classe Pagamento, somente podem ser acessados pelas classes Pagamento em
Dinheiro, Pagamento Cartao e Pagamento Cheque.
Conclusões do paradigma Orientado a objetos
Seguem algumas das conclusões do paradigma OO:
O uso de técnicas orientadas a objetos facilita o controle da complexidade uma vez que promove uma melhor estruturação de seus componentes e também permite que componentes já usados e validados possam ser reaproveitados. 
Proporciona modularidade trazendo os seguintes benefícios:
• Reusabilidade: softwares podem ser escritos com base em componentes já existentes;
• Extensibilidade: novos componentes de software podem ser desenvolvidos a partir de outros, já existentes, sem afetar o comportamento do componente de origem.
As hierarquias de classes (herança) são componentes portáveis entre aplicações, que, se bem projetados, podem ser reutilizados em vários sistemas sem modificação e, além disso, podem ser estendidos (polimorfismo) sem corromper o que já existe. 
Um sistema desenvolvido com as características do modelo OO tende a ser bem estruturado posto que os objetos são unidades coesas com interfaces simples que escondem as suas implementações.
Para conhecer um pouco mais sobre as conclusões do Paradigma Orientado a Objetos, clique no botão ao lado:
Conclusões do paradigma Orientado a objetos
O paradigma orientado a objetos surgiu (década de 1980) como um modelo
promissor para o desenvolvimento de software mais confiável devido às
características inerentes ao modelo de objetos. Vejamos:
• O conceito de encapsulamento permite a construção de classes
independentes uma das outras, facilitando o desenvolvimento e a manutenção do
software (alterações e melhorias na classe).
• A herança e o polimorfismo permitem e facilitam a reutilização de código,
útil nas fases de implementação e manutenção.
O uso de técnicas orientadas a objetos facilita o controle da complexidade uma vez
que promove uma melhor estruturação de seus componentes e também permite
que componentes já usados e validados possam ser reaproveitados.
Cabe ressaltar que uma das principais razões para a baixa produtividade, no
desenvolvimento de software, é a dificuldade de reutilização de código usando o
paradigma funcional.
As hierarquias de classes (herança) são componentes portáveis entre aplicações,
que, se bem projetados, podem ser reutilizados em vários sistemas sem
modificação e, além disso, podem ser estendidos (polimorfismo) sem corromper o
que já existe.
Assim sendo, podemos dizer que o modelo de objetos proporciona modularidade
trazendo os seguintes benefícios:
• Reusabilidade: softwares podem ser escritos com base em componentes já
existentes;
• Extensibilidade: novos componentes de software podem ser desenvolvidos a
partir de outros, já existentes, sem afetar o comportamento do componente de
origem.
Sabe-se que software são intrinsicamente complicados devido aos novos requisitos
das aplicações modernas: alta confiabilidade, alto desempenho, desenvolvimento
de software rápido e barato, alta complexidade e tamanhos grandes.
O modelo OO veio para combater os problemas derivados da crise do software,
termo cunhado em 1968, na Europa, e caracterizado pelos seguintes problemas do
software: baixa confiabilidade, baixa qualidade, alto custo de manutenção e
duplicação de esforços na sua construção (tempo e dinheiro).
Um sistema desenvolvido com as características do modelo OO tende a ser bem
estruturado posto que os objetos são unidades coesas com interfaces simples que
escondem as suas implementações
Um sistema desenvolvido sob o paradigma da orientação a objetos representa os
objetos que encontramos no mundo real, no problema que estamos tratando, no
negócio para o qual o estamos desenvolvendo o sistema. O foco da equipe de
desenvolvimento passa a ser a identificação e a modelagem dos objetos do mundo
real que afetam o sistema.
A orientação a objetos tem como alicerce três princípios fundamentais: o
encapsulamento que protege o acesso aos atributos e métodos, a herança e o
polimorfismo, que juntos, permitem que classes sejam reaproveitadas, otimizando
tempo e custo de desenvolvimento, além da segurança no reuso de classes testadas
e utilizadas.
Conceitos de Análise e Projeto Orientado a Objeto
A orientação a objetos enfatiza a identificação, a representação e a organização dos objetos necessários a um sistema.
Antes de adentramos no universo da análise e projeto, sob o enfoque do paradigma Orientado a objeto, vamos tecer rápidos comentários acerca do que sejam as atividades de Análise e Projeto, dentro do contexto de desenvolvimento de software.
Análise de sistemas significa uma investigação dos problemas e dos requisitos de um contexto, em particular, com vistas ao desenvolvimento de um sistema automatizado. A ideia básica é identificar quais seriam as funções que esse sistema precisa ter, de forma a atender eficientemente as necessidades de seus usuários.
Atividade de análise e projeto
A atividade de análise, por ser muito abrangente, costuma ser dividida em:
Análise de requisitos (investigação dos requisitos);
Análise do domínio do problema.
No contexto específico da orientação
a objetos, análise implica em identificar e descrever os conceitos no domínio do problema. Já na atividade de análise foca-se na definição dos objetos de software e como eles colaboram para que os requisitos dos usuários sejam plenamente satisfeitos.
Por outro lado, a atividade de projeto denota uma solução, voltada a atender aos requisitos, considerando aspectos de tecnologia. Em geral, o projeto enfoca a arquitetura do sistema, definindo suas partes e a relação entre elas.
Portanto, análise pode ser traduzida em “faça a coisa certa”, e projeto em “faça certo a coisa”.
Um sistema desenvolvido sob o paradigma da orientação a objetos representa os objetos que encontramos no mundo real, no problema que estamos tratando, no negócio para o qual o estamos desenvolvendo o sistema. O foco da equipe de desenvolvimento passa a ser a identificação e modelagem dos objetos do mundo real que afetam o sistema.
A UML como uma linguagem padrão
A UML (Unified Modeling Language) é uma linguagem padrão para construção de projetos de sistemas, orientados a objeto, voltada para visualização, especificação, construção e documentação de artefatos de um sistema. A UML foi projetada para ser independente do método de desenvolvimento utilizado. Ela é uma linguagem de modelagem, não é um método de desenvolvimento, nem tão pouco um metodologia ou um processo de desenvolvimento de sistemas, uma vez que não determina a ordem e nem como os diagramas devem ser usados. Simplesmente disponibiliza os diagramas, sob as várias visões necessárias ao desenvolvimento de sistemas, e cada empresa utiliza da forma como lhe convém, ou seja, adequando a UML ao seu processo de desenvolvimento de sistema.
A UML é destinada à:
Visualizaçao
A modelagem gráfica tende a facilitar a compreensão, permitindo sua interpretação sem ambiguidades.
Especificaçao
Permite a construção de modelos precisos, sem ambiguidades e completos. A UML atende a esses quesitos sob o ponto de vista da análise, projeto e implementação.
Construçao
Os diagramas UML podem ser diretamente integrados a várias linguagens de programação tais como Java e C++.
Documentaçao
A UML abrange a documentação da arquitetura do sistema e de todos os seus detalhes. 
Clique no botão ao lado para visualizar um breve histórico da UML: 
Um Breve Histórico da UML
A UML nasceu da integração de três métodos emergentes orientados a objeto, que
na década de 1990, eram os mais populares entre os profissionais de
desenvolvimento de sistemas:
• O Método OMT (Object Modeling Technique) de Jacobson;
• O Método OOSE (Object-Oriented Software Engineering) de Rumbaugh;
• O Método de Booch.
Finalmente, em 1997, a UML foi adotada pela OMG (Object Management Group ou
Grupo de Gerenciamento de Objetos), como uma linguagem padrão de modelagem.
Atualmente a UML encontra-se em sua versão 2.0 (2.4.1, já existindo a 2.5 em
release BETA), e trouxe grandes novidades em relação à estrutura geral da
linguagem, principalmente a respeito da abordagem de quatro camadas e à
possibilidade de se desenvolver “perfis” particulares (oficial no site da OMG em
www.uml.org).
Desde a versão inicial, a UML sofreu mudanças substanciais.
Os diagramas da atual versão da UML
Os diagramas da UML são divididos em 2 grupos: Diagramas de Estruturas e Diagramas Comportamentais. No total, eles formam 14 diagramas, conforme ilustrado pela imagem:
Para conhecer cada diagrama detalhadamente, clique no botão ao lado:
Diagramas da atual versão da UML
Os diagramas da UML são divididos em 2 grupos: Diagramas de Estruturas e
Diagramas Comportamentais, e são em total de 14, conforme ilustrado pela
imagem:
A seguir, uma especificação de cada um dos diagramas:
Diagrama Especificação
Diagrama de perfil Diagrama mais recente e bastante abstrato. Permite a
criação de perfis que adapte a UML a plataformas,
tecnologias ou domínios específicas , para os quais a
linguagem não foi projetada originalmente
Diagrama de classes O mais popular dos diagramas. Tem muitas informações,
mas a principal finalidade é apresentar os tipos de
objetos presentes no sistema e os vários tipos de
relacionamentos existentes entre eles. Descreve para
cada classe, suas propriedades (atributos e métodos).
Diagrama de estruturas
compostas
Abrange um novo conceito, criado com a UML 2.0, que é
a capacidade de decompor hierarquicamente uma classe.
Diagrama de
componentes
Apresenta diferentes componentes de um sistema, além
de possíveis dependências entre eles. O conceito de
componente diz respeito a uma parte física de um
sistema de componente, englobando outras estruturas
relacionadas (como classes, interfaces etc.).
Diagrama de
implantação
Determina o ambiente físico sobre o qual o sistema vai
operar. Determina as necessidades de hardware do
sistema, evidenciando características físicas dos
servidores, estações, protocolos de comunicação, redes
etc.
Diagrama de objetos É um diagrama de classes, instanciado, ou seja, mostra
exemplos de objetos de cada classe, exibindo os
relacionamentos.
Diagrama de pacotes Pacotes são elementos que englobam outros. O mais
comum são classes, mas têm sido usados para outros
elementos, especialmente casos de uso. Representam a
divisão de um sistema grande em partes menores
(modularização).
Diagrama de atividades Descreve a lógica de procedimentos, processos de
negócios e fluxos de trabalho, suportando processamento
sequencial e paralelo.
Diagrama de casos de
uso
Mostra as funcionalidades do sistema e os atores que com
elas interagem.
Diagrama de estados Mostra, para cada objeto do sistema, o comportamento
do seu ciclo de vida.
Diagrama de sequencia Mostra como os objetos interagem para a realização de
um caso de uso, detalhando a troca de mensagem entre
os objetos.
Diagrama de
comunicação
É o antigo Diagrama de Colaboracão, que junto com o
diagrama de sequencia forma o diagrama de interação.
Tem a mesma finalidade do diagrama de sequencia,
porém não objetiva a temporalidade (sequencia).
Diagrama de visão geral
de interação
Novidade da versão 2.0. Mistura em um único diagrama
conceitos e elementos do diagrama de atividades e do 
diagrama de sequencia.
Diagrama de tempo Novidade da versão 2.0. Outro tipo de diagrama de
interação, onde o foco está nas restrições de
temporização. Usado para demonstrar a mudança no
estado de um objeto no tempo em resposta a eventos
externos.
A UML pode ser inserida dentro do contexto de qualquer que seja o processo de
desenvolvimento em uso, na medida em que é independente de tecnologia e
processo de desenvolvimento de software.
Uso da UML
Como a UML não determina quais diagramas usar nem por onde começar, cada um começa por onde desejar. Nem mesmo os idealizadores da UML conseguem usar todos os diagramas. Geralmente, as empresas escolhem um subconjunto deles e implementam nas fases de seus processos de desenvolvimento de sistemas. O ideal é que você encontre o seu conjunto de diagramas que funcione para o tipo de sistema que desenvolve.
Por exemplo: muitos começam pelo Diagrama de classes, na medida em que o consideram o diagrama mais relevante. Porém muitos iniciam pelo Diagrama de Casos de uso, cuja finalidade é modelar as principais funcionalidades do sistemas para atender às necessidades de seus usuários. Ambos estão usando a UML de forma correta e expressando como visualizam a sequencia mais adequada para desenvolver sistemas.
Martin Fowler e Steve Mellor propuseram três modos pelos quais pode-se usar a UML no desenvolvimento de sistemas:
1-Uml como esboço
O modo mais usado, onde os desenvolvedores usam a UML como forma de expressar aspectos relevantes de um sistema, esboçando ideias e alternativas do que pretende fazer. É uma possibilidade de discussão com a equipe de desenvolvedores. Seu foco é a comunicação seletiva em vez de especificação completa. Geralmente, são usados desenhos informais, sem ferramentas e cujo objetivo é a discussão de ideias visando à construção de
software de forma colaborativa. O modo UML, como esboço, está mais compatível com as metodologias ágeis, que preconizam mais código e menos documentação
2-Uml como projeto
Foca a completeza. Aqui a ideia é construir um projeto completo para ser codificado por programadores, valendo-se de ferramentas case para melhor entendimento dos modelos pela equipe. O modo UML, como projeto, está mais alinhado com os processos de desenvolvimento mais complexos, como processos iterativos e incrementais, como o PU (processo unificado) implementado através da ferramenta RUP (Rational Unifiec Process) prototipação.
3-Uml como linguagem de programaçao
Onde os desenvolvedores desenham os diagramas que são compilados para o código executável e a UML se torna o código fonte. Exige ferramentas mais sofisticadas. O modo UML, como linguagem de programação, tende a ser mais usado em modelos de desenvolvimento de prototipação.
Processos Iterativos de desenvolvimento e a UML
Um processo de desenvolvimento de software descreve uma abordagem para organizar as atividades relacionadas com a construção, a implantação e a manutenção de sistemas.
Os processos mais populares hoje são os iterativos, como:
O PU (Processo Unificado), em particular o RUP (Processo Unificado da Rational);
As metodologias ágeis, como o XP (eXtreming Programming) e Scrum.
Mas o que são os processos iterativos?
São processos onde o ciclo de vida do sistema é dividido em uma série de mini projetos, curtos, preferencialmente de duração fixa (por exemplo, 3 meses), denominados iterações.
Para conhecer um pouco mais sobre os processos iterativos, clique no botão ao lado:
Processos Iterativos de desenvolvimento e a UML
Um processo de desenvolvimento de software descreve uma abordagem para
organizar as atividades relacionadas com a construção, a implantação e a
manutenção de sistemas.
Os processos mais populares hoje são os iterativos, como o PU (Processo Unificado),
em particular o RUP (Processo Unificado da Rational) e as metodologias ágeis,
como o XP (eXtreming Programming) e Scrum.
Mas o que são processos iterativos, afinal?
São processos onde o ciclo de vida do sistema é dividido em uma série de mini
projetos, curtos, preferencialmente de duração fixa (por exemplo, 3 meses),
denominados iterações.
Cada iteração contém um subconjunto das funcionalidades do sistema. Em cada
iteração, temos as atividades de levantamento de requisitos, análise de requisitos,
projeto, implementação, testes e implantação, conforme ilustrado pela imagem a
seguir.
O ciclo de vida iterativo é baseado em incrementos sucessivos do sistema, pelas
iterações do processo. A cada iteração um pedaço do software é incrementado, daí
o nome processo iterático e incremental.
Claro que entre um incremento e outro, teremos feedbacks e ajustes na iteração
encerrada.
A figura anterior ilustra um processo com uso de 3 iterações, onde em cada uma
repete-se o conjunto de etapas, que começa com levantamento de requisitos e
termina com implantação das funcionalidades contidas naquela iteração.
Como já mencionado, a UML não define um processo padrão. Seus autores
reconhecem que uma linguagem de modelagem e um processo robusto são ambos
importantes. Eles ofereceram sua orientação sobre o que constitui um processo
adequado em publicações separadas daquelas exclusivamente dedicadas a UML,
porque a padronização de um processo estava fora do escopo da definição de UML.
A UML e os resultados em cada fase
Usar a UML, em um processo de desenvolvimento de sistemas, não implica, necessariamente, na elaboração de documentos ou uso de uma ferramenta case.
Muitas equipes, por exemplo, usam UML para desenhos à mão em reuniões e para discussão de ideias.
Uma ferramenta case é um programa que auxilia aos membros da equipe de desenvolvimento no estudo, modelagem e construção do sistema, possibilitando que vários diagramas possam ser elaborados em conjunto, representando a estrutura e comportamento do sistema a ser desenvolvido.
Para visualizar uma proposta de fluxo de trabalho com os resultados em cada fase, usando a UML em um processo iterativo, clique no botão abaixo:
Proposta de fluxo de trabalho usando a UML
A seguir, veja uma proposta de fluxo de trabalho com os resultados em cada fase,
usando a UML em um processo iterativo, conforme ilustração da figura anterior.
Levantamento de requisitos
• Diagrama de casos de uso, para identificação, informal, dos requisitos e
funcionalidades do sistema;
• Diagrama de classes conceitual, de alto nível, com modelagem apenas das
classes, com talvez, os atributos mais relevantes.
Análise de requisitos
• Casos de uso, que descrevem como as pessoas interagem com o sistema;
• Diagrama conceitual de classes;
• Diagrama de estados, caso seja necessário elucidar algum ciclo de vida de um
objeto relevante para o sistema;
• Diagrama de atividades, com algum fluxo de trabalho relevante, ou um caso de
uso mais complexo.
Nas 2 fases, o aspecto mais relevante é a efetiva comunicação com os usuários e
com a equipe de desenvolvimento.
Projeto
• Diagrama de classes, já a partir de uma perspectiva de software;
• Diagrama de sequencia, para cenários relevantes e comuns;
• Diagrama de estados;
• Diagrama de componentes, com a arquitetura do software;
• Diagrama de implantacão, para definição do ambiente físico e distribuição dos
componentes.
Atividade
Nessa atividade, vamos identificar os requisitos (necessidades dos usuários) de um sistema!
Para isso, primeiramente leia o texto “Necessidade de usuário”.
Com base no texto acima, identifique as funcionalidades que o sistema precisa ter para atender as necessidades do gerente e da Dona Sílvia.
As funcionalidades são: 
Liberar pagamento, gerir notas fiscais e controlar estoque.
Aula 02
Requisitos de um sistema
O primeiro passo para a modelagem de um sistema é saber quais são os seus requisitos. Nesse processo, o levantamento e mapeamento adequado dos requisitos de um sistema são passos fundamentais para o sucesso do produto final a ser gerado: o software.
O software precisa ter as funcionalidades adequadas para satisfazer as necessidades de seus usuários. Portanto, durante o processo de desenvolvimento de software é preciso ter cuidado e, se possível, garantias de que os requisitos estão sendo corretamente capturados e compreendidos pelos analistas de sistemas.
A UML (linguagem unificada de modelagem) disponibiliza para esse fim o diagrama de casos de uso, cuja finalidade é mapear as funcionalidades do sistema, evidenciando os atores que com elas interagem.
Levantamento de requisitos
De uma forma geral, os requisitos são necessidades dos usuários que os sistemas precisam atender.
As atividades de levantar e identificar os requisitos são fundamentais para todo o processo de desenvolvimento de sistemas, pois uma vez conhecidas as reais necessidades de seus usuários poderemos desenvolver o sistema adequado.
Em contrapartida, se as necessidades identificadas não forem as reais, o sistema não atenderá ao que seus usuários precisam, e a tendência é que seja descartado.
Levantamento de requisitos
Pense um pouco:
Apenas identificar os requisitos de um sistema corretamente é o suficiente?
Nao Pois temos de controlar o processo de desenvolvimento do software de forma a garantir que os requisitos estão sendo interpretados, entendidos e implementados de forma adequada pela equipe de desenvolvimento.
Ou seja, a garantia de atender aos usuários implementando adequadamente os requisitos que reflitam as suas necessidades depende de procedimentos de controle que garantam a qualidade do software durante todo o seu processo de desenvolvimento.
Levantar requisitos implica em sabermos o que o sistema precisa fazer para atender as necessidades de seus usuários. A qualidade do levantamento de requisitos influencia todo o processo de desenvolvimento, especialmente as validações junto aos usuários, necessárias ao longo do processo de desenvolvimento
e sobretudo na adequação do software.
Tipos de requisitos
O levantamento de requisitos visa identificar dois tipos de requisitos. Veja:
Os requisitos funcionais representam as funcionalidades necessárias para atender as necessidades dos usuários do sistema.
Veja alguns exemplos de requisitos funcionais para um sistema de Folha de Pagamento:
Registro dos dados dos funcionários;
Registro do salário bruto de cada funcionário;
Cálculo da folha de pagamento;
Cadastramento da tabela de imposto de renda;
Emissão do recibo de pagamento;
Dentre outras funções necessárias ao sistema.
Os requisitos nao funcionais Apresentam restrições e qualidades do sistema e suas funcionalidades.
Eles representam os atributos e propriedades do sistema. Podem ser expressos em termos do sistema como um todo, como por exemplo: o sistema deve ser operado por uma tela de toque (touch screen), denotando um requisito não funcional de usabilidade.
Os requisitos não funcionais podem representar também propriedades de uma função específica. Por exemplo: o usuário pode ter a necessidade de especificar que a impressão do boleto de venda (função) não deve demorar mais que 10 segundos (requisito não funcional), representando um requisito não funcional que visa a performance do sistema.
Diagrama de casos de uso
Como vimos, o diagrama de casos de uso tem como objetivo apresentar os requisitos funcionais do sistema. Ou seja, é um diagrama que começa a ser usado após o levantamento de requisitos, de forma a mapear as funcionalidades do sistema, documentando o que o sistema faz.
O diagrama de casos de uso é um dos mais informais e simples, dentre os diagramas propostos pela UML (Linguagem Unificada de Modelagem), e sua finalidade é apresentar as principais funcionalidades que o sistema precisa ter.
O diagrama de casos de uso pode, ainda, ser usado durante determinadas técnicas de elicitação de requisitos, como o JAD (Joint Application Design), que visa extrair requisitos de usuários de forma coletiva e colaborativa.
Para saber mais, clique no botão abaixo:
Durante uma sessão JAD, componentes da equipe técnica, como engenheiros de requisitos e/ou analistas de sistemas, podem desenhar diagramas de casos de uso, para identificar as funcionalidades requeridas pelo sistema, de forma a atender as necessidades desses usuários.
Outra finalidade do diagrama de casos de uso é possibilitar que os requisitos possam ser validados junto aos usuários, de forma que se tenha certeza de que:
Todos os requisitos funcionais foram identificados;
O entendimento da equipe de desenvolvimento, no que tange aos requisitos identificados, está correto e corresponde à realidade.
Nesse diagrama, não mostramos detalhes de como o sistema realizará suas funcionalidades.
Elementos do diagrama de casos de uso
Por ser simples, o diagrama de casos de uso possui poucos elementos passíveis de serem representados, que são:
Os atores
Os casos de uso
Os relacionamentos
A figura a seguir ilustra um diagrama de casos de uso, contendo:
“Usuário” e “Atendente” são os atores.
Os casos de uso “Matricular em curso”, “Incluir Disciplina” e “Cancelar Disciplina”, estão interagindo com o ator “Usuário”. Isto significa que o Usuário é o ator que interage com essas três funcionalidades.
O caso de uso “Cancelar Matrícula em Curso”, interagindo com o ator “Atendente”, ou seja, “Atendente” é quem pode “Cancelar Matrícula de um Curso”, a quarta funcionalidade disponível no sistema.
Ator
Vamos conhecer cada elemento do diagrama de casos de uso separadamente, e vamos iniciar pelo elemento Ator.
O ator é algo com comportamento, que interage diretamente com o sistema. Um ator participa (realiza) um ou mais casos de uso do sistema. A representação do ator, no diagrama de casos de uso, é o boneco, chamado de stickman, conforme a figura ao lado:
Um ator é o papel que o agente desempenha em relação ao sistema. Ele pode representar:
Papéis internos (Gerente de Compras) ou externos (Cliente e Fornecedor)
Setores e departamentos da empresa (Contabilidade e Contas a Pagar), bem como funções desempenhadas na empresa (almoxarifado).
Dispositivos eletrônicos, como por exemplo hardware e servidores, ou dispositivos lógicos, como sistemas.
Identificando atores
O primeiro passo para a construção do modelo de casos de uso é a identificação de atores. Algumas perguntas são úteis nesta situação, veja:
Quais órgãos, empresas ou pessoas farão uso deste sistema de informação?
	
Que sistemas ou equipamentos irão se comunicar com o sistema que será desenvolvido?
	
Quem deve ser informado de alguma ocorrência no sistema?
	
A quem pode interessar os requisitos funcionais do sistema?
Casos de uso
Outro elemento do diagrama são os casos de uso.
Segundo Jacobson, um dos criadores da UML, um caso de uso é uma descrição narrativa de uma sequência de eventos que ocorre quando um ator usa um sistema para realizar uma tarefa.
Os casos de uso representam, através de elipses, as funcionalidades do sistema, conforme a imagem a seguir:
Casos de uso
Sendo uma funcionalidade, o nome do caso de uso deve ser composto por um verbo no Infinitivo + complemento verbal, como o exemplo acima: “Matricular em Curso”.
Matricular em curso
Sendo uma funcionalidade, o nome do caso de uso deve ser composto por um verbo no Infinitivo + complemento verbal, como o exemplo acima: “Matricular em Curso”.
Identificando casos de uso
Como já fizemos a identificação dos atores, podemos passar à identificação dos casos de uso. Esse processo deve seguir duas etapas, veja:
Em primeiro lugar, podemos pensar nos casos de uso que representam os objetivos dos atores. Estes casos de uso representam os processos da empresa, e algumas perguntas são úteis neste momento:
Quais as necessidades e objetivos de cada ator em relação ao sistema?
Que informações serão produzidas pelo sistema?
O sistema realizará alguma ação que ocorre de forma regular no tempo?
Existe um caso de uso para atender cada requisito funcional?
Em seguida, podemos pensar nos casos de uso que não representam um benefício direto para os atores, mas são necessários para o funcionamento do sistema. Tais casos de uso englobam manutenção de cadastros e de informações provenientes de outros sistemas.
Cenários
Um caso de uso é um conjunto de cenários. Descreve uma sequência de ações do ator e do sistema. Cada sequência de ações é chamada de cenário.
Portanto, um cenário é uma sequência específica de ações que ilustra o comportamento do caso de uso.
Atividade
Nessa atividade, você deverá identificar os atores e os casos de uso envolvidos em um diagrama de casos de uso.
Para isso, primeiramente leia o texto “Clínica oftalmológica”.
Com base no texto acima, identifique os atores e os casos de uso envolvidos e desenhe o esboço do diagrama de casos de uso.
Observação:
Realize essa atividade fazendo uso de papel e caneta ou word. Ao término da mesma, você pode visualizar o gabarito e compará-lo com a sua resposta.
Gabarito atividade
Passo 1: identificação dos atores - elementos que interagem com o sistema
(geralmente substantivos)
? “Paciente”, “Atendente” e “Médico”
Passo 2: para cada ato, identificar os casos de uso com os quais se relacionam
(ações, geralmente verbos).
? “Atendente”: “Agendar Consulta”, “Agendar Exame”, “Cancelar Consulta” e
“Cancelar Exame”
? ‘Médico”: “Consultar Paciente”
Importante: embora o paciente seja extremamente relevante nesse processo, ele
não interage diretamente com nenhuma funcionalidade do sistema, embora todos
os dados imputados no sistema sejam fornecidos por ele.
Em princípio, não é considerado um ator do ponto de vista da interação com o
sistema. Todavia muitos autores consideram-no ator, juntamente com os
verdadeiros atores de cada caso de uso.
Assim sendo, podemos ter duas soluções, representadas nos dois diagramas de
casos de uso a seguir:
o A primeira mais alinhada com o conceito de ator, na qual o paciente
não figura entre
os atores.
o A segunda mais alinhada com a situação real, na qual o “Atendente” e
o “Médico” inteagem com o sistema, baseado no que lhes diz o
“Paciente”.
Relacionamentos ou associações
O diagrama de casos de uso possibilita, ainda, a existência de relacionamentos entre:
Atores e casos de uso
Atores entre si
Casos de uso entre si
A seguir, vamos conhecer cada tipo de relacionamento com mais detalhe!
Relacionamentos entre atores e casos de uso
Esse é o relacionamento mais comum, e é indicado por uma linha sólida, que liga o ator ao caso de uso, denotando que o ator interage com o caso de uso.
Nos termos técnicos, dizemos que o ator realiza o caso de uso. A figura a seguir ilustra esse relacionamento:
A comunicação nesse relacionamento é bidirecional, ou seja, o ator informa dados ao caso de uso e recebe informações por ele processadas.
Relacionamentos de atores entre si
Entre atores, é possível haver o relacionamento de generalização/ especialização, representado por uma linha sólida com uma seta na extremidade que aponta para o ator geral, conforme ilustrado nesta imagem:
Observe que nesse exemplo, o ator geral é o “Funcionário” e o ator especialista, o “Gerente”. Este também exerce as atividades de um funcionário, porém como gerente tem tarefas específicas a sua função.
Vamos analisar mais um exemplo de relacionamento de generalização/ especialização entre atores. Observe a leitura desse diagrama:
O ator geral
é “Usuário”
Os atores especializados são “Aluno” e “Atendente”, que se relacionam com todos os casos de uso associados ao ator “Usuário”.
Apenas o ator “Atendente” se relaciona com “Cancelar Matrícula em Curso”, ou seja, apenas o “Atendente” realiza esse caso de uso.
Esta é uma associação útil para definir a sobreposição de papéis entre atores, na qual:
• O ator especializado interage com o caso ao qual está associado diretamente e com todos os casos de uso com o qual o ator generalizado se associa;  
• Já o inverso não ocorre: o ator generalizado não interage com os casos de uso associados ao ator generalizado.
Relacionamentos de Casos de uso entre si
Casos de uso podem conectar por três tipos de relacionamentos:
Inclusão (include ou uses);
Extensão (extend);
Generalização.
Relacionamentos entre Casos de uso por inclusão
Nesse tipo de relacionamento, um caso de uso (principal) incorpora, explicitamente, o comportamento de outro caso de uso (incluído).
O caso de uso incluído é parte integrante do caso de uso principal. A fatoração (separação desse caso de uso) acontece porque outros casos de uso também poderão incorporar o caso de uso incluído e, assim, evitar repetições de fluxos.
O diagrama abaixo demonstra o relacionamento de casos de uso por inclusão:
Relacionamentos entre Casos de uso por inclusão
Vamos analisar um caso de uso por inclusão. Observe o diagrama ilustrado a seguir:
O caso de uso “Validar Disciplina” é usado por dois casos de uso: “Incluir Disciplina” e “Eliminar Disciplina”. Isso significa que o caso de uso “Validar Disciplina” está contido em ambos, ou seja, se formos descrever as interações do que acontece dentro do caso de uso, perceberemos que tanto “Incluir Disciplina” quanto “Eliminar Disciplinas” terão uma parte igual.
Esse caso de uso será obrigatoriamente executado, em algum ponto da execução do caso de uso “Incluir Disciplina”, como também em algum ponto na execução do caso de uso “Eliminar Disciplina”.
Normalmente essa percepção da necessidade de fatoração ocorre quando estamos descrevendo os casos de uso, assunto de que trataremos na próxima aula.
 
O cenário comum a mais de um caso de uso é capturado em outro caso de uso. No caso do exemplo anterior, “Validar Disciplina” agrega o que é comum a “Incluir Disciplina” e a “Eliminar Disciplina”.
Relacionamentos entre Casos de uso por extensão
Esse tipo de relacionamento é usado para descrever cenários opcionais em um caso de uso; uma variação do comportamento normal.
Veja a seguir uma descrição do relacionamento de casos de uso por extensão:
Um caso B (caso de uso estendido) estende A (caso de uso principal) quando alguma condição interrompe a execução do caso A (caso de uso principal) para que B (caso de uso estendido) execute e retorne, ao final, ao caso de uso A (caso de uso principal).
A interrupção é feita no chamado ponto de extensão. Esta imagem ilustra o relacionamento de extensão:
Exemplos de Casos de uso por extensão
Para que você entenda melhor como acontece o relacionamento de casos de uso por extensão, trouxemos dois exemplos que iremos analisar. Veja:
O caso de uso “Enviar Informe de Dívida” estende o caso de uso “Cancelar Matrícula em Curso”.
Esse caso de uso somente será executado se o cancelamento do curso implica em pagamento de dívida do aluno; caso o aluno esteja quite com o curso, o caso de uso não será executado.
Observe como os casos de uso “Pagar em Cheque” ou “Pagar em Cartão” estendem o caso de uso “Pagar Mensalidade”.
 
Neste caso, haverá uma condição a ser avaliada, que é a forma de pagamento e, de acordo com o valor desta, será executado um ou outro caso de uso: apenas um deles será executado, ou seja, são mutuamente exclusivos.
Relacionamentos entre Casos de uso por generalização
Esse tipo de relacionamento é usado quando um caso de uso é semelhante a outro, mas executa algumas funções a mais.
Ele é pouco usado, pois seu uso confunde-se com o extend, na medida em que este também pode resolver essa questão da variação de comportamento, neste caso um comportamento com adição de funcionalidade.
O diagrama a seguir ilustra o relacionamento de casos de uso por generalização:
Vamos analisar um exemplo de caso de uso por generalização. Observe:
Neste exemplo existe a especialização do caso de uso “Solicitar Produtos”, que pode ser pela internet ou pelo telefone. De acordo com a forma de solicitação, o comportamento do caso de uso vai variar, porém existem partes comuns, que estão especificadas em “Solicitar Produtos” (caso mais geral).
Aula 03
A importância da especificação de casos de uso
O diagrama de caso de uso é útil, na medida em que nos fornece uma visão geral das funcionalidades do sistema (conjunto de casos de uso) e dos atores que com elas se relacionam. Todavia, é pobre na medida em que não entendemos como a interação ocorre em cada caso de uso.
É nesse contexto que identificamos a importância da especificação dos casos de uso. Podemos dizer, então, que o diagrama é um sumário gráfico do conjunto de casos de uso (funcionalidades) de um sistema.
O real valor da técnica de especificação de casos de uso está na adequada descrição textual de cada caso de uso, em que veremos com clareza como os atores utilizam o sistema. Mas a UML nada define sobre o texto narrativo, que descreve o caso de uso.
Se o tempo destinado ao modelo de casos de uso for pouco, concentre-se na especificação ou descrição dos casos de uso e esqueça o diagrama. Mas se tiver oportunidade, modele o diagrama, pois é uma ótima ferramenta de diálogo com usuário, pela sua simplicidade.
Os formatos para especificar casos de uso
Craig Larman, em seu livro Utilizando UML e Padrões: uma introdução à análise e ao projeto orientados a objeto e ao desenvolvimento iterativo, cita três formatos para descrever os casos de uso, veja:
Formato Resumido
Corresponde ao resumo de um parágrafo, geralmente contendo o cenário principal do caso de uso e o cenário de sucesso.
Você deve utilizá-lo na análise inicial de requisitos, para obter uma ideia do assunto e o escopo do caso de uso.
Em essência, a especificação ou descrição textual de um caso de uso deve mostrar a interação entre o ator e o sistema (caso de uso em questão), ou seja, a “conversa” entre ator e sistema na realização (acontecimento) do caso de uso.
FORMATO INFORMAL
Refere-se aos múltiplos parágrafos que cobrem vários cenários de uso.
Você deve utilizá-lo na mesma condição do formato resumido.
Em essência,
a especificação ou descrição textual de um caso de uso deve mostrar a interação entre o ator e o sistema (caso de uso em questão), ou seja, a “conversa” entre ator e sistema na realização (acontecimento) do caso de uso.
FORMATO COMPLETO
Nesse formato, todos os cenários (principal e alternativos) são descritos em detalhes, com seções adicionais, complementando a especificação, com elementos que definem os pré e pós-condições.
Você deve utilizá-lo depois que muitos casos de uso tiverem sido descritos no formato resumo ou informal, geralmente durante a fase de análise de requisitos e de sistemas. Para os casos de uso relevantes, tende a ser o formato mais adequado.
Em essência, a especificação ou descrição textual de um caso de uso deve mostrar a interação entre o ator e o sistema (caso de uso em questão), ou seja, a “conversa” entre ator e sistema na realização (acontecimento) do caso de uso.
Exemplo de descrição textual de um caso de uso
Para mostrar a diferença entre os três tipos de especificação, vamos usar como exemplo o caso de uso “Registrar Venda”, com o trecho de diagrama de casos de uso, a seguir.
Observe que neste diagrama foram considerados atores tanto o caixa como o cliente. O motivo é que o cliente também interage com o sistema, quando o pagamento é em cartão, por exemplo.
FORMATO RESUMIDO
Caso de uso: “Registrar Venda”
O cliente chega a um ponto de pagamento da loja com os itens que deseja adquirir. O caixa registra cada item desejado. Ao final, o sistema apresenta o total a pagar e a relação de itens comprados.
O cliente informa e o caixa registra os dados do pagamento, que são validados e registrados pelo sistema. O sistema atualiza o estoque. O cliente recebe o recibo das compras e sai com os itens adquiridos.
FORMATO INFORMAL
Caso de uso: “Registrar Venda”
- Cenário principal (de sucesso): Cliente chega ao ponto de pagamento da loja com os itens a serem adquiridos. Caixa usa o sistema PDV para registrar todos os itens comprados. Ao final, sistema apresenta o total a pagar e a relação de itens comprados.
Cliente informa e caixa registra os dados do pagamento, que são validados e registrados pelo sistema. Sistema atualiza o estoque. Cliente recebe o recibo das compras e sai com os itens adquiridos.
- Cenários alternativos: Se o identificador do item adquirido não for encontrado no sistema, este notifica o caixa e sugere que entre manualmente com a identificação do item (que talvez esteja corrompido).
Se o cliente informou o pagamento em cartão e a operadora não aprova a transação, informa o cliente e solicita uma nova forma de pagamento.
Se o sistema não consegue atualizar o estoque, sugere que o caixa registre no formulário de problemas do dia, para o balanço ao final do dia.
FORMATO COMPLETO
Vários gabaritos e padrões de formatos estão disponíveis para casos de uso relevantes que precisam de especificações detalhadas.
Para visualizar as principais seções que compõem o formato completo, bem como o exemplo de caso de uso “Registrar Venda”, clique no botão.
Exemplo de especificação Formato Completo
Vários gabaritos e padrões de formatos estão disponíveis para casos de uso
relevantes que precisam de especificações detalhadas. A seguir, descrevemos as
principais seções que compõem o formato completo:
Seção da Especificação Significado
Nome do caso de uso (*) Verbo no Infinitivo + complemento verbal.
Escopo (*) O nome do sistema/ projeto.
Nível Objetivo do usuário ou subfunção (include, extend e
especialização).
Atores (*) Atores envolvidos: principal e secundários.
Interessados e Interesses Quem se importa com esse caso de uso e o que eles
desejam?
Pré-condição (*) O que precisa ser verdade para esse caso de uso
acontecer.
Pós-condição ou garantia
de sucesso (*)
O que precisa ser verdade quando da finalização bem
sucedida desse caso de uso.
Cenário principal (*) O cenário de sucesso, um caminho típico, incondicional.
O caso de uso foca no cenário principal.
Cenários alternativos ou
extensões (*)
Cenários alternativos, quando o cenário principal tem
uma variação do fluxo bem-sucedido.
- A especificação deve indicar o ponto em que se se
estende o cenário principal (ou típico);
- A especificação deve indicar o ponto em que se
retorna ao cenário principal (ou típico) ou em que se
encerra o caso de uso.
Requisitos especiais Requisitos não funcionais relacionados
(*) São as seções mais usadas pela maioria dos autores e analistas de
sistemas.
Exemplo de caso de uso “Registrar Venda”
Nome do caso de uso: “Registrar Venda”
Escopo: Sistema de Vendas – PDV
Nível: Usuário
Atores: Caixa
Interessados e Interesses:
- Caixa: deseja que o sistema seja eficiente, sem erros e que tenha fácil
utilização;
- Cliente: deseja encontrar os produtos de que precisa, adquiri-los de forma
rápida, sem muito esforço e, ao final, obter um comprovante da compra;
- Orgãos fiscais: deseja cobrar os impostos de cada venda realizada;
- Operadora de cartão: deseja receber solicitações de autorização de crédito no
formato e protocolo corretos.
- Etc.
Pré-condição: todos os produtos registrados no sistema e com respectivos preços;
caixa autenticado e PDF registrado.
Pós-condições: venda salva, impostos calculados, estoques atualizados,
autorizações de pagamento registradas, recibo gerado.
Cenário principal (ou fluxo básico)
1. Cliente chega ao PDV com os itens que deseja adquirir;
2. Caixa inicia uma nova venda;
3. Para cada item de venda do cliente, faça:
a. Caixa insere o identificador do item;
b. Sistema localiza o item;
c. Sistema apresenta a linha do item de venda, com o identificador, nome e
valor unitário do produto;
d. Sistema calcula os impostos do item;
4. Sistema apresenta o valor total da venda com impostos calculados;
5. Caixa informa total ao cliente e solicita o pagamento;
6. Caixa informa o pagamento do cliente;
7. Sistema registra e trata o pagamento do cliente;
8. Sistema finaliza a venda e apresenta o recibo;
9. Sistema contabiliza a baixa no estoque de cada item vendido.
Cenários alternativos (extensões)
2.a. Sistema não inicializa:
1. Caixa inicia a venda em planilha manual (contingência), registrando cada
item e o pagamento em planilha eletrônica e encerra o caso de uso.
3.a. Sistema não localiza o identificador do item:
1. Sistema avisa o erro e rejeita a entrada;
2. Caixa responde ao erro.
2.a. Existe o ID do item legível:
1. Caixa insere o identificador do item;
2. Sistema mostra descrição e preço.
2.b. Existe preço na etiqueta:
1. Caixa solicita ao gerente executar operacão de correcão;
2. Gerente realiza a correção;
3. Caixa indica a entrada manual de preço, insere preço e solicita imposto
padrão para essa quantia.
2.c. Caixa invoca ajuda no sistema para localizar o produto, a fim de obter
identificação e preços reais do item.
2.d. Caso contrário, caixa pergunta a um funcionário o preço e o
identificador do item e executa a entrada manual do itentificador (ver
acima, 2.a) ou do preço do item (ver acima 2.b).
3-4 a. Cliente solicita o cancelamento de um item da venda:
1. Caixa insere o identificador do item a ser removido;
2. Sistema remove o item e exibe o total parcial atualizado.
3-6 a. Cliente solicita o cancelamento da venda:
1. Caixa cancela a venda no sistema.
7.a. Pagamento em dinheiro:
1. Caixa insere a quantia do dinheiro fornececida;
2. Sistema apresenta o valor do troco e libera a gaveta do dinheiro;
3. Caixa deposita o dinheiro fornecido e entrega o troco ao cliente;
4. Sistema registra o pagamento em dinheiro.
7.b. Pagamento com cartão de crédito:
1. Caixa insere dados do cartão do cliente;
2. Sistema mostra o pagamento para confirmação;
3. Caixa confirma o pagamento;
4. Sistema envia solicitação de autorizacão de pagamento à administradora do
cartão do cliente.
4.a. Sistema detecta falha ao tentar se comunicar com sistema externo:
1. Sistema avisa do erro ao caixa;
2. Caixa solicita ao cliente forma de pagamento alternativa.
5. Sistema recebe
aprovação de pagamento;
6. Sistema registra ao pagamento com cartão de crédito;
7. Sistema apresenta o mecanismo para entrada do pagamento a Crédito;
8. Caixa solicita ao cliente a assinatura para pagamento a crédito e cliente
fornece a assinatura;
9. Assinatura em papel, caixa, insere o papel na gaveta e a fecha.
8.a. Impressora não tem papel:
1. Se o sistema detecta a falha, avisa sobre o pagamento;
2. Caixa repõe o papel;
3. Caixa solicita outro recibo.
Requisitos especiais
1. Interface de usuário com tela sensível a toque em um monitor de tela
plana com pelo menos 23 polegadas;
2. Resposta de autorização de crédito, dentro de 30 segundos, em 90% dos
casos;
3. A recuperação de falhas de servidores deve ser consistente e robusta.
Observe que cada passo do cenário principal é numerado e em cada um pode haver
uma ou mais falhas (incucessos).
Nos cenários alternativos, temos um número e uma letra. Por exemplo: no passo 2
do cenário principal (caixa inicia uma nova venda), pode haver uma exceção
(sistema não inicia), que é tratada no cenário alternativo como 2.a.), ou seja, a
primeira (a) alternativa do passo 2.
Já o passo 7 (sistema registra a trata o pagamento do cliente), possui dois cenários
alternativos, representados por 7.a (pagamento em dinheiro) e 7.b (pagamento em
cartão de crédito). Caso tívessemos uma terceira forma de pagamento, como por
exemplo, cheque, este seria o passo 7.c dos cenários alternativos.
Repare na quantidade de detalhes dessa especificação. Nesse formato, devem ser
considerados todas as possibidades de exceção e insucesso de cada passo do
cenário principal.
A especificacão anterior poderia ter muitos mais detalhes, como por exemplo o
tratamento das seguintes exceções:
? A qualquer momento o sistema falha;
? Ttratamento de outras formas de pagamento (cheque, débito);
? Caixa cancela o pagamento, e muitos outros.
O detalhamento vai depender do sistema e da necessidade.
Especificação de casos de uso que contenham Include
Vamos entender como especificar casos de uso que contenham Include por meio de um exemplo. Veja:
Considere o trecho de diagrama a seguir, de um sistema de locadora de DVDs, no qual os dependentes podem ser incluídos e eliminados do plano de sociedade com a locadora:
Observe que existe um caso comum a ambos: “Pesquisar Dependente”. A partir da especificação de um deles, o “Incluir Dependente”, vamos entender como se dá o uso do <include>.
Para visualizar como realizar a especificação do caso “Incluir Dependente”, clique no botão ao lado:
Especificação do caso “Incluir Dependente”
Cenário principal
1. Atendente informa identificação do cliente;
2. Sistema localiza dados do cliente informado;
3. Atendente informa dados do dependente;
4. Sistema localiza dados do dependente informado – <<Include Pesquisar
Dependente >>;
5. Sistema registra dados do dependente do cliente informado.
Cenários alternativos
2.a. Cliente não localizado:
- Sistema informa “Cliente não registrado no sistema” e retorma ao
passo 1 do cenário principal;
4.a. Dependente já registrado:
 - Sistema informa “Dependente já registrado no sistema” e retorna ao
passo 3 do cenário principal.
A inclusão do caso “Pesquisar Dependente” ocorre no passo 4 do cenário principal.
Nesse momento, ocorre a interrupção na execucão do caso “Incluir Dependente” e
o fluxo desvia para a execução do caso “Pesquisar Dependente”.
Ao final do caso de uso “Pesquisar Dependente”, o fluxo retorna para o cenário
principal do caso “Incluir Dependente” no passo seguinte ao da inclusão do caso de
uso, que é o passo 5.
Especificação de casos de uso que contenham extends
Para explicar como é especificado o uso de casos de extensão (extends), vamos usar diagrama a seguir. Observe:
Para visualizar como realizar a especificação do caso “Registrar Devolução de DVD”, clique no botão.
Especificação do caso de uso “Registrar Devolução de DVD”
Segue a especificação do caso de uso “Registrar Devolução de DVD”, mostrando
como declarar o uso de casos de extensão:
Solução:
Caso de uso: “Registrar Devolução de DVD”
Cenário principal
1. Atendente informa identificação da mídia;
2. Sistema localiza locação com a mídia informada;
3. Sistema apresenta registro da locação com valor a pagar;
4. Atendente informa forma de pagamento;
5. Caso forma de pagamento seja
DINH: <extends PAGAR EM DINHEIRO>
CARTÃO: <extends PAGAR no CARTÃO>
 Fim-Caso;
6. Sistema registra devolução;
7. Sistema emite recibo de quitação do pagamento.
Cenários alternativos
1.a. Mídia não localizada:
- Sistema informa “Mídia não registrada no sistema ou não alugada” e
retorna ao passo 1 do cenário principal.
2.a. Locação não localizada (inconsistência de dados):
 - Sistema informa “Locação não registrada para a mídia no sistema” e
encerra o caso de uso.
2.b. Se data corrente > data prevista de devolução, então calcular multa
<<Extends CALCULAR MULTA POR ATRASO>>
Destacamos em negrito, para melhor visualização, as chamadas aos casos de
extends. No cenário principal, opcionalmente usamos “pagar em dinheiro” ou
“pagar em cartão”, e nos cenários alternativos, condicionalmente, usamos
“calcular multa por atraso”.
Temos três extends no diagrama, porém dois deles estão relacionados entre si e o terceiro não.
O caso de uso “Calcular Multa por Atraso” será usado se e apenas se (condição) a entrega estiver sendo feita com atraso. 
á os casos de uso “Pagar em Dinheiro” e “Pagar em cartão” são mutuamente exclusivos, ou seja, apenas um deles será executado, de acordo com a forma de pagamento (condição) escolhida pelo cliente.
Considerações finais sobre especificações
Conforme já mencionamos, a UML não descreve nada a respeito de especificações textuais de casos de uso, limitando-se a especificar os elementos e uso do diagrama de casos de uso.
Porém, como também já mencionamos, a especificação de casos de uso é extremamente relevante para o entendimento dos requisitos para futura implementação de outros modelos e dos códigos fontes dos programas que vão compor o sistema.
Desse modo, existem várias formas e padrões para especificar casos de uso. O que descrevemos anteriormente não é o melhor e nem tampouco o mais completo, porém vemos muito seu uso na vida profissional.
Escolha o seu padrão, o seu formato e vá em frente. O importante é que seja algo que sua equipe saiba ler e escrever e a comunicação entre vocês possa ser clara e efetiva.
Dicas para especificações de casos de uso
1-Não use detalhes de implementação ou de determinada tecnologia em suas especificações.
2-Procure não associar casos de uso a telas de sistemas.
3-Utilize um formato de especificação que deixa o diálogo mais claro entre ator e caso de uso. O modelo tem duas colunas. Na primeira, descrevemos as ações do ator, e na segunda as ações do sistema.
4-Os casos de uso incluídos (chamados de include) ou estendidos (chamados por extends) também devem ter descrição textual, podendo estar no formato resumido ou informal.
5-Algumas perguntas podem ajudar no detalhamento dos cenários principal e alternativos. Exemplo: Quando tudo ocorre na normalidade (com sucesso), qual o comportamento do sistema?
6-Quando um passo for muito complicado, ele pode vir a ser um novo caso de uso, que se relacionará com o caso original pelo estereótipo include.
7-Faça casos de uso enxutos, pois casos longos podem não ser lidos em sua totalidade.
Para conhecer cada dica de especificações de casos de uso com mais detalhe, clique no botão ao lado:
Dicas para especificações de casos de uso
Seguem algumas dicas sobre especificações de casos de uso:
1. Não use detalhes de implementação ou de determinada tecnologia em
suas especificações.
a. A tecnologia ficará obsoleta, e seu caso de uso terá que ser
revisto.
b. Exemplos: imagine um sistema de autoatendimento bancário, em
caixas eletrônicos. Ao descrever a ação do usuário “informar seus
dados de acesso”, evite descrever como, por exemplo: “Usuário
insere o seu cartão”. Em vez disso, use: “Usuário informa dados da
agência, conta e senha de acesso”.
c. Amanhá a tecnologia muda e a identificação passa a ser, por
exemplo, pela leitura da digital, e o caso de uso precisará ser
escrito novamente. Fazendo como o proposto, estará adequado a
qualquer tecnologia.
2. Procure não associar casos de uso a telas de sistemas.
a. Muitos autores sugerem que listemos esboços de telas nas
especificações de casos de uso. Geralmente os autores são
favoráveis e os processos de desenvolvimentos são ágeis, visando
entregar o código o mais rápido possível.
b. Procure evitar essa prática, pois no momento em que estamos
especificando os casos de uso, ainda é cedo para pensarmos em
interface, que será objeto da fase de projeto do sistema.
c. Resista a essa tentação, pois sabemos que os usuários adoram
telas.
3. Existe um formato de especificação de que muitos gostam, pois fica mais
claro o diálogo que acontece entre ator e caso de uso. O modelo tem 
duas colunas. Na primeira, descrevemos as ações do ator, e na segunda as
ações do sistema.
4. Os casos de uso incluídos (chamados de <include>) ou estendidos
(chamados por <extends>) também devem ter descrição textual, podendo
estar no formato resumido ou informal.
5. Perguntas que podem ajudar no detalhamento dos cenários principal e
alternativos:
a. Quando tudo ocorre na normalidade (com sucesso), qual o
comportamento do sistema? – Esse será o passo a passo do cenário
principal;
b. Algo pode acontecer de forma diferenciada nesse passo? – Indica
um cenário alternativo (relacionado a esse passo);
c. O que pode dar errado nesse passo? – Da mesma forma que a
pergunta anterior, esta conduz à identificação de um cenário
alternativo.
6. Quando um passo for muito complicado, ele pode vir a ser um novo caso
de uso, que se relacionará com o caso original pelo estereótipo
<include>.
7. Faça casos de uso enxutos, pois casos longos podem não ser lidos em sua
totalidade.
Dicas para especificações de casos de uso
Veja um exemplo de caso de uso:
Caso de uso: “Reserva Quarto”
Sistema: Gestão de Quartos de Hotel
Atividade
O diagrama de caso de uso é útil, na medida em que nos fornece uma visão geral das funcionalidades do sistema (conjunto de casos de uso) e dos atores que com elas se relacionam. No entanto, ele não informa como ocorre a interação em cada caso de uso. Nesse cenário, entra em cena a especificação de casos de uso. Explique qual a importância dessa técnica:
Gabarito
O real valor da técnica de especificação de casos de uso está na adequada descrição textual de cada caso de uso, em que veremos com clareza como os atores utilizam o sistema.
Atividade
Craig Larman cita três formatos para descrever os casos de uso: o resumido, o informal e o completo.
Analise as informações abaixo e relacione cada formato à sua devida definição:
Formato completo -Todos os cenários (principal e alternativos) são descritos em detalhes, com seções adicionais, complementando a especificação, com elementos que definem os pré e pós-condições.
Formato resumido-Resumo de um parágrafo, geralmente contendo o cenário principal do caso de uso e o cenário de sucesso.
Formato informal-Múltiplos parágrafos que cobrem vários cenários de uso.
Atividade
Considere a seguinte descrição do que ocorre na realização do caso de uso “Emprestrar DVD”, referente a um sistema de uma locadora de DVD:
- O cliente escolhe os DVDs que pretende alugar e os entrega ao caixa;
- O caixa solicita ao cliente sua identificação (CPF ou telefone);
- O cliente informa sua identificação e o sistema verifica se o cliente está devidamente cadastrado;
- Estando cadastrado, o caixa informa o ID de cada DVD a ser alugado, quando o sistema verifica se o ID está devidamente cadastrado e mostra o nome do DVD, com o respectivo preço de locação;
- Ao final do registro de todos os DVDs, o caixa confirma a locação. O sistema, nesse momento, registra a locação dos DVDs informados, imprime o recibo de locação, com o valor que deve ser pago no ato da devolução;
- Caso cada DVD informado para locação não esteja cadastrado, deve ser tratado pelo sistema, emitindo uma mensagem de erro, da mesma forma que a identificação do cliente não cadastrado.
Descreva a solução para o caso de uso:
Caso de Uso: Emprestar DVD
Pré-condição: cliente e DVDs devidamente registrados
Pós-condição: empréstimo devidamente registrado
Cenário principal:
1. Caixa informa ID do cliente;
2. Sistema localiza cliente com ID do cliente;
3. Para cada DVD a ser emprestado, FAÇA:
    a. Caixa informa ID do DVD;
    b. Sistema localiza DVD com ID DVD;
    c. Sistema exibe nome do DVD e valor de locação;
    d. Sistema acumula total da locação;
Fim_Para
4. Sistema apresenta total da locação;
5. Caixa confirma a locação;
6. Sistema registra locação de cada DVD, calculando a data de devolução;
7. Sistema imprime recibo com dados da locação.
Cenários alternativos:
2.a. Cliente não cadastrado
1. Sistema informa “Cliente não cadastrado";
2. Sistema  retorna ao passo 1.
 
3.b.a. DVD não cadastrado
1. Sistema informa “DVD não cadastrado";
2. Sistema  retorna ao passo 3.a.
Aula 04
Conceitos de diagrama de classes
O diagrama de classes é considerado por muitos o principal diagrama da UML, sendo também o mais amplamente usado por aqueles que usam a UML na modelagem de seus sistemas orientados a objetos.
Existem vários níveis de diagramas de classes, que são usados no nível de domínio — conceitual — e de projeto.
Nesta aula, vamos inicialmente abordar o diagrama de classes a partir da observação do mundo real para um determinado contexto. Vamos construir o diagrama em nível de domínio, ou ainda, o chamado modelo conceitual de classes.
Para começarmos , atente-se para a seguinte informação, referente ao diagrama conceitual de classes:
Não se devem representar estruturas de projeto (interfaces, chaves, arquivos, campos etc.). O foco da análise é o negócio.
Modelo conceitual de classes
Com base no que vimos, podemos conhecer o modelo conceitual de classes.
Esse modelo usa os elementos mais básicos do diagrama de classes, pois a finalidade é representar os objetos tal qual existem no mundo real, sem inserir aspectos de projeto ou de implementação no modelo.
Assim, o diagrama de classes descreve, de forma gráfica, os tipos de objetos que interagem para realizar as funcionalidades previstas em um sistema, bem como os vários tipos de relacionamentos estáticos entre eles. O diagrama de classes mostra, ainda, as propriedades e operações de uma classe e as restrições relacionadas à forma como os objetos se relacionam.
A evolução do diagrama de classes
O diagrama de classes evolui à medida que o projeto avança. Observe esse processo através do esquema a seguir:
Fase de analise
1-Inicialmente, em sua primeira versão, na fase de análise, o diagrama apresenta as classes do negócio (também chamada de entidades) e chama-se diagrama de classes conceitual.
Esse é um diagrama compatível com as funcionalidades dos casos de uso, ou seja, mostra a modelagem em classes dos requisitos essenciais do sistema.
2-Num segundo momento, ainda na fase de análise, novas classes podem ser inseridas no diagrama de classes, como as de controle e as de interface (ou fronteira).
Classe de fronteira (boundary) ou interface: responsável pela interação com os atores. Exemplo: para representar um formulário, para representar a interface com outro equipamento (um acionador de cancelas de entrada e saída de veículos, por exemplo);
Classes de controle: responsável pela coordenação da interação entre os objetos, na realização de um caso de uso. A princípio, cada caso de uso teria uma classe de controle.
Fase de projeto
Nessa fase, o mesmo diagrama de classes pode ser refinado com a inserção de:
Multiplicidades e papéis;
Relacionamento entre as classes;
Novos métodos (como, por exemplo, get, set e formatações);
Novos atributos;
Parâmetros nas chamadas dos
métodos;
Visibilidade dos atributos e métodos;
Novas classes, chamadas de classes de projeto (como representação de persistência).
FASE DE IMPLEMENTAÇÃO
Durante a implementação (codificação na linguagem), novas classes podem surgir, como classes que implementem determinada característica da linguagem de programação ou determinada forma de programar. É o diagrama de classes de implementação.
Na verdade, embora com diferentes nomenclaturas, o diagrama de classes é um só, que vai crescendo e sendo alterado a cada fase do ciclo de desenvolvimento. Algumas equipes de projeto podem optar por guardar as versões finais de cada diagrama, mas a última versão guarda todas as alterações feitas.
A classe
Vamos conhecer o conceito de classe com mais detalhe:
Uma classe é uma abstração da realidade, na qual representamos algo do mundo real. Se, por exemplo, em um contexto de sistema, identificarmos que desejamos armazenar os dados de um determinado elemento, estamos diante de uma candidata à classe do sistema.
Na UML, uma classe é representada por um compartimento contendo três partes, conforme ilustra a figura a seguir:
A figura, abaixo, ilustra um exemplo de classe de nome “cliente”, contendo os atributos Nome e Matrícula e os métodos (operações) Criar(), Destruir() e Incluir Cliente():
Classe x Objeto
CLASSE
É o molde de um conjunto de objetos afins, ou seja, com as mesmas características (atributos e métodos). 
OBJETO
É uma instância de uma classe.
Na imagem, a seguir, você pode visualizar o exemplo de um objeto específico pertencente à classe cliente. O objeto é como se fosse um elemento específico do conjunto (classe) cliente:
Ao modelarmos um sistema, estamos em busca de classes, e não de objetos. Poderíamos pensar que o nome da técnica deveria chamar-se “orientação a classes”, e não “orientação a objetos”.
Visão geral do diagrama de classes e seus elementos
A figura abaixo ilustra um diagrama conceitual de classes, contendo apenas classes de negócio (entidades) que são modeladas, bem como apresenta comentários dos principais elementos do diagrama de classes.
Figura extraída do livro UML Essencial: um breve guia para a linguagem-padrão de modelagem de objetos, de Martin Fowler, 3a edição.
Por meio do exemplo de diagrama, podemos observar que um diagrama de classes possui os seguintes elementos básicos:
1. Classes, com atributos e operações (métodos) de cada uma;
2. Relacionamentos entre as classes;
3. Multiplicidade dos relacionamentos;
4. Visibilidade de atributos e métodos;
5. Nome dos relacionamentos e papel nos relacionamentos;
6. Navegabilidade nos relacionamentos;
7. Notas e comentários.
Vamos conhecer cada elemento com mais detalhe, a seguir.
Classes com seus atributos e operações
Cada classe possui os seus atributos e operações específicos. Veja como esses elementos se relacionam:
Atributo
O conceito de atributo remete ao conjunto de características (estado) dos objetos da classe.
Ele descreve uma propriedade estrutural da classe, um dado relevante que desejamos armazenar daquela classe. Segundo a UML, forma mínima de representar um atributo é: visibilidade Nome: tipo.
Operaçoes
O conceito de método remete ao conjunto de operacões (comportamento) que a classe fornece.
A operacão de uma classe é representada por um método, que é um procedimento ou função da classe. Segundo a UML, a forma mínima de representar um método é: visibilidade Nome (Lista de parâmetros) : tipo.
Exemplos de classes com seus atributos e operações
Atributo
Conforme a figura a seguir, temos a classe disciplina e quatro atributos. Vejamos o
atributo código:
? O sinal menos (-) antes do nome é a visibilidade, que explicaremos
adiante;
? Código é o nome do atributo;
? String é o tipo do atributo.
Operações
Conforme a figura a seguir, temos a classe disciplina e quatro métodos. Vejamos o
método RECUPERARCREDITOS(Cod:int):int:
? O sinal mais (+) antes do nome é a visibilidade, que explicaremos
adiante;
? RecuperarCreditos é o nome do método;
? (Cod:int) é a lista de parâmetros, que no caso é composta de apenas um
parâmetro; em que Cod é o nome do parâmetro e int o tipo de dado do
parâmetro;
? Int é o tipo de dado que RECUPERACREDITOS retorna.
Observe que em três métodos o tipo de dados é VOID. Isto significa que esses
métodos não retornam um tipo de dados, não sendo portanto uma função, e sim
um procedimento.
Associação entre classes
O relacionamento de associação é o mais simples e comum relacionamento entre classes. Ocorre entre uma, duas ou mais classes distintas, não correlatas e independentes. Ao final do relacionamento, as classes permanecem com suas vidas próprias.
A associação entre classes pode acontecer das seguintes maneiras, veja:
AssociaçÃo BINÁRIA
É a associação mais comum, também chamada de associação entre duas classes.
AUTOASSOCIAÇÃO
Também chamada de associação unária, corresponde à associação que ocorre com a mesma classe, na qual uma classe se relaciona com ela própria.
ASSOCIAÇÃO EXCLUSIVA
É uma restrição em duas ou mais associações. Ela indica que objetos de uma determinada classe podem participar de no máximo uma das associações, em determinado momento.
Ela é representada por uma linha tracejada, entre as associações, com a especificação {ou}, denotando que o relacionamento é exclusivo a somente uma das duas classes.
Para saber mais sobre a associação entre classes, clique no botão ao lado:
Associação entre classes
O relacionamento de associação é o mais simples e comum relacionamento entre
classes. Ocorre entre uma, duas ou mais classes distintas, não correlatas e
independentes. Ao final do relacionamento, as classes permanecem com suas vidas
próprias.
A associação entre classes pode acontecer das seguintes maneiras, veja:
Associação binária
É a associação mais comum é entre duas classes, ilustrada na figura a seguir.
Observe que o relacionamento de associação e denotado por uma linha sólida, que
conecta as duas classes.
Nesse exemplo, as classes cliente e pedido se relacionam no momento em que o
cliente faz um pedido à empresa.
ASSOCIAÇÃO
Autoassociação
Também chamada de associação unária, corresponde à associação que ocorre com
a mesma classe, na qual uma classe se relaciona com ela própria, conforme ilustra 
a figura a seguir, em que o relacionamento é de pré-requisito. Uma disciplina tem
como pré-requisito outra disciplina da mesma classe.
É possível haver relacionamentos com três ou mais classes, todavia é difícil
encontrá-los no mundo real para modelagem. A figura a seguir mostra um exemplo
de relacionamento de associação entre três classes. Um cliente contrata um
projeto e um arquiteto.
Autoassociação
Associação exclusiva
Uma associação exclusiva é uma restrição em duas ou mais associações. Ela indica
que objetos de uma determinada classe podem participar de no máximo uma das
associações, em determinado momento.
É representada uma linha tracejada, entre as associações, com a especificação
{ou}, demotando que o relacionamento é exclusivo a somente uma das duas
classes.
A figura a seguir mostra que um contrato somente pode ser entre pessoas ou entre
empresas, mas não pode haver contrato no qual figure empresa e pessoa
simultaneamente:
Multiplicidade nos relacionamentos
A multiplicidade é um conceito extremamente relevante nos relacionamentos. De uma forma bem simples, ela indica quantos objetos de cada classe podem estar envolvidos no relacionamento.
Para visualizar um exemplo sobre a multiplicidade nos relacionamentos, clique no botão a seguir:
Exemplo de multiplicidade nos relacionamentos
Imagine um relacionamento entre cliente e pedido, no qual um cliente faz um
pedido. Vamos analisar a multiplicidade de cada um dos dois lados do
relacionamento: do lado da classe cliente e do lado da classe pedido.
? Do lado da classe cliente, temos: o cliente pode realizar nenhum ou
vários pedidos. Observe que escrevemos essa multiplicidade do lado