- França.pro.br

Transcrição

- França.pro.br

FUNDAÇÃO DE APOIO À ESCOLA TÉCNICA
DO
ESTADO DO RIO DE JANEIRO - FAETEC
Nome da Disciplina
Período
Carga Horária
MODELAGEM DE DADOS 3 – MD3
2º
2 aulas/semana
Notas de Aula – v1.0
Fevereiro de 2012
Professor M. França
[email protected]
http://www.franca.pro.br/prof
FAETEC 2012 - Notas de Aula de MD3 – Prof. M. França – Página: 1
Esta página foi deixada propositadamente em branco.
O Autor
Marcelo França é técnico em Processamento de Dados, tecnólogo em Processamento de Dados,
analista de sistemas pós-graduado pela PUC-Rio, bacharel em Administração de Sistemas de Informação,
licenciado em Informática pelo Instituto Superior de Educação do Rio de Janeiro – ISERJ,
mestre em Informática pela Universidade Federal do Estado do Rio de Janeiro – UNIRIO,
aluno do MBA em gerenciamento de projetos da Fundação Getúlio Vargas,
certificado MCAD pela Microsoft, certificado SCJA pela Sun,
certificado RAD Associate pela IBM, certificado OCJP 6 (SCJP) pela Oracle,
professor de Informática da FAETEC e da Faculdade de Informática Lemos de Castro,
e especialista de sistemas da IBM Brasil.
Estuda Informática desde 1990 e trabalha com Informática desde 1994.
Dedicatória
Dedico este trabalho a todos os meus alunos e ex-alunos.
Desejo a todos vocês muito sucesso profissional.
Que seus objetivos sejam alcançados e que vocês sempre perseverem, mantendo o foco!
Agradecimentos
Agradeço a Deus pela iluminação e por ter sido tão feliz na escolha desta profissão.
Obrigado, Senhor!
Índice
1.
Introdução ao Paradigma OO ..................................................................................... 7
Motivação.................................................................................................................... 7
Técnicas de Programação Tradicionais ............................................................................ 9
Histórico da Orientação a Objetos................................................................................. 10
Princípios Básicos ....................................................................................................... 13
Introdução à UML ....................................................................................................... 19
Exercícios .................................................................................................................. 20
2.
Diagrama de Casos de Uso ...................................................................................... 23
Introdução ................................................................................................................ 23
O que são atores, cenários e casos de uso? ................................................................... 25
Como identificar atores e casos de uso? ........................................................................ 28
Aplicação de UML: diagramas de casos de uso ............................................................... 37
Relacionamentos entre Casos de Uso ............................................................................ 38
Sugestões de ferramentas de Modelagem: .................................................................... 41
Exercícios .................................................................................................................. 42
3.
Diagrama de Classes ............................................................................................... 45
Diagrama de Classes .................................................................................................. 45
Associações ............................................................................................................... 47
Agregação e Composição ............................................................................................ 49
Generalizações........................................................................................................... 50
Dependências e Refinamentos ..................................................................................... 51
Exercícios .................................................................................................................. 52
4.
Diagrama de Atividades e de Sequência .................................................................... 53
Diagrama de Atividades .............................................................................................. 53
Diagramas de Sequência ............................................................................................. 60
Exercícios .................................................................................................................. 70
6.
Apêndice A – Questionário de Avaliação do Curso ....................................................... 77
1. Introdução ao Paradigma OO
Motivação
Crise do Software
A crise do software foi um termo utilizado nos anos 70, quando a engenharia de software era
praticamente inexistente. O termo expressava as dificuldades do desenvolvimento de software frente
ao rápido crescimento da demanda por software, da complexidade dos problemas a serem resolvidos e
da inexistência de técnicas estabelecidas para o desenvolvimento de sistemas que funcionassem
adequadamente ou pudessem ser validados.
A noção da crise do software emergiu no final dos anos 60. Uma das primeiras e mais
conhecidas referências ao termo foi feita por Edsger Dijkstra, na apresentação feita em 1972 na
Association for Computing Machinery Turing Award, intitulada "The Humble Programmer" (EWD340),
publicada no periódico Communications of the ACM.
Logo que o desenvolvimento de software começou a caminhar com o advento das linguagens
estruturadas e modulares, uma situação tornou-se clara diante de todos: a indústria de software
estava falhando repetidamente na entrega de resultados dentro dos prazos, quase sempre estourando
os orçamentos e apresentando um grau de qualidade duvidoso ou insatisfatório.
Em um relatório de 1969 [Naur, 1969], esse problema já havia sido reconhecido. Conforme foi
observado, cerca de 50 a 80% dos projetos nunca foram concluídos ou estavam tão longe de seus
objetivos que foram considerados fracassados. Dos sistemas que foram finalizados, 90% haviam
terminado 150 a 400% acima do orçamento e dos prazos predeterminados [Wallnau, 2002].
Os problemas que originaram essa crise tinham relacionamento direto com a forma de trabalho
das equipes. Eram problemas que não se limitavam a "sistemas que não funcionam corretamente",
mas envolviam também dúvidas sobre como desenvolver e manter um volume crescente de software e
ainda estar preparado para as futuras demandas. Essencialmente, eram sintomas provenientes do
pouco entendimento dos requisitos por parte dos desenvolvedores, somados às técnicas e medidas
pobres aplicadas sobre o processo e o produto, além dos poucos critérios de qualidade estabelecidos
até então [Pressman, 2004].
A palavra “crise” já tem sido discutida por não descrever exatamente o problema em questão.
Uma definição mais precisa talvez seja “aflição crônica”, pelas características de continuidade e
intermitência dos sintomas [Pressman, 2004].
Todos esses fatores
exigiram
respostas e
métodos que foram
sendo aprimorados
e
documentados, dando início à área de Engenharia de Software. A busca por eficiência e competência
revelou oportunidades, desafios e perigos que guiaram as tecnologias e apontaram novos rumos para
as pesquisas.
A Crise do Software e a Idade Média
Para compreender melhor as origens da Crise de Software, podemos fazer uma comparação
muito interessante com a história das outras indústrias. Por exemplo, antes da revolução industrial, os
sapatos eram feitos de forma muito individual. Nesses tempos mais remotos, os sapateiros faziam cada
par de sapatos de forma única para cada cliente, desde a obtenção da matéria prima até o produto
final.
As semelhanças com a indústria de software começam logo aí. Primeiro, porque as técnicas de
desenvolvimento de software ainda não estão totalmente maduras e consolidadas. Afinal, a variedade
de técnicas que surgiram nas últimas décadas é enorme.
Em segundo lugar, existe uma tendência muito forte em desenvolver software sem aproveitar o
material produzido no passado. E para piorar, além de entregá-lo quase sempre mal documentado, a
maior parte do conhecimento envolvido na sua construção permanece apenas na cabeça dos
desenvolvedores, o que deixa a situação muito parecida com a do sapateiro do exemplo.
Causas da Crise do Software
As causas da crise do software estão ligadas a complexidade do processo de software e a
relativa imaturidade da engenharia de software como profissão:
As estimativas de prazo e de custo frequentemente são imprecisas;
Não dedicamos tempo para coletar dados sobre o processo de desenvolvimento de software;
Com poucos dados históricos como guia, as estimativas tem sido “a olho”, com resultados
notadamente ruins;
A produtividade das pessoas da área de software não tem acompanhado a demanda por
seus serviços;
Os projetos de desenvolvimento de software normalmente são efetuados apenas com um
vago indício das exigências do cliente;
A qualidade de software às vezes é menos que adequada e só recentemente começam a
surgir conceitos quantitativos sólidos de garantia de qualidade de software;
O software existente é muito difícil de manter e a tarefa de manutenção devora o orçamento
destinado ao software; e a facilidade de manutenção não foi enfatizada como um critério
importante.
A crise se manifesta de varias formas:
•
Projetos estourando o orçamento;
•
Projetos estourando o prazo;
•
Software de baixa qualidade;
•
Software muitas vezes não atinge os requisitos;
•
Projetos não gerenciáveis (escopo e prazo estourados) e o código difícil de manter.
A maior parte dos projetos, hoje, continua com estes problemas. Assim, pode se dizer que a
crise continua vigente ainda na atualidade.
As possíveis soluções para a crise de software:
•
O uso de melhores técnicas, métodos e ferramentas;
•
Mais treinamento e educação: Atualmente não se investe o suficiente;
•
A mudança de paradigma sobre o que é desenvolver software e como deveria ser feito.
Técnicas de Programação Tradicionais
Introdução
As técnicas de programação tradicionais, como por exemplo a “decomposição funcional”, leva o
desenvolvedor a decompor o sistema em partes menores (funções), criando um emaranhado de
inúmeras funções que chamam umas às outras.
Geralmente não há separação de conceitos e responsabilidades, causando dependências
enormes no sistema, dificultando futuras manutenções no código do programa.
Não existe muito reaproveitamento de código, ao contrário, muitas vezes se tem muito código
duplicado (mesmo trabalhando-se com “tecnologia OO”).
Programação Orientada a Eventos
Uma linguagem pode ser OO e não ser OE (Pascal), bem como pode ser OE (Visual Basic 6,
Javascript) e não suportar totalmente a OO. Outras linguagens (Visual Basic.NET, Java, Delphi) podem
ser tanto orientadas a objetos como orientadas a eventos. Uma boa IDE (Integrated Development
Environment) pode facilitar muito a programação orientada a eventos – Microsoft Visual Studio, por
exemplo.
É bom salientar que o fato de uma linguagem ser considerada OO, não implica em que a mesma
não seja (também) uma linguagem estruturada – suportando as instruções básicas de “seqüência,
repetição e seleção”.
Em suma, a programação orientada a eventos, somada a componentização (ferramentas
baseadas
em
componentes
como
text
box,
combo,
button,
form,
etc.,
que
agilizavam
o
desenvolvimento de interfaces), tornou a programação para Windows uma tarefa relativamente fácil. A
geração anterior de programadores trabalhava com linguagens como o Clipper, essencialmente
orientadas ao console/texto. Com o advento do Windows, surgiu um novo padrão de interface com o
usuário. E a componentização (Delphi e Visual Basic 5) e o conceito do RAD (Rapid Application
Development) proporcionaram que aplicações inteiras fossem escritas em um tempo bastante
reduzido, em comparação com a geração anterior.
Nota: Rapid application development (RAD) is a software development methodology that uses
minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is
interleaved with writing the software itself. The lack of extensive pre-planning generally allows software
to be written much faster, and makes it easier to change requirements.
Histórico da Orientação a Objetos
Origens
A Programação Orientada ao Objeto (Object-Oriented Programming) pode ser considerada como
uma extensão quase natural da Programação Modular; entretanto a sigla OOP tem causado um certo
"frisson" na comunidade de computação, nos últimos anos.
Na verdade, isto não deveria acontecer, uma vez que a OOP foi concebida há muito tempo atrás
(no inicio da década de 70). A sua origem vem da linguagem Simula (Simula Language), concebida na
Noruega no início da década de 60, e como o nome indica, foi criada para fazer simulações. Entretanto,
seu uso alavancou um conceito que até então passava "despercebido" pela maioria dos projetistas: a
similaridade com o mundo real.
A primeira linguagem de programação a implementar sistematicamente os conceitos de OOP foi
a linguagem SIMULA-68; em seguida surgiu a linguagem Smalltalk -criada pela Xerox -, que pode ser
considerada a linguagem que popularizou e incentivou o emprego da OOP. Atualmente podemos
encontrar versões de Smalltalk para microcomputadores, o que facilitou enormemente o seu uso,
tirando-a dos ambientes privativos das Universidades. O resultado foi uma linguagem de pura linhagem
OO, poderosíssima, que implementa todos os conceitos de OO, o que não acontece com as chamadas
linguagens OO híbridas que implementam apenas alguns conceitos de orientação ao objeto.
Com o aparecimento da famosa "crise do software", o emprego da OOP foi a saída
protagonizada pelos desenvolvedores para minimizar os custos dos sistemas, em particular os custos
relativos às manutenções corretivas, uma vez que cerca de 75% dos custos dos programas referem-se
ao indesejável expediente de alterar e/ou remendar códigos dos sistemas já implantados e em
operação. É notório que um dos grandes benefícios da OO é a reutilização (reuso de código/classes),
além do que, um bom projeto OO resulta em classes com alta coesão e baixo acoplamento – o que
facilita a manutenção.
Basicamente, a OOP utiliza os mesmos princípios da engenharia de hardware que projeta novos
equipamentos usando os mesmos componentes básicos como transistores, resistores, fusíveis, diodos,
chips, etc. Os "objetos" já existentes são utilizados para produzir novos "objetos", tornando essa
metodologia mais poderosa que as metodologias tradicionais de desenvolvimento de sistemas.
Se consideramos a Orientação ao Objeto como um novo paradigma de desenho de software,
devemos considerar, também, uma nova maneira de pensar, porque apesar de a escrita do código
continuar sendo procedural, alguns conceitos mudam radicalmente: a estruturação e o modelo
computacional. Fundamentalmente o que se deseja com esta metodologia são basicamente duas
características: reutilização de código e modularidade de escrita; e nisto a OOP é imbatível quando
comparada com as metodologias antigas.
Em termos de modelo computacional podemos dizer que enquanto as metodologias tradicionais
utilizam o conceito de um processador, uma memória e dispositivos de I/O para processar, armazenar
e exibir as informações, a OOP emprega um conceito mais real, mais concreto, que é o de Objeto.
O que é Orientação a Objetos?
É um paradigma para o desenvolvimento de software que baseia-se na utilização de
componentes individuais (objetos) que colaboram para construir sistemas mais complexos. A
colaboração entre os objetos é feita através do envio de mensagens.
Um paradigma é um conjunto de regras que estabelecem fronteiras e descrevem como resolver
problemas dentro desta fronteira. Um paradigma ajuda-nos a organizar a e coordenar a maneira como
olhamos o mundo.
Dentre as vantagens podemos citar:
•
Facilita a reutilização de código;
•
Os modelos refletem o mundo real de maneira mais aproximada: Descrevem de maneira
mais precisa os dados; A decomposição é baseada em um particionamento natural; e são
mais fáceis de entender e manter;
•
Pequenas mudanças nos requisitos não implicam em alterações massivas no sistema em
desenvolvimento;
•
Implementação de tipos abstratos de dados (tipos que não serão implementados, mas
que servem ao projeto, pensando-se em “herança”).
Classes e Objetos
A OO é um mecanismo moderno que ajuda a definir a estrutura de programas baseada nos
conceitos
do
mundo
real,
sejam
eles
reais
ou
abstratos.
A
OO
permite
criar
programas
componentizados, separando as partes do sistema por responsabilidades e fazendo com que essas
partes se comuniquem entre si, por meio de mensagens. Essas partes do sistemas são chamadas
OBJETOS – criados a partir de CLASSES.
Uma classe é a descrição de um grupo de objetos com propriedades similares (atributos),
comportamento comum (operações), relacionamentos com outros objetos e semânticas idênticas. Todo
objeto é instância de uma classe.
Enquanto um objeto individual é uma entidade concreta que executa algum papel no sistema,
uma classe captura a estrutura e comportamento comum a todos os objetos que estão relacionados.
Uma classe define a estrutura e o comportamento de qualquer objeto da classe, atuando como um
padrão para a construção de objetos. Objetos podem ser agrupados em classes.
A definição da classe consiste na definição dos atributos e operações dos objetos desta classe;
Um atributo é uma característica de uma classe. Atributos não apresentam comportamento, eles
definem a estrutura da classe; Operações caracterizam o comportamento de um objeto, e são o único
meio de acessar, manipular e modificar os atributos de um objeto.
Figura 1: relação entre classe e objeto
Exemplo: Programação Estruturada vs. OO
Vamos considerar o mesmo problema sendo resolvido, usando-se pseudo-código, primeiro na
programação estruturada, e depois na programação orientada a objetos.
Ler 2 números e exibir sua soma (Como?):
PROGRAMA SOMA
VARIÁVEIS
N1, N2: REAL
INÍCIO
LOC = 8
ESCREVA “ENTRE COM DOIS NÚMEROS:”
LEIA N1, N2
ESCREVA “A SOMA É:”, N1+N2
FIM
Note que a ênfase neste caso está nas operações que devem ser desempenhadas para a solução
do problema. Neste caso a solução fica muito presa ao problema, sendo mais difícil podermos
aproveitar este código num outro cenário. Alguns poderiam afirmar que este código poderia ser
utilizado através do “famoso” Copy & Paste. Porém, esta “técnica” não deve ser considerada quando
falamos de reuso, pois pode levar à situações de redundância (o que dificulta e encarece a manutenção
do código), bem como a situações de inconsistência (no caso de uma alteração ser necessária mas nem
todas as ocorrências do código foram atualizadas, logo, o código terá cópias atualizadas e outras não –
Find & Replace). Por fim, note que foram necessárias apenas 8 linhas de código para a solução no
paradigma estruturado (seqüência, seleção e repetição).
Ler 2 números e exibir sua soma (Com o quê?):
CLASSE CALCULADORA
ATRIBUTOS
N1, N2: REAL
MÉTODOS
INFORMAR_N1(N: REAL)
N1 N
FIM-INFORMAR_N1
INFORMAR_N2(N: REAL)
N2 N
FIM-INFORMAR_N2
RETORNAR_SOMA(): REAL
RETORNO (N1+N2)
FIM-RETORNAR_SOMA
FIM-CLASSE
LOC = 27
PROGRAMA SOMA
VARIÁVEIS
C: CALCULADORA
N: REAL
INÍCIO
C NOVO CALCULADORA
ESCREVA “ENTRE COM DOIS NÚMEROS:”
LEIA N
C.INFORMAR_N1(N)
LEIA N
C.INFORMAR_N2(N)
ESCREVA “A SOMA É:”, C.RETORNAR_SOMA()
FIM
Princípios Básicos
Abstração
Informalmente um objeto representa uma entidade, tanto física quanto conceitual ou de
software. Exemplos:
•
Entidade Física: caminhão, carro, bicicleta, etc.
•
Entidade Conceitual: processo químico, matrícula, etc
•
Entidade de Software: lista encadeada, arquivo, etc.
Podemos afirmar que um objeto é um conceito, abstração, ou entidade com limites bem
definidos e um significado para a aplicação. Quando modelamos um objeto (classe), só consideramos o
que for relevante. O “time de futebol do coração” pode não ser um atributo relevante para um sistema
de informação escolar, por exemplo.
Abstração é considerada como a habilidade de modelar características do mundo real do
problema que o programador esteja tentando resolver. Por exemplo, se o programador estiver
interessado em controlar dados dos clientes de uma empresa, é muito mais fácil lidar com uma
linguagem que ofereça recursos em que ele possa criar algo chamado "Cliente" ao invés de recorrer à
estruturas de dados tipo array ou record.
Nesse contexto a abstração refere-se à capacidade de modelar o mundo real, e por outro lado,
podemos considerá-la como um mecanismo pelo qual restringimos o nosso universo de análise e as
variáveis e constantes que compõem esse universo, desprezando os dados que não nos interessa na
análise.
Podemos demonstrar o uso de abstração facilmente, quando fechamos os olhos e pensamos em
uma mesa; esta mesa imaginária provavelmente não vai ser igual à uma outra imaginada por outras
pessoas, mas o que importa é que todos as pessoas que imaginaram uma mesa, colocaram nessa as
informações que para elas são necessárias para a sua função (de ser uma mesa). Não importa se a
mesa é de três pés ou quatro, ou se o tampão é de vidro, madeira ou mármore; o que importa é que a
imagem que idealizamos em nossa cabeça é de uma mesa e tenha as informações necessárias para
cumprir sua função.
Encapsulamento
Information Hiding: segurança, simplicidade, coesão.
“Esconder” os detalhes da implementação de um objeto é chamado encapsulamento. A
capacidade de um objeto possuir uma parte privada, acessível somente através dos métodos definidos
na sua interface pública; Não se deve permitir acesso direto aos atributos de uma classe;
Benefícios: O código cliente pode usar apenas a interface para a operação; A implementação do
objeto pode mudar, para corrigir erros, aumentar performance, etc. sem que seja necessário modificar
o código do cliente; A manutenção é mais fácil e menos custosa; e cria um programa legível e bem
estruturado. Na prática, tendemos a diminuir o acoplamento, a dependência externa (de outras
classes).
Normalmente, para respeitarmos o princípio do encapsulamento, todos os atributos de uma
classe devem ser “private” ou, no máximo, “protected”.
Observação: A linguagem Java não “respeita” totalmente o conceito do encapsulamento posto
que o escopo “protected” em Java permite que outras classes, que não filhas, consigam acessar o item
(atributo ou método), apenas por fazer parte do mesmo pacote.
Encapsulamento é a base de toda a abordagem da Programação Orientada ao Objeto; isto
porque contribui fundamentalmente para diminuir os malefícios causados pela interferência externa
sobre os dados. Partindo desse princípio, toda e qualquer transação feita com esses dados só pode ser
feita através de procedimentos colocados "dentro" desse objeto, pelo envio de mensagens. Desta
maneira, dizemos que um dado está encapsulado quando envolvido por código de forma que só é
visível na rotina onde foi criado; o mesmo acontece com uma rotina, que sendo encapsulada, suas
operações internas são invisíveis às outras rotinas. E até mesmo em linguagens consideradas não OO,
como no caso do Clipper 5.xx, segundo FERREIRA & JARABECK, pode-se observar um certo
encapsulamento nas rotinas em que as variáveis são declaradas como LOCAL. Nesses casos tais
variáveis são visíveis somente dentro dessas rotinas aonde foram declaradas, o que permite ao
programador certa segurança quanto aos acessos indevidos por parte de outras rotinas, o que não
acontece com variáveis PRIVATE ou PUBLIC, no contexto dessa linguagem.
Podemos visualizar a utilidade do encapsulamento pensando em um dvd, onde temos os botões
de liga-desliga, para frente, para traz, etc. Estes botões executam uma série de operações existentes
no aparelho, onde são executadas pelos componentes existentes dentro do aparelho (transistores,
cabos, motores, etc.) Não interessa ao operador saber como é o funcionamento interno do
equipamento; esta informação só é relevante para os projetistas do aparelho (Encapsulamento =
Simplicidade). As informações pertinentes ao usuário do equipamento são as existentes no meio
externo (botões, controle remoto) que ativam as operações internas do equipamento. Desta maneira o
aparelho de dvd pode evoluir com os avanços tecnológicos, e as pessoas que o utilizam continuam
sabendo utilizar o equipamento, sem a necessidade de um novo treinamento.
Na área de software acontece o mesmo: as classes podem continuar evoluindo, com aumento
de tecnologia, e os programas que utilizam essas classe continuam compatíveis. Isto ocorre porque a
esses programas não interessa saber como é o funcionamento interno da classe e sim sua função, para
que ele possa executar, conforme ela evolui, novas funções colocadas à sua disposição. A única coisa
que interessa aos “consumidores” é a API da classe (operações públicas).
Herança
Herança é um mecanismo que, se for bem empregado, permite altos graus de reutilização de
código. Do ponto de vista prático, pode ser entendido como sendo um conjunto de instâncias criadas a
partir de um outro conjunto de instâncias com características semelhantes, e os elementos desse
subconjunto herdam todas as características (se aplica a atributos e métodos.) do conjunto original.
A ideia é fornecer um mecanismo simples (mas muito poderoso) para que se defina novas
classes a partir de uma já existente. Assim sendo, dizemos que essas novas classes herdam todos os
membros (propriedades + métodos) da classe-mãe (ou super classe); isto torna o mecanismo de
herança uma técnica muito eficiente para construir, organizar e reutilizar código. Por isso, nas
linguagens que não suportam esse mecanismo, as classes são criadas como unidades independentes:
cada uma com seus membros concebidos do zero (sem vínculo direto com outras classes), o que torna
o processo mais demorado e com códigos, às vezes, redundantes.
Um exemplo de linguagem que não implementa herança na sua forma clássica é o Visual Basic®
(até a atual versão desktop 6.0); neste caso o desenvolvedor tem que simular esse mecanismo,
usando a “criatividade”. A herança possibilita a criação de uma nova classe de modo que essa classe
(denominada subclasse, classe-filha ou classe derivada) herda TODAS as características da classe-mãe
(denominada superclasse, classe base ou classe primitiva); podendo ainda, a classe-filha, possuir
propriedades e métodos próprios.
No processo de herança podemos imaginar um ser humano, que nasce com todas as
características de um ser humano sadio; agora, coloquemos nele uma roupa e um relógio. A roupa e o
relógio não faz parte do ser humano, mas quando "pegamos" este ser, vestido e com um relógio, e
realizamos o processo de herança é gerada uma copia idêntica da matriz. Se colocarmos um sapato
preto no ser humano original a sua copia também ficará calçada, e se trocarmos a camisa do ser
humano original a sua cópia também vai receber a nova camisa; isto demonstra que a copia continua
vinculada à matriz de origem. Podemos tirar quantas cópias que desejarmos da matriz original e todas
estas cópias manterão o seu vínculo. Podemos, até, tirar cópias das cópias, mas o processo de
modificarmos a matriz original implicará numa mudança em todas as outras que estão abaixo dela.
Nunca uma modificação feita nas copias altera a matriz de origem, e nunca podemos remover um item
que tenha sido recebido por intermédio da herança, isto que dizer que nenhuma das cópias (humanas)
poderá se dar ao luxo de não ter o relógio.
Polimorfismo
O termo polimorfismo, etimologicamente, quer dizer "várias formas"; todavia, na Informática, e
em particular no universo da OOP, é definido como sendo um código que possui "vários
comportamentos" ou que produz "vários comportamentos"; em outras palavras, é um código que pode
ser aplicado à várias classes de objetos (se aplica a métodos). De maneira prática isto quer dizer que a
operação em questão mantém seu comportamento transparente para quaisquer tipos de argumentos;
isto é, a mesma mensagem é enviada a objetos de classes distintas e eles poderão reagir de maneiras
diferentes.
Um método polimórfico é aquele que pode ser aplicado à várias classes de objetos sem que haja
qualquer inconveniente. É o caso por exemplo, do método Clear em Delphi®, que pode ser aplicado
tanto à classe TEdit como à classe TListBox; nas duas situações o conteúdo desse objetos são limpos,
mesmo pertencendo, ambos, à classes distintas, LEITE.
Segundo FERREIRA & JARABECK, um exemplo bem didático para o polimorfismo é dado por um
simples moedor de carne. Esse equipamento tem a função de moer carne, produzindo carne moída
para fazer bolinhos. Desse modo, não importa o tipo (classe) de carne alimentada; o resultado será
sempre carne moída, não importa se de boi, de frango ou de qualquer outro tipo. As restrições
impostas pelo processo estão no próprio objeto, definidas pelo seu fabricante e não pelo usuário do
produto.
É comum a definição de que, para haver polimorfismo, é preciso primeiro haver herança.
Polimorfismo se refere a métodos, e nunca a atributos. Um método herdado pode ser sobrescrito na
classe-filha, ou seja, apresentará um comportamento diferente do comportamento original da classemãe. É importante salientar que existe o chamado “Polimorfismo de Interface”, onde classes diferentes
(de hierarquias diferentes) implementam um mesmo conjunto de métodos, cada qual à sua maneira.
Classicamente isto não deve ser considerado polimorfismo posto que não existe herança, nem ligação
hierárquica neste caso.
Binding Dinâmico
O acoplamento (binding) é uma associação feita pelo compilador (interpretador) entre um
atributo e uma entidade. Exemplo: acoplamento entre tipos e variáveis. O acoplamento pode ser:
•
Estático: se ocorre antes do tempo de execução e permanece inalterado durante a
execução do programa. Exemplo: quando você declara em Pascal que uma variável é do
tipo integer;
•
Dinâmico ou Atrasado: se ocorre durante o tempo de execução ou muda durante a
execução do programa. Normalmente associado à linguagens orientadas a objetos;
Exemplo (Java):
1 Elipse e;
2 Circulo c;
3 e := c;
4 e.calcularArea( );
A atribuição da linha 3 é dinamicamente acoplada, pois acopla o objeto e a um tipo diferente de
seu tipo originalmente declarado. Em princípio, seria uma violação atribuir um objeto de um tipo
diferente do tipo da variável e, no entanto, como c (Circulo) é subclasse de e (Elipse) essa atribuição é
válida.
Qual o método executado? O de Círculo ou de Elipse? Note que executamos o método da
instância e não da referência. A operação executada é a de Circulo, porque o compilador em tempo de
execução verifica que a variável aponta para um objeto desta classe.
Em algumas linguagens o programador deve pedir explicitamente o acoplamento dinâmico para
uma mensagem em particular. Por exemplo, em C++ a operação deve ser declarada virtual na
superclasse e redefinida na subclasse.
Importante:
Todas
as
operações
sobrescritas
na
classe
derivada
devem
proporcionar
semanticamente os mesmos serviços oferecidos pela superclasse.
Classes Abstratas
Uma classe abstrata é uma classe que não tem instâncias diretas. Uma classe concreta é uma
classe que pode ter instâncias. Em outras palavras se X é uma classe abstrata o código a seguir não
pode ser executado:
X objeto = new X();
Apesar disso, você pode criar construtores de uma classe abstrata para que eles sejam
chamados pelos construtores das subclasses (Reutilização).
Em Java utiliza-se a palavra “abstract” para indicar uma classe abstrata:
public abstract class Figure { ....
O objetivo de criarmos classes abstratas é encapsular outras classes com comportamento
comum. Elas podem surgir naturalmente na modelagem ou serem criadas para promover o reuso.
Além disso, uma classe abstrata pode definir um protocolo para uma operação sem definir a
implementação do método.
public abstract class Figure { // inicio da class Figure
public abstract double area();
public abstract double perimetro();
}// fim da class Figure
Assim, você pode declarar métodos abstratos em uma classe abstrata apenas para especificar
um protocolo comum de operações. Toda subclasse concreta da classe abstrata deve fornecer uma
implementação para TODOS os métodos abstratos:
class Circle extends Figure {
protected double raio;
public Circle(double r) { raio = r;}
public double area() { return PI*raio*raio;}
public double perimetro() { return 2*PI*raio;}
}
Se uma subclasse de uma classe abstrata não implementa todos os métodos abstratos então ela
também é abstrata; e Uma classe abstrata também pode ter métodos concretos. Frequentemente, faz
sentido mover o máximo de funcionalidade possível para uma superclasse, seja ela abstrata ou não.
Interfaces
Interface é um contrato entre a classe e o mundo externo. Quando uma classe implementa uma
interface, ela está comprometida a fornecer o comportamento publicado pela interface.
What Is an Interface?
As you've already learned, objects define their interaction with the outside world through the
methods that they expose. Methods form the object's interface with the outside world; the buttons on
the front of your television set, for example, are the interface between you and the electrical wiring on
the other side of its plastic casing. You press the "power" button to turn the television on and off.
In its most common form, an interface is a group of related methods with empty bodies. A
bicycle's behavior, if specified as an interface, might appear as follows:
interface Bicycle {
void changeCadence(int newValue);
// wheel revolutions per minute
void changeGear(int newValue);
void speedUp(int increment);
void applyBrakes(int decrement);
}
To implement this interface, the name of your class would change (to a particular brand of
bicycle, for example, such as ACMEBicycle), and you'd use the implements keyword in the class
declaration:
class ACMEBicycle implements Bicycle {
// remainder of this class implemented as before
}
Implementing an interface allows a class to become more formal about the behavior it promises
to provide. Interfaces form a contract between the class and the outside world, and this contract is
enforced at build time by the compiler. If your class claims to implement an interface, all methods
defined by that interface must appear in its source code before the class will successfully compile.
Note: To actually compile the ACMEBicycle class, you'll need to add the public keyword to the
beginning of the implemented interface methods.
A API (Application Program Interface) pública de uma classe, ou a “interface” de uma classe é o
conjunto de todos os métodos públicos da classe.
Introdução à UML
Motivação
O grande problema do desenvolvimento de novos sistemas utilizando a orientação a objetos nas
fases de análise de requisitos, análise de sistemas e design é que não existe (ou existia) uma notação
padronizada e realmente eficaz que abranja qualquer tipo de aplicação que se deseje. Cada simbologia
existente possui seus próprios conceitos, gráficos e terminologias, resultando numa grande confusão,
especialmente para aqueles que querem utilizar a orientação a objetos não só sabendo para que lado
aponta a seta de um relacionamento, mas sabendo criar modelos de qualidade para ajudá-los a
construir e manter sistemas cada vez mais eficazes.
Quando a "Unified Modeling Language" (UML) foi lançada, muitos desenvolvedores da área da
orientação a objetos ficaram entusiasmados já que essa padronização proposta pela UML era o tipo de
força que eles sempre esperaram.
A UML é muito mais que a padronização de uma notação. É também o desenvolvimento de
novos conceitos não normalmente usados. Por isso e muitas outras razões, o bom entendimento da
UML não é apenas aprender a simbologia e o seu significado, mas também significa aprender a modelar
orientado a objetos no estado da arte.
UML foi desenvolvida por Grady Booch, James Rumbaugh, e Ivar Jacobson que são conhecidos
como "os três amigos". Eles possuem um extenso conhecimento na área de modelagem orientado a
objetos já que as três mais conceituadas metodologias de modelagem orientada a objetos foram
desenvolvidas por eles, e a UML é a junção do que havia de melhor nestas três metodologias
adicionado novos conceitos e visões da linguagem.
Veremos como a UML aborda o caráter estático e dinâmico do sistema a ser analisado levando
em consideração, já no período de modelagem, todas as futuras características do sistema em relação
à utilização de "packages" próprios da linguagem a ser utilizada, utilização do banco de dados bem
como as diversas especificações do sistema a ser desenvolvido de acordo com as métricas finais do
sistema.
A
versão
atual
da
(especificação)
UML
pode
ser
conferida
no
site
http://www.omg.org/spec/UML/. No momento da preparação desta apostila, a versão corrente era a
2.4.1 de agosto de 2011.
The Unified Modeling Language™ - UML - is OMG's most-used specification, and the way the
world models not only application structure, behavior, and architecture, but also business process and
data structure.
UML, along with the Meta Object Facility (MOF™), also provides a key foundation for OMG's
Model-Driven Architecture®, which unifies every step of development and integration from business
modeling, through architectural and application modeling, to development, deployment, maintenance,
and evolution.
OMG is a not-for-profit computer industry specifications consortium; our members define and
maintain the UML specification which we publish in the series of documents linked on this page for your
free download. Software providers of every kind build tools that conform to these specifications. To
model in UML, you'll have to obtain a compliant modeling tool from one of these providers and learn
how to use it.
Exercícios
Responda
Baseado no texto o que seria necessário aplicar para evitar a Crise do Software?
Em sua opinião, estamos ainda em uma Crise de Software? Comente sua resposta.
Em sua opinião, a comparação entre a fabricação de sapatos e de software procede?
Comente sua resposta.
Qual o objetivo da Engenharia de Software?
Segundo a Engenharia de Software, o que é um software de baixa qualidade?
O fato de o Software ser feito sob encomenda é um complicador? Torna a construção, de
certa forma, artesanal? Comente sua resposta.
Em sua opinião, existem outras possíveis soluções para a crise de software além das
descritas neste artigo?
Exercício de Modelagem
O exercício (modelo de funcionários) a seguir tem por objetivo criar um sistema para gerenciar
os funcionários do Banco.
1) Modele um funcionário. Ele deve ter o nome do funcionário, o departamento onde trabalha,
seu salário (double), a data de entrada no banco (String), seu RG (String) e um valor booleano que
indique se o funcionário ainda está ativo na empresa ou se já foi mandado embora.
Você deve criar alguns métodos de acordo com sua necessidade. Além deles, crie um método
bonifica que aumenta o salário do funcionário de acordo com o parâmetro passado como argumento.
Crie, também, um método demite, que não recebe parâmetro algum, só modifica o valor booleano
indicando que o funcionário não trabalha mais aqui.
A ideia aqui é apenas modelar, isto é, só identifique que informações são importantes e o que
um funcionário faz. Desenhe no papel tudo o que um Funcionario tem e tudo que ele faz.
2) Transforme o modelo acima em uma classe Java. Teste-a, usando uma outra classe que
tenha o main. Você deve criar a classe do funcionário chamada Funcionario, e a classe de teste você
pode nomear como quiser. A de teste deve possuir o método main.
Um esboço da classe:
class Funcionario {
double salario;
// seus outros atributos e métodos
void bonifica(double aumento) {
// o que fazer aqui dentro?
}
void demite() {
// o que fazer aqui dentro?
}
Figura
2:
classe
Funcionario
}
Você pode (e deve) compilar seu arquivo java sem que você ainda tenha terminado sua classe
Funcionario. Isso evitará que você receba dezenas de erros de compilação de uma vez só. Crie a classe
Funcionario, coloque seus atributos e, antes de colocar qualquer método, compile o arquivo java.
Funcionario.class será gerado, não podemos “executá-la” pois não há um main, mas assim verificamos
que nossa classe Funcionario já está tomando forma.
Esse é um processo incremental. Procure desenvolver assim seus exercícios, para não descobrir
só no fim do caminho que algo estava muito errado. Um esboço da classe que possui o main:
1 class TestaFuncionario {
2
3 public static void main(String[] args) {
4 Funcionario f1 = new Funcionario();
5
6 f1.nome = "Fiodor";
7 f1.salario = 100;
8 f1.bonifica(50);
9
10 System.out.println("salario atual:" + f1.salario);
11
12 }
13 }
Incremente essa classe. Faça outros testes, imprima outros atributos e invoque os métodos que
você criou a mais.
Lembre-se de seguir a convenção java, isso é importantíssimo. Isto é, nomeDeAtributo,
nomeDeMetodo, nomeDeVariavel, NomeDeClasse, etc... (Camel case).
Exercícios Teóricos
1) Relacione os termos “classe”, “objeto” e “instância”.
2) Defina os princípios/conceitos do paradigma OO.
3) Defina a estrutura de uma classe.
4) Qual a diferença entre programação orientada a eventos e programação orientada a
objetos?
5) Defina a classe Java Pessoa com os atributos nome e idade, e seus respectivos métodos
getters e setters.
6) Faça um programa que instancie duas Pessoas: João e Maria. O programa deve exibir os
dados de ambos os objetos.
2. Diagrama de Casos de Uso
Introdução
Um caso de uso é uma técnica de modelagem usada para descrever o que um novo sistema
deve fazer. Ele é construído através de um processo interativo no qual as discussões entre o cliente e
os desenvolvedores do sistema conduzem a uma especificação do sistema da qual todos estão de
acordo.
Um caso de uso descreve as operações que o sistema deve cumprir para cada usuário. Ele vai
ajudar a formalizar as funções que o sistema precisa fazer. Um caso de uso se apresenta como uma
lista completa das interações entre um usuário e o sistema para cumprir uma tarefa. Lista completa
significa que o caso de uso descreve as interações desde o início da tarefa, até o fim.
Casos de uso têm que ser compreensíveis por usuários porque só eles sabem o que o sistema
precisa fazer. Os casos de uso permitem verificar se o analista e o usuário concordam sobre o que o
sistema deve fazer. Isso é um problema importante no desenvolvimento de software. No mesmo
tempo, casos de uso podem servir de “contratos” entre os usuários e a equipe de desenvolvimento.
Casos de uso são narrativas em texto, amplamente utilizadas para descobrir e registrar
requisitos. Eles influenciam muitos aspectos de um projeto, inclusive a A/POO, e servem de entrada
para vários artefatos subseqüentes.
Objetivo
•
Decidir e descrever os requisitos funcionais do sistema;
•
Fornecer uma descrição clara e consistente do que o sistema deve fazer;
•
Permitir descobrir os requisitos funcionais das classes e operações do sistema (Casos de
uso NÃO são requisitos, mas ajudam a identificá-los).
Componentes
Podemos dizer que os componentes de um modelo de casos de uso são:
•
Ator - é um “papel” (role) que tipicamente estimula/solicita ações/eventos do sistema e
recebe reações. Cada ator pode participar de vários casos de uso;
•
Casos de uso - documento narrativo que descreve a seqüência de ações feitas por um
ator no uso do sistema;
•
Sistema - o sistema a ser modelado.
Na UML o modelo de casos de uso consiste de diagramas de casos de uso que mostram os
atores , os casos de uso e seus relacionamentos. Os elementos gráficos que representam atores, casos
de uso e sistema são mostrados abaixo:
Figura 3: casos de uso (UML)
Elementos
Os elementos principais do diagrama são uma elipse para representar um caso de uso e um
pequeno boneco para representar um ator.
O nome de um caso de uso pode ser qualquer sentença, mas a UML recomenda usar uma frase
ativa curta (verbo + substantivo), por exemplo: “comprar itens’’, “efetuar venda”, etc..
Exemplo
Informalmente, casos de uso são narrativas em texto de algum ator usando um sistema para
atingir objetivos. Segue um exemplo de caso de uso no formato resumido:
Processar Venda: um cliente chega em um ponto de pagamento com itens que deseja
adquirir. O caixa usa o sistema PDV para registrar cada item comprado. O sistema
apresenta um total parcial e detalhes de linha de item. O cliente entra com os dados
sobre o pagamento, que são validados e, em seguida, registrados pelo sistema. O
sistema atualiza o estoque. O cliente recebe um recibo do sistema e sai com os itens
comprados.
Note que casos de uso não são diagramas, são textos. Enfocar os diagramas de caso de uso
UML, de valor secundário, em vez do importante texto do caso de uso, é um erro comum para novatos.
Casos de uso frequentemente necessitam ser mais detalhados ou estruturados do que no
exemplo, mas o essencial é descobrir e registrar os requisitos funcionais, escrevendo narrativas de uso
de um sistema para satisfazer as metas do usuário, ou seja, casos de uso (“caso de utilização”). Não se
trata de uma idéia difícil, embora possa ser difícil descobrir o que é necessário e escrevê-lo de forma
coerente.
O que são atores, cenários e casos de uso?
Introdução
Primeiro, daremos algumas definições informais: um ator é algo com comportamento, tal como
uma pessoa (identificada por seu papel), um sistema de computador ou uma organização; por
exemplo, um caixa.
Um cenário é uma seqüência específica de ações e interações entre atores e o sistema; é
também chamado de instância de caso de uso. É uma história particular de uso de um sistema ou um
caminho através do caso de uso; por exemplo, o cenário de efetuar com sucesso a compra de itens em
dinheiro, ou o cenário de não consumar a compra de itens por causa da recusa de uma autorização de
crédito.
Em termos informais, então, um caso de uso é uma coleção de cenários relacionados de sucesso
e fracasso, que descrevem um ator usando um sistema como meio para atingir um objetivo. Por
exemplo, temos a seguir um caso de uso em um formato informal que inclui alguns cenários
alternativos:
Tratar Devoluções
Cenário de sucesso principal: um cliente chega a um posto de pagamento com itens a
serem devolvidos. O caixa usa o sistema PDV para registrar cada item devolvido...
Cenários alternativos:
Se o cliente pagou a crédito e a transação de reembolso para estorno em sua conta de
crédito é rejeitada, informe o cliente e o reembolse com dinheiro.
Se o identificador do item não for encontrado no sistema, este notifica o caixa e sugere
que entre manualmente o código do produto (talvez ele esteja corrompido).
Se o sistema detecta uma falha para se comunicar com o sistema externo de
contabilidade...
Agora que cenários (instâncias de casos de uso) estão definidos, uma definição alternativa,
porém similar, de “caso de uso” fornecida pelo RUP (Rational Unified Process) vai fazer mais sentido:
Um conjunto de instâncias de casos de uso, no qual cada instância é uma sequencia de ações
que um sistema executa e que fornece um resultado observável com valor para um determinado ator
[RUP].
Casos de uso e o modelo de casos de uso
O PU (Processo Unificado) define o Modelo de Casos de Uso dentro da disciplina Requisitos.
Essencialmente, trata-se do conjunto de todos os casos de uso escritos; é um modelo da
funcionalidade e ambiente do sistema.
Casos de uso são documentos de texto e não diagramas. Portanto, a modelagem de caso de uso
é essencialmente uma ação de redigir texto e não de desenhar diagramas.
O Modelo de Casos de Uso não é o único artefato de requisitos no PU. Existem também:
Especificação Suplementar, Glossário, Visão e Regras de Negócio. São todos úteis para análise de
requisitos, mas secundários neste ponto.
O Modelo de Casos de Uso pode opcionalmente incluir um diagrama de caso de uso UML para
mostrar os nomes de casos de uso, atores e seus relacionamentos. Isso dá um belo diagrama de
contexto de um sistema e do seu ambiente. Fornece também um modo rápido de listar os casos de
uso por nome.
Não há nada orientado a objetos em casos de uso; não estamos fazendo análise OO quando os
escrevemos. Isso não é problema – casos de uso são amplamente aplicáveis, o que aumenta sua
utilidade. Dito isso, casos de uso são considerados uma entrada de requisitos chave para a A/POO
clássica.
Motivação: por que casos de uso?
Nós temos objetivos e desejamos que os computadores nos ajudem a atingi-los. Os objetivos
vão desde o registro de vendas até o uso de jogos e programas para estimar o fluxo de petróleo de
futuros poços. Analistas experientes inventaram muitos modos de descobrir objetivos, mas os melhores
são simples e familiares. Por quê? Isso torna mais fácil – especialmente para clientes – contribuir para
sua definição e revisão. Isso diminui o risco de perder a referência. Este pode parecer um comentário
inoportuno, mas é importante. Pesquisadores apresentaram métodos complexos de análise que eles
entendem, mas que levam uma pessoa de negócios a entrar em coma! Falta de envolvimento do
usuário em projetos de software está perto do topo da lista de razões para fracassos de projetos
[Larman 03], assim, qualquer coisa que ajude a mantê-los envolvidos é realmente desejável.
Casos de uso são uma boa maneira de manter a coisa simples e de tornar possível a
especialistas no domínio ou fornecedores de requisitos escrever eles mesmos (ou participar da escrita
de) casos de uso.
Outro valor dos casos de uso é que eles enfatizam os objetivos e perspectivas do usuário;
formulamos a questão “quem está usando o sistema, quais são seus típicos cenários de uso e quais são
os seus objetivos?” Essa é uma ênfase mais centrada no usuário, comparada a simplesmente solicitar
uma lista de características do sistema.
Muito tem sido escrito sobre casos de uso e, apesar de valer a pena, pessoas criativas
frequentemente obscurecem uma ideia simples com camadas de sofisticação ou supercomplicação.
Geralmente, é possível encontrar um modelador de casos de uso novato (ou um analista sério tipo A)
que se preocupa em excesso com problemas secundários, como diagramas de casos de uso,
relacionamento entre casos de uso, pacotes de casos de uso e etc., em vez de se concentrar no
trabalho árduo de simplesmente escrever as narrativas em texto.
Dito isso, um dos pontos fortes do mecanismo de casos de uso é a sua capacidade de
escalabilidade para cima ou para baixo em termos de sofisticação e formalidade.
Guia Sugerido para Preparar Casos de Uso
Nome do Caso de Uso (Começar com um verbo.)
Descrição do caso de uso (um parágrafo). Escopo (O sistema em projeto.).
Atores
Ator principal – chama o sistema para fornecer os serviços.
Lista dos nomes dos atores com descrição curta.
Prioridade
Este caso de uso é muito importante no projeto ou é acessório?
Pré-Condições
Lista de condições que têm que ser verificadas antes que o caso de uso começa.
Fluxo de Eventos / Fluxo Principal
1. Primeiro passo no caso de uso – resposta do sistema.
2. Segundo passo no caso de uso – resposta do sistema.
3. ...
Fluxos Alternativos
Descrever os fluxos alternativos ou extensões.
Pós-Condições (garantias de sucesso)
Lista de condições que têm que ser verificadas depois do fim do caso de uso.
Pontos de extensão
Lista dos pontos de extensão no caso de uso.
Casos de uso incluídos
Lista dos nomes dos casos de usos incluídos.
Como identificar atores e casos de uso?
Introdução
Nos primeiros contatos com os modelos de casos de uso surgem com frequência perguntas para
as quais não existe uma resposta absoluta. São elas: Como identificar atores? Como identificar casos
de uso?
Para identificar os atores que vão participar do modelo devemos perguntar:
•
Quem usa o sistema?
•
Quem inicia o sistema?
•
Quem fornece os dados?
•
Quem usa as informações?
Descrição de Atores
Geralmente descreve atores usando:
•
Nome do caso de uso;
•
Tipo de uso (frequente, ocasional , etc.);
•
Descrição de seu papel no sistema.
Tipos de Atores
Um ator é qualquer coisa com um comportamento, inclusive o próprio sistema em discussão
quando invoca os serviços de outros sistemas. Atores principais e de suporte aparecerão nos passos de
ação do texto do caso de uso. Atores não são somente papéis desempenhados por pessoas, mas
também por organizações, software e máquinas. Há três tipos de atores externos em relação ao
sistema:
•
Ator Principal (Primary) – tem objetivos de usuário satisfeitos por meio do uso dos serviços
do sistema. Por exemplo, o caixa.
o Por que identificar? Para encontrar objetivos de usuário, que guiam os casos de uso.
•
Ator de Suporte (Supporting) – fornece um serviço (por exemplo, informações) para o
sistema. O serviço automatizado de autorização de pagamento é um exemplo. Frequentemente
é um sistema de computador, mas pode ser uma organização ou pessoa.
o Por que identificar? Para esclarecer interfaces externas e protocolos.
•
Ator de Bastidor (Offstage) – tem interesse no comportamento do caso de uso, mas não é um
ator principal ou de suporte; por exemplo, um órgão governamental responsável por impostos.
o Por que identificar? Para garantir que todos os interesses necessários estejam
identificados e satisfeitos. Os interesses de atores de bastidor são, às vezes, sutis ou de
fácil esquecimento, a menos que esses atores sejam explicitamente nomeados.
Formatos Comuns de Casos de Uso
Casos de uso podem ser escritos em diferentes formatos e níveis de formalidade:
•
Resumido (brief) – resumo sucinto de um parágrafo, geralmente o cenário de sucesso
principal. O exemplo precedente Processar Venda foi resumido.
o Quando? Durante a análise de requisitos inicial, para obter uma rápida ideia do
assunto e escopo. Pode levar apenas alguns minutos para criar.
•
Informal (casual) – formato informal de parágrafos. Múltiplos parágrafos que cobrem vários
cenários. O exemplo precedente Tratar Devoluções foi informal.
o Quando? Como acima.
•
Completo (fully dressed) – Todos os passos e variantes são escritos em detalhe, e há seções
de suporte, como pré-condições e garantias de sucesso.
o Quando? Depois que muitos casos de uso tiverem sido identificados e escritos em
formato resumido, então durante o primeiro workshop de requisitos, alguns (como por
exemplo, 10%) dos casos de uso arquiteturalmente significativos e de alto valor, são
escritos em detalhe.
Exemplo – Caso de Uso Completo
Use Case UC1: Process Sale
Scope: NextGen POS application
Level: user goal
Primary Actor: Cashier
Stakeholders and Interests:
•
Cashier: Wants accurate, fast entry, and no payment errors, as cash drawer shortages are
deducted from his/her salary.
•
Salesperson: Wants sales commissions updated.
•
Customer: Wants purchase and fast service with minimal effort. Wants easily visible display
of entered items and prices. Wants proof of purchase to support returns.
•
Company: Wants to accurately record transactions and satisfy customer interests. Wants to
ensure that Payment Authorization Service payment receivables are recorded. Wants some
fault tolerance to allow sales capture even if server components (e.g., remote credit
validation) are unavailable. Wants automatic and fast update of accounting and inventory.
•
Manager: Wants to be able to quickly perform override operations, and easily debug Cashier
problems.
•
Government Tax Agencies: Want to collect tax from every sale. May be multiple agencies,
such as national, state, and county.
•
Payment Authorization Service: Wants to receive digital authorization requests in the correct
format and protocol. Wants to accurately account for their payables to the store.
Preconditions: Cashier is identified and authenticated.
Success Guarantee (or Postconditions): Sale is saved. Tax is correctly calculated.
Accounting and Inventory are updated. Commissions recorded. Receipt is generated. Payment
authorization approvals are recorded.
Main Success Scenario (or Basic Flow):
1. Customer arrives at POS checkout with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and presents item description, price, and running total. Price
calculated from a set of price rules. Cashier repeats steps 3-4 until indicates done.
5. System presents total with taxes calculated.
6. Cashier tells Customer the total, and asks for payment.
7. Customer pays and System handles payment.
8. System logs completed sale and sends sale and payment information to the external
Accounting system (for accounting and commissions) and Inventory system (to update
inventory).
9. System presents receipt.
10. Customer leaves with receipt and goods (if any).
Extensions (or Alternative Flows):
*a. At any time, Manager requests an override operation:
1. System enters Manager-authorized mode.
2. Manager or Cashier performs one Manager-mode operation. e.g., cash balance change,
resume a suspended sale on another register, void a sale, etc.
3. System reverts to Cashier-authorized mode.
*b. At any time, System fails:
To support recovery and correct accounting, ensure all transaction sensitive state and events
can be recovered from any step of the scenario.
1. Cashier restarts System, logs in, and requests recovery of prior state.
2. System reconstructs prior state.
2a. System detects anomalies preventing recovery:
1. System signals error to the Cashier, records the error, and enters a clean state.
2. Cashier starts a new sale.
1a. Customer or Manager indicate to resume a suspended sale.
1. Cashier performs resume operation, and enters the ID to retrieve the sale.
2. System displays the state of the resumed sale, with subtotal.
2a. Sale not found.
1. System signals error to the Cashier.
2. Cashier probably starts new sale and re-enters all items.
3. Cashier continues with sale (probably entering more items or handling payment).
2-4a. Customer tells Cashier they have a tax-exempt status (e.g., seniors, native peoples)
1. Cashier verifies, and then enters tax-exempt status code.
2. System records status (which it will use during tax calculations)
3a. Invalid item ID (not found in system):
1. System signals error and rejects entry.
2. Cashier responds to the error:
2a. There is a human-readable item ID (e.g., a numeric UPC):
1. Cashier manually enters the item ID.
2. System displays description and price.
2a. Invalid item ID: System signals error. Cashier tries alternate
method.
2b. There is no item ID, but there is a price on the tag:
1. Cashier asks Manager to perform an override operation.
2. Managers performs override.
3. Cashier indicates manual price entry, enters price, and requests
standard taxation for this amount (because there is no product information, the
tax engine can’t otherwise deduce how to tax it)
2c. Cashier performs Find Product Help to obtain true item ID and price.
2d. Otherwise, Cashier asks an employee for the true item ID or price, and does
either manual ID or manual price entry (see above).
3b. There are multiple of same item category and tracking unique item identity not important
(e.g., 5 packages of veggie-burgers):
1. Cashier can enter item category identifier and the quantity.
3c. Item requires manual category and price entry (such as flowers or cards with a price on
them):
1. Cashier enters special manual category code, plus the price.
3-6a: Customer asks Cashier to remove (i.e., void) an item from the purchase: This is only legal
if the item value is less than the void limit for Cashiers, otherwise a Manager override is needed.
1. Cashier enters item identifier for removal from sale.
2. System removes item and displays updated running total.
2a. Item price exceeds void limit for Cashiers:
1. System signals error, and suggests Manager override.
2. Cashier requests Manager override, gets it, and repeats operation.
3-6b. Customer tells Cashier to cancel sale:
1. Cashier cancels sale on System.
3-6c. Cashier suspends the sale:
1. System records sale so that it is available for retrieval on any POS register.
2. System presents a “suspend receipt” that includes the line items, and a sale ID used
to retrieve and resume the sale.
4a. The system supplied item price is not wanted (e.g., Customer complained about something
and is offered a lower price):
1. Cashier requests approval from Manager.
2. Manager performs override operation.
3. Cashier enters manual override price.
4. System presents new price.
5a. System detects failure to communicate with external tax calculation system service:
1. System restarts the service on the POS node, and continues.
1a. System detects that the service does not restart.
1. System signals error.
2. Cashier may manually calculate and enter the tax, or cancel the sale.
5b. Customer says they are eligible for a discount (e.g., employee, preferred customer):
1. Cashier signals discount request.
2. Cashier enters Customer identification.
3. System presents discount total, based on discount rules.
5c. Customer says they have credit in their account, to apply to the sale:
1. Cashier signals credit request.
2. Cashier enters Customer identification.
3. Systems applies credit up to price=0, and reduces remaining credit.
6a. Customer says they intended to pay by cash but don’t have enough cash:
1. Cashier asks for alternate payment method.
1a. Customer tells Cashier to cancel sale. Cashier cancels sale on System.
7a. Paying by cash:
1. Cashier enters the cash amount tendered.
2. System presents the balance due, and releases the cash drawer.
3. Cashier deposits cash tendered and returns balance in cash to Customer.
4. System records the cash payment.
7b. Paying by credit:
1. Customer enters their credit account information.
2. System displays their payment for verification.
3. Cashier confirms.
3a. Cashier cancels payment step:
1. System reverts to “item entry” mode.
4. System sends payment authorization request to an external Payment Authorization
Service System, and requests payment approval.
4a. System detects failure to collaborate with external system:
1. System signals error to Cashier.
2. Cashier asks Customer for alternate payment.
5. System receives payment approval, signals approval to Cashier, and releases cash
drawer (to insert signed credit payment receipt).
5a. System receives payment denial:
1. System signals denial to Cashier.
2. Cashier asks Customer for alternate payment.
5b. Timeout waiting for response.
1. System signals timeout to Cashier.
2. Cashier may try again, or ask Customer for alternate payment.
6. System records the credit payment, which includes the payment approval.
7. System presents credit payment signature input mechanism.
8. Cashier asks Customer for a credit payment signature. Customer enters signature.
9. If signature on paper receipt, Cashier places receipt in cash drawer and closes it.
7c. Paying by check…
7d. Paying by debit…
7e. Cashier cancels payment step:
1. System reverts to “item entry” mode.
7f. Customer presents coupons:
1. Before handling payment, Cashier records each coupon and System reduces price as
appropriate. System records the used coupons for accounting reasons.
1a. Coupon entered is not for any purchased item:
1. System signals error to Cashier.
9a. There are product rebates:
1. System presents the rebate forms and rebate receipts for each item with a rebate.
9b. Customer requests gift receipt (no prices visible):
1. Cashier requests gift receipt and System presents it.
9c. Printer out of paper.
1. If System can detect the fault, will signal the problem.
2. Cashier replaces paper.
3. Cashier requests another receipt.
Special Requirements:
•
Touch screen UI on a large flat panel monitor. Text must be visible from 1 meter.
•
Credit authorization response within 30 seconds 90% of the time.
•
Somehow, we want robust recovery when access to remote services such the inventory system
is failing.
•
Language internationalization on the text displayed.
•
Pluggable business rules to be insertable at steps 3 and 7.
•
...
Technology and Data Variations List:
*a. Manager override entered by swiping an override card through a card reader, or entering an
authorization code via the keyboard.
3a. Item identifier entered by bar code laser scanner (if bar code is present) or keyboard.
3b. Item identifier may be any UPC, EAN, JAN, or SKU coding scheme.
7a. Credit account information entered by card reader or keyboard.
7b. Credit payment signature captured on paper receipt. But within two years, we predict many
customers will want digital signature capture.
Frequency of Occurrence: Could be nearly continuous.
Open Issues:
•
What are the tax law variations?
•
Explore the remote service recovery issue.
•
What customization is needed for different businesses?
•
Must a cashier take their cash drawer when they log out?
•
Can the customer directly use the card reader, or does the cashier have to do it?
Este caso de uso é ilustrativo e não pretende ser exaustivo (embora seja baseado nos requisitos
de um sistema PDV real – desenvolvido com projeto OO em Java). No entanto, é suficientemente
detalhado e complexo para oferecer um senso de realismo, de modo que um caso de uso completo
possa registrar muitos detalhes de requisitos. Este exemplo servirá de modelo para muitos problemas
de casos de uso.
Como encontrar Casos de Uso
Os casos de uso são interações entre os atores e o sistema. Temos então ações do ator e ações
do sistema, sendo que os atores sempre iniciam a ação.
Casos de uso são definidos para satisfazer aos objetivos dos atores principais. Assim, o
procedimento básico é:
1. Escolher a fronteira do sistema. Ele é somente uma aplicação de software, é o hardware e a
aplicação como uma unidade, é isso e mais uma pessoa usando o sistema, ou é toda uma
organização?
2. Identificar os atores principais – aqueles que têm objetivos satisfeitos por meio do uso dos
serviços do sistema.
3. Identificar os objetivos para cada ator principal.
4. Definir casos de uso que satisfaçam os objetivos dos usuários; nomeie-os de acordo com o
objetivo. Geralmente, os casos de uso no nível de objetivo do usuário estarão em uma relação
de um-para-um com os objetivos dos usuários, mas existe pelo menos uma exceção que será
examinada.
Certamente, em um desenvolvimento iterativo e evolutivo, nem todos os objetivos ou casos de
uso vão estar total ou corretamente identificados logo no início. Trata-se de uma descoberta evolutiva.
Recomendações
Nomeie um caso de uso começando com um verbo, para enfatizar que ele é um processo. Ex:
Cadastrar Cliente , Comprar Item, etc..
Para identificar claramente um ator iniciador e um evento, comece a descrição da sequência de
um caso de uso usando o seguinte esquema: “Este caso de uso começa quando o <Ator> <Evento que
inicia o caso de uso>...”
Exemplo: Este caso de uso começa quando um cliente chega com vários itens para efetuar uma
compra.
Vamos a outro exemplo: Suponha que você tenha um almoxarifado de peças onde clientes
façam pedidos e onde um operador receba tarefas do sistema para buscar peças para os pedidos dos
clientes e distribuir peças do setor de compras para o almoxarifado.
Como poderíamos identificar os atores e os casos de uso para este exemplo?
Vamos identificar os atores. Eles são: Cliente, Operador, Sistema e Setor de Compras. Certo?
Não, errado! No exemplo acima “Sistema” não pode ser um ator pois ele não se ajusta ao conceito
dado a um ator: Um agente externo ao sistema.
Lembre-se que um ator é um papel que interage com o sistema mas não faz parte do sistema.
Então, no lugar de Sistema, poderíamos sugerir um administrador ou gerente. Então os atores seriam:
Cliente, Operador, Administrador e Compras. Note ainda que podem existir subsistemas que interajam
com o sistema. Neste caso eles seriam considerados atores.
E os casos de usos, quais seriam?
•
solicita peças (ator Cliente)
•
entrega peças (ator Compras)
•
buscar pedidos (ator operador)
•
distribuir pedidos (ator operador)
•
cadastrar Tarefas (administrador)
Certo? Errado! No caso do ator operador, ele não atua sobre o sistema nos casos de uso buscar
pedidos e distribuir pedidos. Ele atua sobre o sistema realizando Tarefa. Então o correto seria:
•
solicita peças (ator Cliente)
•
entrega peças (ator Compras)
•
realiza Tarefa (ator operador)
Figura 4: atores e fronteira do sistema
•
cadastrar Tarefas (administrador)
O caixa ou o cliente é o ator principal?
Por que é o caixa, e não o cliente, o ator principal no caso de uso Processar Venda?
A resposta depende da fronteira do sistema em projeto e para quem o sistema está sendo
principalmente projetado, conforme ilustrado na figura 4. Se enxergarmos a empresa ou o
serviço de conclusão da venda (checkout) como um sistema agregado, o cliente é um ator
principal, com o objetivo de obter bens ou serviços e ir embora.
Aplicação de UML: diagramas de casos de uso
Introdução
A UML fornece a notação de diagramas de casos de uso para ilustrar os nomes dos casos de uso
e dos atores, bem como os relacionamentos entre eles (ver figura 5).
Figura 5: diagrama parcial de contexto dos casos de uso.
Um sinal típico de modeladores de casos de uso iniciantes (ou acadêmicos) é a preocupação
com diagramas de casos de uso e seus relacionamentos, em vez de escrever texto. Especialistas em
casos de uso mundialmente reconhecidos, como Fowler e Cockburn, entre outros, não se preocupam
com os diagramas de casos de uso e seus relacionamentos, concentrando-se, em vez disso, em sua
redação. Tendo isso como um alerta, um simples diagrama de caso de uso oferece um diagrama de
contexto visual sucinto para o sistema, que ilustra os atores externos e como eles usam o sistema.
Um diagrama de caso de uso é uma excelente imagem do contexto do sistema; ele é um bom
diagrama de contexto, ou seja, mostra a fronteira de um sistema, o que está fora dele e como o
sistema é usado. Serve como uma ferramenta de comunicação que resume o comportamento do
sistema e seus atores. A figura 5 é uma amostra de um diagrama de caso de uso de contexto parcial
para o sistema ProxGer.
Diretriz: diagramação
A figura 6 oferece algumas sugestões sobre o diagrama. Note a caixa de ator com o símbolo
«ator». Este símbolo é usado para as palavras-chave e estereótipos UML e incluem aspas horizontais –
guillemets – colchetes especiais de um único caractere («ator» e não “<<ator>>”), mais comumente
usados na tipografia francesa para indicar uma citação.
Figura 6: Sugestão de notação.
Para maior clareza, alguns preferem destacar os atores externos ao sistema de computador com
uma notação alternativa, como mostrado na figura 7.
Figura 7: Notação alternativa para ator.
Relacionamentos entre Casos de Uso
Introdução
A partir do diagrama de casos de uso preliminar, muitas vezes temos que definir casos de usos
adicionais, separadamente, pois as operações se encontram duplicadas em outros casos de uso ou são
complexas e longas e a separação nos ajuda a compreendê-las.
Os relacionamentos possíveis são: Inclusão, Extensão e Generalização.
Inclusão
Se um caso de uso inicia ou inclui o comportamento de outro, dizemos que ele usa o outro.
Exemplo: No caso de uso Comprar Item, se o pagamento for feito com dinheiro, podemos ter a
inclusão PagarComDinheiro.
O relacionamento de inclusão em UML é ilustrado com uma linha de generalização com o rótulo
«include».
Figura 8: Inclui
Então, para o exemplo do cliente, com o use case Solicitar Pedidos de peças, teríamos como
propriedades básicas da inclusão:
•
Realizar uma decomposição funcional;
•
Reduzir a complexidade de um caso de uso;
•
O caso de uso básico não pode executar sem a inclusão.
•
Comportamento comum.
Extensão
Define pontos de extensão (opcionais) que adicionam comportamento a um caso de uso base,
descrevendo uma variação do comportamento normal. O caso de uso base pode ser executado mesmo
sem a extensão.
Exemplo: O caso de uso Comprar Produto pode apresentar a extensão Compra por um Cliente
Regular. Os pontos de extensão são indicados na linha entre os casos de uso do sistema. Abaixo temos
diagramas UML exemplificando estes conceitos.
Figura 9: Estende
Dica: note que a seta sempre aponta para o “ido” (estendido, ou incluído).
Figura 10: Relacionamento de inclusão e extensão.
Generalização
Indica um caso de base que possui diferentes especializações, e inclui comportamento ou
sobrescreve o caso de uso base.
O caso de uso Pagar fatura apresenta as especializações: Pagamento com cartão e Pagamento
com Cheque, conforme o diagrama a seguir:
Figura 11: generalização do caso de uso.
Além disto temos também os relacionamentos entre atores onde um ator especializado pode
acessar os casos de uso de um Ator base.
A seguir temos um exemplo onde o Ator gerente acessa os casos de uso do ator funcionário:
Figura 12: generalização de atores.
Sugestões de ferramentas de Modelagem:
Introdução
Recomendamos as seguintes ferramentas:
•
Rational Rose (IBM RSA – Rational Software Architect).
•
Free: Jude/Community
•
Poseidon/Community
•
Visual Paradigm – Community Edition
Note que algumas empresas adotam o Microsoft Visio. Porém, ele não é considerado uma
ferramenta específica para UML – ao contrário do Visual Paradigm, por exemplo.
Exercícios
Faça os diagramas de caso de uso
Fazer Pedido - versão 1
Cenário informal
O caso de uso começa quando o cliente seleciona "fazer pedido". O cliente fornece seu nome e
endereço. Se o cliente fornece apenas o CEP, o sistema coloca automaticamente a cidade e o estado. O
cliente fornece os códigos do produto. O sistema devolve as descrições e o preço de cada produto. O
sistema calculará os valores totais para cada produto fornecido. O cliente fornece as informações sobre
cartão de crédito. Em seguida, ele submete os dados ao sistema. O sistema verifica as informações
fornecidas, marca o pedido como "pendente" e envia as informações de pagamento para o sistema de
contabilidade e pagamento. Quando o pagamento é confirmado, o pedido é marcado como
"confirmado" e o número de pedido (NP) é dado ao cliente.
Desenhe o caso de uso
Cenário: José resolveu desenvolver uma aplicação para controlar as ligações telefônicas de sua
casa, a fim de checar se o valor que paga mensalmente está correto. Assim, sempre que desejar
poderá listar as ligações efetuadas num determinado período, contabilizando o valor a pagar.
Para que isso seja possível, toda ligação será feita pelo computador. A cada solicitação de
ligação, a aplicação deverá registrar: a data da ligação, a hora da ligação, quantidade de minutos
gastos (que deve ser registrado no momento que a ligação for encerrada), o número de pulsos (que
deve ser calculado pela aplicação) e o telefone para onde se discou.
A aplicação permitirá o controle de uma agenda de telefones, com número do telefone e nome
da pessoa de contato. O usuário poderá escolher no momento da ligação, se deseja um dos registros
da agenda ou se digitará diretamente o número do telefone.
A forma de cálculo dos pulsos considera os seguintes critérios:
- A ligação ao ser completada já conta um pulso. A partir daí, a cada quatro minutos de
conversação concluída, cobra-se mais um pulso.
- Cada pulso custa R$ 0,08 para ligações locais.
Exemplo:
Ligação de 2 minutos - 1 pulso
Ligação de 4m30s - 2 pulsos
Ligação de 8 minutos - 3 pulsos
- Os finais de semana possuem uma promoção. Cada ligação contabiliza somente um pulso,
independente do número de minutos de conversação.
Desenhe o diagrama de casos de uso
Carlos aposta toda semana na Loteria, em jogos como quina, megasena, fotomania, etc. São
vários cartões por semana. Na hora de conferir é uma loucura. Certa vez, quase que ele confere o
cartão errado.
Para resolver isso, ele quer desenvolver uma aplicação que cadastre os cartões apostados e o
resultado de um concurso, apresentando o relatório final com os números acertados por cartão e o
valor do prêmio, se houver.
Exercício (Biblioteca)
Identifique os atores e elabore o diagrama de casos de uso para o sistema de controle de uma
biblioteca descrito a seguir:
É um sistema de suporte para uma biblioteca
A biblioteca empresta livros e revistas para clientes, que são registrados no sistema, no qual
também estão registrados os livros e as revistas.
A biblioteca controla a compra de novos títulos. De títulos populares compra-se várias cópias.
Livros antigos e revistas são removidos quando estão ultrapassados ou deteriorados.
Bibliotecário é um funcionário da biblioteca que interage com os clientes e seu trabalho é
auxiliado pelo sistema.
Um cliente pode reservar um livro ou revista que não está disponível no momento na biblioteca,
de forma que quando ele for devolvido ou comprado pela biblioteca, o cliente é avisado. A reserva é
cancelada quando o cliente retira o livro ou revista, ou através de um processo exclusivo de
cancelamento.
A biblioteca pode facilmente criar, atualizar, e apagar informações sobre seus títulos, clientes,
empréstimos, e reservas no sistema.
O sistema pode rodar em todos os ambientes populares (UNIX, Linux, windows, etc) e tem uma
interface gráfica (GUI) moderna.
O sistema deve ser facilmente estendido com novas funcionalidades
O sistema deve lidar com a mensagem que é enviada ao cliente quando um título reservado
torna-se disponível, e precisa checar se um determinado título está ultrapassado ou deteriorado.
Exercício (Coca-Cola)
Identifique os atores e elabore o diagrama de casos de uso para um sistema de controle de uma
máquina que vende Coca-Cola, descrito a seguir:
É um sistema de venda de Coca-cola em máquina automatizada.
O sistema deve estar preparado para receber e conferir o dinheiro colocado pelo Cliente,
inclusive para dar o troco.
Deve controlar a recarga de refrigerantes pelo Técnico, bem como o recolhimento do dinheiro da
máquina.
3. Diagrama de Classes
Diagrama de Classes
Introdução
O diagrama de classes demonstra a estrutura estática das classes de um sistema onde estas
representam as "coisas" que são gerenciadas pela aplicação modelada. Classes podem se relacionar
com outras através de diversas maneiras: associação (conectadas entre si), dependência (uma classe
depende ou usa outra classe), especialização (uma classe é uma especialização de outra classe), ou em
pacotes (classes agrupadas por características similares).
Todos estes relacionamentos são mostrados no diagrama de classes juntamente com as suas
estruturas internas, que são os atributos e operações. O diagrama de classes é considerado estático já
que a estrutura descrita é sempre válida em qualquer ponto do ciclo de vida do sistema.
Um sistema normalmente possui alguns diagramas de classes, já que não são todas as classes
que estão inseridas em um único diagrama e uma certa classes pode participar de vários diagramas de
classes.
Escopo ou Visibilidade
+, -, # (protected), ~ (friend/pacote). Visibilidade do elemento.
Figura 3.1: diagrama de classes.
Em UML as classes são representadas por um retângulo dividido em três compartimentos: o
compartimento de nome, que conterá apenas o nome da classe modelada, o de atributos, que possuirá
a relação de atributos que a classe possui em sua estrutura interna, e o compartimento de operações,
que serão o métodos de manipulação de dados e de comunicação de uma classe com outras do
sistema. A sintaxe usada em cada um destes compartimentos é independente de qualquer linguagem
de programação, embora pode ser usadas outras sintaxes como a do C++, Java, e etc.
Pacotes
Pacote é um mecanismo de agrupamento, onde
todos os modelos de elementos podem ser agrupados.
Em UML, um pacote é definido como: "Um mecanismo
de
propósito
geral
para
organizar
elementos
semanticamente relacionados em grupos." Todos os
modelos
de
referenciados
elementos
por
um
que
pacote
são
são
ligados
chamados
ou
de
"Conteúdo do pacote". Um pacote possui vários
modelos de elementos, e isto significa que estes não
podem ser incluídos em outros pacotes.
Pacotes podem importar modelos de elementos
Figura 3.2: pacotes.
de outros pacotes. Quando um modelo de elemento é
importado, refere-se apenas ao pacote que possui o elemento. Na grande maioria dos casos, os
pacotes possuem relacionamentos com outros pacotes. Embora estes não possuam semânticas
definidas para suas instâncias. Os relacionamentos permitidos entre pacotes são de dependência,
refinamento e generalização (herança).
O pacote tem uma grande similaridade com a agregação (relacionamento que será tratado em
seguida). O fato de um pacote ser composto de modelos de elementos cria uma agregação de
composição. Se este for destruído, todo o seu conteúdo também será.
Relacionamentos
Os relacionamentos ligam as classes/objetos entre si criando relações lógicas entre estas
entidades. Os relacionamentos podem ser dos seguintes tipos:
•
Associação: É uma conexão entre classes, e também significa que é uma conexão entre
objetos daquelas classes. Em UML, uma associação é definida com um relacionamento
que descreve uma série de ligações, onde a ligação é definida como a semântica entre as
duplas de objetos ligados.
•
Generalização: É um relacionamento de um elemento mais geral e outro mais específico.
O elemento mais específico pode conter apenas informações adicionais. Uma instância
(um objeto é uma instância de uma classe) do elemento mais específico pode ser usada
onde o elemento mais geral seja permitido.
•
Dependência e Refinamentos: Dependência é um relacionamento entre elementos, um
independente e outro dependente. Uma modificação é um elemento independente
afetará
diretamente
elementos
dependentes
do
anterior.
Refinamento
é
um
relacionamento entre duas descrições de uma mesma entidade, mas em níveis diferentes
de abstração.
Abordaremos agora cada tipo de relacionamento e suas respectivas sub-divisões:
Associações
Uma associação representa que duas classes possuem uma ligação (link) entre elas, significando
por exemplo que elas "conhecem uma a outra", "estão conectadas com", "para cada X existe um Y" e
assim por diante. Classes e associações são muito poderosas quando modeladas em sistemas
complexos.
Associações Normais
O tipo mais comum de associação é apenas uma conexão entre classes. É representada por uma
linha sólida entre duas classes. A associação possui um nome (junto à linha que representa a
associação), normalmente um verbo, mas substantivos também são permitidos.
Pode-se também colocar uma seta no final da associação indicando que esta só pode ser usada
para o lado onde a seta aponta. Mas associações também podem possuir dois nomes, significando um
nome para cada sentido da associação.
Para expressar a multiplicidade entre os relacionamentos, um intervalo indica quantos objetos
estão relacionados no link. O intervalo pode ser de zero para um (0..1), zero para vários (0..* ou
apenas *), um para vários (1..*), dois (2), cinco para 11 (5..11) e assim por diante. É também
possível expressar uma série de números como (1, 4, 6..12). Se não for descrito nenhuma
multiplicidade, então é considerado o padrão de um para um (1..1 ou apenas 1).
Figura 3.3: associação.
No exemplo acima vemos um relacionamento entre as classes Cliente e Conta Corrente se
relacionam por associação.
Associação Recursiva
É possível conectar uma classe a ela mesma através de uma associação e que ainda representa
semanticamente a conexão entre dois objetos, mas os objetos conectados são da mesma classe. Uma
associação deste tipo é chamada de associação recursiva.
Figura 3.4: associação recursiva.
Associação Qualificada
Associações qualificadas são usadas com associações de um para vários (1..*) ou vários para
vários (*).
Figura 3.5: associação qualificada.
O "qualificador" (identificador da associação qualificada) especifica como um determinado objeto
no final da associação "n" é identificado, e pode ser visto como um tipo de chave para separar todos os
objetos na associação. O identificador é desenhado como uma pequena caixa no final da associação
junto à classe de onde a navegação deve ser feita.
Associação Exclusiva
Em alguns modelos nem todas as combinações são válidas, e isto pode causar problemas que
devem ser tratados. Uma associação exclusiva é uma restrição em duas ou mais associações. Ela
especifica que objetos de uma classe podem participar de no máximo uma das associações em um
dado momento. Uma associação exclusiva é representada por uma linha tracejada entre as associações
que são parte da associação exclusiva, com a especificação "{ou}" sobre a linha tracejada.
Figura 3.6: associação exclusiva.
No diagrama acima um contrato não pode se referir a uma pessoa e a uma empresa ao mesmo
tempo, significando que o relacionamento é exclusivo a somente uma das duas classes.
Associação de Classe
Uma classe pode ser associada a uma outra
associação. Este tipo de associação não é conectado
a nenhuma das extremidades da associação já
existente, mas na própria linha da associação. Esta
associação serve para se adicionar informações
extras a associação já existente.
A associação da classe Fila com a associação
Figura 3.7: associação de classe.
das classes Cliente e Processo pode ser estendida com operações de adicionar processos na fila, para
ler e remover da fila e de ler o seu tamanho. Se operações ou atributos são adicionados a associação,
ela deve ser mostrada como uma classe.
Agregação e Composição
Agregação
A agregação é um caso particular da associação. A agregação indica que uma das classes do
relacionamento é uma parte, ou está contida em outra classe. As palavras chaves usadas para
identificar uma agregação são: "consiste em", "contém", "é parte de".
Figura 3.8: agregação.
Existem tipos especiais de agregação que são as agregações compartilhadas e as compostas.
Agregação Compartilhada: É dita compartilhada quando uma das classes é uma parte, ou está
contida na outra, mas esta parte pode fazer estar contida na outra várias vezes em um mesmo
momento.
Figura 3.9: agregação compartilhada.
No exemplo acima uma pessoa pode ser membro de um time ou vários times e em determinado
momento.
Composição
Agregação de Composição: É uma agregação onde uma classe que está contida na outra "vive"
e constitui a outra. Se o objeto da classe que contém for destruído, as classes da agregação de
composição serão destruídas juntamente já que as mesmas fazem parte da outra.
Figura 3.10: agregação de composição.
Generalizações
Definição
A generalização é um relacionamento entre um elemento geral e um outro mais específico. O
elemento mais específico possui todas as características do elemento geral e contém ainda mais
particularidades. Um objeto mais específico pode ser usado como uma instância do elemento mais
geral. A generalização, também chamada de herança, permite a criação de elementos especializados
em outros.
Existem alguns tipos de generalizações que variam em sua utilização a partir da situação. São
elas: generalização normal e restrita. As generalizações restritas se dividem em generalização de
sobreposição, disjuntiva, completa e incompleta.
Generalização Normal
Na generalização normal a classe mais específica, chamada de subclasse, herda tudo da classe
mais geral, chamada de superclasse. Os atributos, operações e todas as associações são herdadas.
Figura 3.11: generalização normal.
Uma classe pode ser tanto uma subclasse quanto uma superclasse, se ela estiver numa
hierarquia de classes que é um gráfico onde as classes estão ligadas através de generalizações.
A generalização normal é representada por uma linha entre as duas classes que fazem o
relacionamento, sendo que coloca-se um seta no lado da linha onde encontra-se a superclasse
indicando a generalização.
Observação: a herança deve ser “natural”. Ao criar uma girafa, nenhum programador deveria
estender elefante só porque precisa de “algo com quatro patas”. Senão, no futuro, podemos acabar
tendo uma “girafa com tromba”...
Dependências e Refinamentos
Definição
Além das associações e generalizações, existem ainda dois tipos de relacionamentos em UML. O
relacionamento de dependência é uma conexão semântica entre dois modelos de elementos, um
independente e outro dependente. Uma mudança no elemento independente irá afetar o modelo
dependente. Como no caso anterior com generalizações, os modelos de elementos podem ser uma
classe, um pacote, um use-case e assim por diante. Quando uma classe recebe um objeto de outra
classe como parâmetro, uma classe acessa o objeto global da outra. Nesse caso existe uma
dependência entre estas duas classes, apesar de não ser explícita.
Uma relação de dependência é simbolizada por uma linha tracejada com uma seta no final de
um dos lados do relacionamento. E sobre essa linha o tipo de dependência que existe entre as duas
classes. As classes "Amigas" provenientes do C++ são um exemplo de um relacionamento de
dependência.
Figura 3.12: dependência.
Os refinamentos são um tipo de relacionamento entre duas descrições de uma mesma coisa,
mas em níveis de abstração diferentes e podem ser usados para modelar diferentes implementações de
uma mesma coisa (uma implementação simples e outra mais complexa, mas também mais eficiente).
Os refinamentos são simbolizados por uma linha tracejada com um triângulo no final de um dos
lados do relacionamento e são usados em modelos de coordenação. Em grandes projetos, todos os
modelos que são feitos devem ser coordenados. Coordenação de modelos pode ser usada para mostrar
modelos em diferentes níveis de abstração que se relacionam e mostram também como modelos em
diferentes fases de desenvolvimento se relacionam.
Figura 3.13: refinamento.
Exercícios
Um estudo de caso em UML
Diante do apresentado no decorrer do trabalho, aplicaremos aqui grande parte dos conceitos
abordados diante de uma aplicação da UML num problema fictício que poderá ser de grande ajuda no
melhor entendimento das potencialidades da linguagem de modelagem unificada.
O estudo de caso dará mais ênfase na fases de análise de requisitos, análise e design, já que as
principais abstrações dos modelos do sistema se encontram nestas fases do desenvolvimento.
Desenvolveremos uma modelagem em UML para criarmos um sistema de manutenção e
controle de contas correntes e aplicações financeiras de um banco fictício.
Antes de dar início à primeira fase da modelagem, faremos algumas considerações sobre o que
o sistema se propõe a fazer e outras observações que consideramos de suma importância para o bom
entendimento do problema.
•
O sistema suportará um cadastro de clientes, onde cada cliente cadastrado poderá ter
várias contas correntes, vários dependentes ligados a ele, e várias contas de poupança.
•
Cada dependente poderá possuir várias contas de poupança, mas não poderão ter uma
conta corrente própria.
•
Entendemos poupança como uma conta que possui um valor, um prazo de aplicação a
uma taxa de juros (definida no vencimento da poupança).
•
Entendemos Aplicações Pré-fixadas como uma aplicação de um valor, em um prazo
predeterminado a uma taxa de juros previamente definida.
•
Tanto a conta corrente quanto a poupança deverão manter um histórico de todas as
movimentações de crédito, débito, transferências e aplicações de pré-fixados (préfixados apenas para conta corrente).
•
Uma conta corrente poderá ter várias aplicações pré-fixadas ligadas a ela.
4. Diagrama de Atividades e de Sequência
Diagrama de Atividades
Introdução
Um diagrama de atividades UML mostra atividades sequenciais e paralelas em um processo. Eles
são úteis para modelagem de processos de negócios, fluxos de trabalho (workflows), fluxos de dados e
algoritmos complexos.
Uma atividade é o estado de estar fazendo uma ação: tanto um processo de mundo real, como
realizar um exercício, ou a execução de uma rotina de software, tal como um método em uma classe.
O diagrama de atividades descreve a sequência de atividades, com suporte para comportamento
condicional e paralelo. Um diagrama de atividades é uma variante de um diagrama de estados no qual
a maioria, se não todos, dos estados é estado de atividade. Portanto, muito da terminologia segue a
mesma terminologia de estados.
Na figura 1 o símbolo central é o estado de atividade, ou simplesmente atividade.
Início
Receber
o Pedido
Separação
Atividade
Preencher
o Pedido
Guarda
Envia a
Fatura
Desvio
[Senão]
[Pedido Urgente]
Entrega Durante
a Noite
Entrega
Regular
Recebe o
Pagamento
Intercalação
Junção
Fechar
o Pedido
Fim
Fig. 1: Diagrama de Atividades
Como aplicar os diagramas de atividade?
Um diagrama de atividades da UML oferece uma notação rica para mostrar uma sequência de
atividades, inclusive atividades paralelas. Ele pode ser aplicado em qualquer perspectiva ou propósito,
mas é mais popular para visualizar fluxos de trabalho e processos de negócios, além de casos de uso.
Modelagem de processo de negócios: Um de meus clientes está no negócio de entrega expressa
de mercadorias. O processo de despachar um pacote é bastante não trivial; existem muitas partes
envolvidas (cliente, motorista, ...) e muitos passos. Embora este processo possa ser capturado por um
texto (no texto do caso de uso), neste caso os diagramas de atividades representam um excelente
exemplo de que figuras valem por mil palavras. Meu cliente usa diagramas de atividades para entender
seus atuais e complexos processos de negócio por meio de sua visualização. As partições são úteis
para ver as várias partes envolvidas e as ações paralelas envolvidas no processo de despacho. Os nós
de objetos ilustram o que está sendo movimentado de um lado para outro. Depois de modelar seus
processos atuais, eles exploram visualmente mudanças e otimizações.
Modelagem de fluxo de dados: A partir dos anos 70, diagramas de fluxos de dados (DFD)
tornaram-se uma forma popular de visualizar os principais passos e dados envolvidos em processos de
sistemas de software. Isso não equivale à modelagem de processos de negócios; em vez disso, DFDs
eram geralmente usados para mostrar fluxos de dados em um sistema computacional, embora
teoricamente pudessem ser aplicados à modelagem de processos de negócios. DFDs eram úteis para
documentar os principais fluxos de dados ou para explorar um novo projeto de alto nível em termos de
fluxo de dados. Veja a figura 13 para um exemplo de um DFD na notação clássica de Gane-Sarson.
Observe que os passos do processo são numerados, para indicar a ordem.
Figura 13: DFD Clássico, na notação Gane-Sarson.
A informação modelada em um DFD é útil, tanto para documentação quanto para descoberta,
mas a UML não inclui a notação para DFD. Felizmente, os diagramas de atividade da UML podem
satisfazer os mesmos propósitos – eles podem ser usados para modelagem de fluxo de dados,
substituindo a notação tradicional dos DFDs. A Figura 14 ilustra a mesma informação do DFD da Figura
13, mas usando um diagrama de atividades da UML. Note que além de podermos usar os nós de objeto
para mostrar os fluxos de dados, os nós dos armazéns de dados (datastore nodes) da UML podem
ser usados.
Figura 14: Aplicação da notação de
diagramas de atividades para mostrar um
modelo de fluxo de dados.
Programação concorrente e modelagem de algoritmos paralelos: Embora os detalhes estejam
fora do escopo desta introdução, algoritmos paralelos em problemas de programação concorrente
envolvem partições múltiplas e comportamento de fork e junção. Por exemplo, tais algoritmos são
usados em simulações 3D com elementos finitos ou modelagem por diferenças finitas, sendo aplicados
para modelagem de reservas de petróleo, análise de resistência de materiais e modelagem do tempo.
O espaço físico global é dividido em blocos grandes e muitas linhas de execução (ou processos)
paralelas executam, uma para cada sub-bloco. Nesses casos, as partições dos diagramas de atividade
UML podem ser usadas para representar diferentes linhas ou processos do sistema em operação. Os
nós de objeto podem ser usados para modelar os dados e objetos compartilhados. E, é claro, forking
pode ser usado para modelar a criação e execução paralela de múltiplas linhas ou processos, um por
partição.
Comportamento Condicional
Comportamento condicional é delineado por desvios (branches) e intercalações (merges). Um
desvio (branch) é uma transição de entrada única e várias transições de saída guardadas. Somente
uma transição de saída pode ser tomada, de modo que os guardas devem ser mutuamente exclusivos.
A utilização de [else] como um guarda indica que a transição “else” deverá ser usada se todos os
outros guardas do desvio forem falsos. Uma intercalação (merge) tem múltiplas transições de
entrada e uma única saída. Um merge marca o final de um comportamento condicional iniciado por um
branch.
Comportamento paralelo é indicado por separações (forks) e junções (joins). Uma separação
(fork) tem uma transição de entrada e várias transições de saída. Quando uma transição de entrada é
acionada (triggered) todas as transições de saída são executadas em paralelo. Quando temos
comportamento paralelo, precisamos sincronizar. Com a junção (join) a transição seguinte é efetuada
somente quando todos os estados nas transições de entrada tenham completado suas atividades.
O diagrama de atividades permite escolher a ordem em que as coisas vão ser feitas. Ele
simplesmente determina as regras essenciais de sequências que devem ser seguidas. Esta é a
diferença-chave entre um diagrama de atividades e um fluxograma: os fluxogramas são normalmente
limitados a processos sequenciais, enquanto que os diagramas de atividades podem lidar com
processos paralelos.
Os diagramas de atividades também são úteis para programas concorrentes, uma vez que é
possível projetar graficamente quais caminhos (threads) temos e quando eles precisam ser
sincronizados.
Separação e junção devem se completar. Isso significa que toda vez que tiver uma separação deve
haver uma junção que una as threads iniciadas por aquelas separações.
Entretanto, existem várias extensões para esta regra:
•
Um thread que sai de uma separação pode abrir-se em uma nova separação, com os novos
threads juntando-se antes de alcançar a junção da primeira separação.
•
Se um thread saindo de uma separação vai direto para outra separação, podemos remover a
segunda separação e somente ter os threads da segunda separação saindo da primeira
separação. De modo semelhante, se uma junção vai direto para outra junção, podemos
eliminar a primeira junção e ter as threads indo direto para a segunda.
•
Uma construção avançada chamada de estado de sincronia permite que façamos sincronia
em lugares onde a regra de encaixe de separação e junção impediria que fizéssemos isso.
Existe uma exceção para regra de que todos os estados de entrada em uma junção devem ter
terminado suas atividades, antes que a junção possa ser efetuada. Podemos acrescentar uma condição
para um thread saindo de uma separação. O resultado é um thread condicional. Durante a execução,
se a condição de um thread condicional for falsa, este thread é considerado completado no que diz
respeito à junção.
Separação removida
do diagrama
[a fim de vinho]
Cozinhar
Espaguete
Misturar Molho
Carbonara
Thread
Condicional
Abrir Vinho
Tinto
Combinar
Fig 2:
Separações, Junções e Thread Condicionais
Decompondo uma Atividade
Uma atividade pode ser dividida em subatividades. Isso funciona mais ou menos como
superestados e subestados em um diagrama de estados. Você pode somente mostrar o superestado no
diagrama-pai, ou pode mostrar o superestado no seu comportamento externo dentro dele.
As vantagens dos estados de fim e início explícitos são que uma atividade de entrega pode ser
usada em outros contextos, e o diagrama-pai é desacoplado dos conteúdos do diagrama subsidiário.
Como podemos mostrar que uma atividade é expandida em outro diagrama de atividades? As
figuras 15 e 16 ilustram isso, usando o símbolo de um ancinho.
Como podemos mostrar ramos condicionais? Veja o símbolo de decisão usado na Figura 16. O
símbolo correspondente para junção mostra como os fluxos podem voltar a ficar juntos.
Figura
15:
Uma
atividade
será expandida em outro diagrama.
Sinais são mostrados na Figura 17. Eles são úteis, por exemplo, quando você precisa modelar
eventos como o disparo de uma ação, ou uma solicitação de cancelamento.
Figura 16: A expansão de uma atividade.
Existe muito mais notação UML disponível para diagramas de atividades. Esta pequena
introdução destaca meramente alguns dos elementos mais comuns.
Figura 17: Sinais.
Concorrência Dinâmica
Concorrência dinâmica permite que você mostre iterações sem que tenha que construir um
ciclo. Ou seja, permite representar a repetição de uma atividade.
Concorrência Dinâmica
Receber o
Pedido
*
Preencher Linha
de Item
Entregar
Pedido
Fig 4: Concorrência Dinâmica
Raias (Swimlanes)
Para usar raias, você deve organizar seus diagramas de atividade em zonas verticais separadas
por linhas. Cada zona representa as responsabilidades de uma classe específica ou, um departamento
específico.
As raias são úteis porque combinam a descrição de lógica do diagrama de atividades com a
descrição de responsabilidade do diagrama de interação.
Figura 18: Modelagem do caso de uso Processar
Venda com um diagrama de atividades.
Quando utilizar Diagramas de Atividades?
Os diagramas de atividades têm qualidades e fraquezas definidas, por isso a melhor maneira de
usá-los é em combinação com outras técnicas. A maior qualidade dos diagramas de atividades está no
fato de que eles suportam e encorajam comportamento paralelo. A maior desvantagem destes
diagramas é que eles não deixam muito claras as ligações entre ações e objetos.
Você pode definir uma ligação para um objeto rotulando uma atividade com um nome de objeto
ou usando raias que dividem um diagrama de atividades em base em responsabilidades, mas isso não
tem a clareza simples de diagramas de interação. Por esta razão, algumas pessoas sentem que
diagramas de atividades não são orientados a objetos e, portanto, são maus.
Devemos utilizar diagramas de atividades nas seguintes situações:
•
Analisando um caso de uso.
•
Compreendendo workflow
•
Descrevendo um algoritmo sequencial complicado
•
Lidando com aplicações de processamento paralelo.
Não devemos usar diagramas de atividades nas seguintes situações:
•
Tentando ver como os objetos colaboram.
•
Tentando ver como um objeto se comporta durante o seu ciclo de vida.
•
Representando lógica condicional existente.
O diagrama de estados e diagramas de atividades faz com que exista uma base mais estável
para os desenvolvedores de ferramentas construírem as que executarão estes diagramas.
Diagramas de Sequência
Introdução
A UML inclui diagramas de interação para ilustrar como os objetos interagem por meio de
mensagens. Eles são usados para modelagem de objetos dinâmica. Há dois tipos comuns de diagramas
de interação: diagramas de sequência e de comunicação.
O termo diagrama de interação é uma generalização de dois tipos de diagramas
especializados da UML: diagramas de sequência e diagramas de comunicação. Ambos podem expressar
interações semelhantes.
Diagramas de sequência são os mais ricos dos dois tipos em termos de notação, mas diagramas
de comunicação também têm sua utilidade, especialmente para rascunho na parede.
Os diagramas de sequência ilustram as interações em um formato semelhante a cercas, nas
quais cada objeto novo é acrescentado à direita, conforme mostrado na Figura 19.
Figura 19: Diagrama de sequência.
O que isso poderia representar em código? Provavelmente, que a classe A tem um método
denominado fazerUm e um atributo do tipo B. Também que a classe B tem métodos chamados
fazerDois e fazerTres. Talvez a definição parcial da classe A seja:
public class A
{
private B meuB = new B();
public void fazerUm()
{
meuB.fazerDois();
meuB.fazerTres();
}
...
}
Um diagrama de sequência do sistema é um artefato criado rápida e facilmente que ilustra os
eventos de entrada e saída relacionados com o sistema em discussão. Eles são entradas para contratos
de operação e – mais importante – projeto de objetos.
A UML contém notação na forma de diagramas de sequência para ilustrar eventos provenientes
de atores externos ao sistema.
A influência dos artefatos do PU enfatizando diagramas de sequência de sistema é mostrada na
Figura 20. O texto do caso de uso e seus eventos implícitos no sistema são entradas para a criação do
DSS. As operações do DSS (tais como entrarItem) podem, por sua vez, ser analisadas nos contratos de
operação, detalhadas no Glossário, e – mais importante – servir como ponto de partida para projetar
objetos de colaboração.
Figura 20: Amostra da influência dos artefatos no PU.
Na maioria dos casos, usamos um diagrama de sequência para ilustrar as realizações de casos
de uso, isto é, para mostrar como os objetos interagem para executar o comportamento total ou
parcial de um caso de uso. Um ou mais diagramas de sequência podem ilustrar as interações de
objetos que constituem um caso de uso. Uma organização típica deve ter um diagrama de sequência
para o fluxo principal de eventos e um diagrama de sequência para cada subfluxo independente do
caso de uso.
Os diagramas de sequência
ência são muito importantes para designers porque eles esclarecem os
papéis
dos
objetos
em
um
fluxo
e,
portanto,
fornecem
entrada
básica
para
determinar
responsabilidades
bilidades de classe e interfaces.
Diferentemente de um diagrama de colaboração, um diagrama de sequ
sequência inclui sequências,
mas não inclui relacionamentos de objetos. Ambos expressam informações semelhantes; o que muda é
a forma como elas são mostradas. Os diagramas de sequência
ência mostram a sequência
seq
explícita de
mensagens e são melhores quando é importante visualizar a ordenação temporal das mensagens.
Quando você estiver interessado nos relacionamentos estruturais entre as instâncias de uma interação,
use um diagrama de colaboração.
Conteúdo de Diagrama de Sequência
Você pode ter objetos e instâncias de ator em diagramas de sequ
seq ência, juntamente com
mensagens que descrevem como eles interagem. O diagrama descreve o que ocorre nos objetos
participantes, em termos de ativações, e como os objetos se comunicam enviando mensagens uns aos
outros. É possível fazer um diagrama de sequência para cada variante do fluxo de eventos de um caso
de uso.
Figura 21: Um diagrama de seqüência que descreve parte
do fluxo de eventos do caso de uso Colocar Ligação Local em uma
Central Telefônica simples.
Objetos
Um objeto é mostrado como uma linha tracejada vertical denominada
denominada "linha de vida". A linha de
vida representa a existência do objeto em um momento específico. Um símbolo de objeto foi
desenhado no alto da linha de vida e mostra o nome do objeto e sua classe sublinhada e separada por
dois-pontos:
objectname : classname
FAETEC 2012
12 - Notas de Aula de MD3 – Prof. M. França – Página: 62
Você pode usar objetos em diagramas de sequência das seguintes formas:
a) Uma linha de vida pode representar um objeto ou sua classe. Portanto, a linha de vida pode
ser usada para modelar tanto o comportamento da classe quanto do objeto. Contudo, em geral,
uma linha de vida representa todos os objetos de uma determinada classe.
b) Uma classe de objeto pode não estar especificada. Geralmente, você cria primeiro um
diagrama de sequência com objetos e mais tarde especifica as suas classes.
c) Os objetos podem não ter nome, mas é recomendável nomeá-los se você quiser diferenciar os
diversos objetos da mesma classe.
d) Várias linhas de vida no mesmo diagrama podem representar objetos diferentes da mesma
classe; mas, como foi dito anteriormente, os objetos devem ser nomeados para que você possa
estabelecer a diferença entre os dois objetos.
e) Uma linha de vida que representa uma classe pode existir paralelamente a linhas de vida que
representam objetos daquela classe. O nome do objeto da linha de vida que representa a classe
pode ser definido com o nome da classe.
Atores
Geralmente, uma instância de ator é representada pela primeira (mais à esquerda) linha de vida
no diagrama de sequência, como o disparador da interação. Se houver várias instâncias de atores no
mesmo diagrama, tente mantê-las na linha de vida mais à esquerda ou na linha mais à direita.
Mensagens
Uma mensagem é uma comunicação entre objetos que leva informações na expectativa de que
resulte uma atividade; nos diagramas de sequência, uma mensagem é mostrada como uma seta sólida
horizontal partindo da linha de vida de um objeto para a linha de vida de outro objeto. No caso de uma
mensagem de um objeto para si mesmo, a seta pode iniciar e terminar na mesma linha de vida. A seta
é rotulada com o nome da mensagem e seus parâmetros. Ela também pode ser rotulada com um
número que indique a sequência da mensagem no processo geral de interação. Os números
sequenciais em geral são omitidos em diagramas de sequência, nos quais a localização física da seta
mostra a sequência relativa.
Uma mensagem pode ser não-atribuída, o que significa que seu nome é uma sequência de
caracteres temporária que descreve o sentido geral da mensagem e não é o nome de uma operação do
objeto recebedor. Mais tarde, você poderá atribuir à mensagem especificando a operação do objeto de
destino da mensagem. A operação especificada substituirá então o nome da mensagem.
Tipos de Mensagem
Mensagem de Criação
– Aponta diretamente para o objeto e é marcada com «create»
Mensagem de Retorno
– Opcional, e normalmente é omitida
– Usa seta tracejada
Marca de Destruição
– Indica o término da vida de um objeto com um “X”
Figura 22: Mensagens.
Mensagem Síncrona x Assíncrona
É possível utilizar dois tipos de mensagem de métodos no diagrama de sequência:
– Mensagem síncrona (seta cheia): a execução fica bloqueada até o retorno do
método.
– Mensagem assíncrona (seta vazia): a execução continua em paralelo ao método que
foi chamado (fork implícito).
Figura 23: Mensagens Síncronas e
Assíncronas.
Scripts
Os scripts descrevem o fluxo de eventos textualmente em um diagrama de sequência. Você
deve posicionar os scripts à esquerda das linhas de vida para poder ler o fluxo completo de cima para
baixo (consulte a Figura 21). Você pode anexar scripts a uma determinada mensagem assegurando,
assim, que o script se mova com a mensagem.
Distribuição de Fluxo de Controle
O controle centralizado de um fluxo de eventos ou de parte do fluxo de eventos significa que
poucos objetos guiam o fluxo trocando mensagens com outros objetos. Esses objetos controladores
decidem a ordem em que outros objetos serão ativados no caso de uso. A interação entre os objetos
restantes é mínima ou inexistente.
Exemplo:
No Sistema da Máquina de Reciclagem, o caso de uso Imprimir Relatório Diário controla,
entre outros, o número e o tipo de objetos retornados, e escreve a contagem em um recibo. O objeto
de controle Gerador de Relatório decide a ordem em que os totais serão extraídos e escritos.
Figura
24:
A
estrutura
de
comportamento do caso de uso Imprimir
Relatório Diário é centralizada no objeto
de controle Gerador de Relatório.
Esse é um exemplo de comportamento centralizado. A estrutura de controle é centralizada
principalmente porque as diferentes fases de subeventos do fluxo de eventos não dependem umas das
outras. A principal vantagem desse método é que cada objeto não precisa controlar a contagem do
objeto seguinte. Para mudar a ordem das fases de subeventos, basta fazer a mudança no objeto de
controle. Ainda será possível adicionar facilmente outra fase de subevento se, por exemplo, for incluído
um novo tipo de item retornável. Outra vantagem dessa estrutura é que você pode facilmente reutilizar
as várias fases de subeventos em outros casos de uso, porque a ordem de comportamento não está
embutida nos objetos.
O controle descentralizado surge quando os objetos participantes se comunicam diretamente
entre si, e não através de um ou mais objetos controladores.
Exemplo: No caso de uso Enviar Carta alguém remete uma carta para outro país através de
uma agência de correio. Primeiro, a carta é enviada para o país do destinatário. No país, a carta é
enviada para uma cidade específica. A cidade, por sua vez, envia a carta para a residência do
destinatário.
Figura 25: A estrutura de comportamento do
caso de uso Enviar Carta é descentralizada.
O comportamento do caso de uso é um fluxo de eventos descentralizado. As fases de
subeventos integram o conjunto. O remetente da carta fala em "enviar uma carta a alguém". Ele não
precisa nem deseja saber os detalhes de como as cartas são enviadas em países ou cidades.
(Provavelmente, se alguém remetesse uma carta dentro do mesmo país, nem todas as ações
ocorreriam.)
O tipo de controle usado depende do aplicativo. Geralmente, você deve tentar conseguir objetos
independentes, isto é, delegar várias tarefas aos objetos naturalmente mais apropriados a executá-las.
Figura 26: Uma estrutura de controle centralizada "em forma de
forquilha". Uma estrutura de controle descentralizada "em forma de
escada".
Um fluxo de eventos com controle centralizado terá um diagrama de sequência "em forma de
forquilha". Por outro lado, um diagrama de sequência "em forma de escada" ilustra que a estrutura de
controle foi descentralizada para os objetos participantes.
A estrutura de comportamento da realização de um caso de uso frequentemente consiste em
uma mistura de comportamento centralizado e descentralizado.
Uma estrutura descentralizada será adequada:
•
Se as fases de subevento estiverem intrinsecamente acopladas. Esse será o caso se os objetos
participantes:
o Formarem uma hierarquia de partes ou constituintes, como País - Estado - Cidade;
o Formarem uma hierarquia de informações, como CEO - Gerente de Divisão - Gerente de
Seção;
•
Representarem uma progressão cronológica fixa (a sequência de fases de subeventos será sempre
realizada na mesma ordem), como Anúncio - Pedido - Fatura -Remessa - Pagamento; ou
•
Formarem uma hierarquia de herança conceitual, como Animal - Mamífero - Gato.
Se você desejar encapsular a funcionalidade e, portanto, fazer abstrações dela. Isso é bom para
alguém que deseje utilizar sempre a funcionalidade inteira, porque a funcionalidade pode se tornar
desnecessariamente de difícil compreensão caso a estrutura de comportamento seja centralizada.
Uma estrutura centralizada será adequada:
•
Se a ordem em que as fases de subeventos serão executadas puder ser mudada.
•
Se você espera inserir novas fases de subeventos.
•
Se você deseja manter partes da funcionalidade reutilizáveis como peças separadas.
Repetições
O diagrama de sequência permite que repetições sejam feitas durante o fluxo. Para isso são
utilizados quadros (frames) do tipo loop.
Decisões
O diagrama de sequência permite que decisões sejam tomadas durante o fluxo
Para isso são utilizados quadros (frames) do tipo alt ou opt com condições de guarda
Exemplo:
Motivação: por que desenhar um DSS?
Uma questão interessante é útil no projeto de software é a seguinte: que eventos estão
entrando no nosso sistema? Por quê? Porque temos que projetar o software para tratar esses eventos
(desde o mouse, teclado, outro sistema, ...) e executar uma resposta. Basicamente, um sistema de
software reage a três coisas: (1) eventos externos de atores (seres humanos ou computadores), (2)
eventos de tempo e (3) falhas ou exceções (que frequentemente são de fontes externas).
Portanto, é útil saber quais, precisamente, são os eventos externos de entrada – os eventos do
sistema. Eles são uma parte importante da análise do comportamento do sistema.
Você pode estar familiarizado com a ideia de identificar as mensagens que entram em um
objeto de software. Mas esse conceito é útil em um nível mais alto de componentes, inclusive todo o
sistema visto (abstratamente) como uma coisa ou objeto.
Antes de prosseguir para um projeto detalhado de como uma aplicação de software vai
funcionar, é útil investigar e definir seu comportamento como uma “caixa-preta”. Comportamento do
sistema é uma descrição do que um sistema faz, sem explicar como o faz. Uma parte dessa descrição
é um diagrama de sequência do sistema. Outras partes incluem os casos de uso e os contratos de
operação do sistema.
Exemplo:
Figura
27:
Escolher
os
nomes
de
eventos e de operações no nível abstrato.
Exercícios
Diagramas de Atividades
1. Qual a finalidade do Diagrama de Atividades?
2. Quando é recomendado utilizar “raias” na descrição do diagrama de atividades?
3. Compare barra de Junção x Barra de Bifurcação
4. Construa o diagrama de atividades que descreva o processo de compras on-line
(Ex.Submarino, Americanas)
5. Construa o diagrama de atividades que modele as regras de negócio das avaliações do
semestre, considerando o seguinte mini-mundo:
•
Faltas (25%)
•
Avaliações das unidades (Três)
•
Prova final (média 5,0)
•
Media final=Media unidade (Peso 7) e prova final (Peso 3)
1 - Construa os Diagramas de Sequência para o Caso de Uso – “Reservar Carro”:
Nota: somente clientes já cadastrados poderão fazer a reserva do veículo on-line.
2 - Sistema de Vendas de Livros On-Line
Criar o Diagrama de Sequência para o Caso de Uso Cadastrar Livro, tendo como referência
a tela de cadastramento apresentada abaixo. Observe que esta mesma tela deverá ser preenchida por
dois atores diferentes. Primeiro o Funcionário, depois o Gerente registrando os preços de compra e
venda.
3. Construa um Diagrama de Seqüência para abrir uma conta, conforme a descrição
abaixo:
O cliente que deseja abrir uma conta no banco, encaminha um pedido de abertura de conta,
com a documentação necessária. O funcionário do banco, então irá consultar o cadastro do cliente por
meio do seu CPF, para determinar se o solicitante já se encontra cadastrado. Se o cliente já estiver
cadastrado, a consulta retornará as informações do cliente, caso contrário retornará um valor
significando que o cliente ainda não possui cadastro na instituição. Em seguida, o cadastro do cliente
poderá ser atualizado, caso necessário, podendo gerar uma nova instância da classe Cliente, se o
solicitante ainda não estiver registrado, ou simplesmente atualizar os dados do mesmo, se houver
necessidade de alguma atualização.
Antes de finalizar a atualização do cliente, algumas inconsistências devem ser levadas a efeito,
uma delas é o disparo do método para validação do CPF pelo próprio objeto da classe Cliente. Após o
término da atualização, o objeto da classe cliente retornará algum sinal para o funcionário do banco,
para indicar que o cliente foi atualizado com sucesso ou se ocorreu algum erro.
O banco então irá informar ao cliente se o seu pedido foi ou não aprovado. Em caso de
aprovação, o cliente irá fornecer o valor inicial necessário para a abertura da conta e escolherá a
senha. O funcionário irá disparar o método de abertura na classe ContaComum, ou seja, criará um
novo objeto ContaComum.
Após ter sido criado pela chamada do método abertura, o objeto de ContaComum irá disparar o
método gravar para gerar uma nova instância da classe Historico, registrando o movimento gerado
pela abertura da conta, pois, para abrir uma conta, a instituição exige que o cliente deposite algum
valor na mesma. O método gravar retornará um sinal indicando que o movimento foi registrado com
sucesso e o método abertura disparado na classe ContaComum, por sua vez, retornará o número da
conta gerado, indicando que a conta foi criada com sucesso e finalizando o processo de abertura de
conta.
4. Construa um Diagrama de Seqüência encerrar uma conta, conforme a descrição
abaixo:
Primeiramente um cliente se encaminha ao caixa do banco, representado pelo ator Funcionario
e solicita o encerramento de uma determinada conta comum. O caixa então irá verificar se a conta
informada realmente existe e se a senha informada é verdadeira, por meio do disparo do método
consulta. Caso a conta realmente exista, o próprio método irá chamar o método de validação de senha
para verificar se a senha informada pelo usuário está correta. Em caso positivo, será verificado o saldo
da conta.
Se o saldo retornado for positivo, então o caixa irá retirar o dinheiro da conta, o saque efetuado
deverá ser registrado no histórico das movimentações. Em seguida o objeto de ContaComum retornará
o valor do saldo para o atendente que deverá ser igual a zero se o método for executado com sucesso.
Finalmente o atendente irá chamar o método encerramento para fechar a conta do cliente no
objeto de ContaComum. Antes de concluir a execução, esse método pode, caso a conta a ser encerrada
seja a única possuída pelo cliente, atualizar o cadastro do mesmo, definindo o seu status como inativo,
por meio do método gravar no objeto de Fisica.
Caso tenha sido possível atualizar a instância da classe Física, então o método gravar retornará
um valor indicando que o cliente foi atualizado. A conta retornará um valor que instruirá o software
mostrar ao atendente a mensagem: “Conta Encerrada com Sucesso”, finalizando o processo de
encerramento de conta.
Referências
•
“Crise do Software” - Alanderson (FNM, Engenharia da Computação)
•
“Programação Orientada ao Objeto: uma abordagem didática” - UNICAMP
•
“Conceitos de OO” – Prof. Cleidson Souza - Universidade Federal do Pará
•
Apostila de “Java e OO” da CAELUM
•
“Java Help” da Oracle (em inglês)
•
“Linguagem de Modelagem Unificada”
•
Utilizando UML e Padrões – 3ª edição – Craig Larman
•
Object Management Group website at www.omg.org
6. Apêndice A – Questionário de Avaliação do Curso
FAETEC – Rio de Janeiro
Professor M. França
Disciplina:
Aluno:
__________
_______________________________________________
Data:
________
Período/Turma: ________
Observação: Solicite ao professor o endereço para preenchimento eletrônico.
Atenção: Procure dar respostas completas, evitando monossílabos: “sim”, “não”, “é”, “fui” etc..
E não se esqueça de perguntar ao professor sobre o 0,5 ponto relativo ao preenchimento deste.
1) O curso: O curso Técnico em Informática da Escola Técnica Estadual República possui um bom nível? As
matérias são atuais e relevantes? Ele proporciona um ambiente para que alunos interessados possam adquirir
conhecimentos aplicáveis profissionalmente?
2) A disciplina: A disciplina em questão (MD3) possui um conteúdo atual? O programa foi totalmente coberto? A
carga horária semanal foi suficiente para explanação e resolução de exercícios? As aulas práticas (se for o
caso) foram suficientes e em condições adequadas (máquinas)?
3) O professor: O professor possuía domínio da disciplina (conhecimento)? Ele explica bem (didático)? Ele é
cordial e atencioso para com os alunos? Ele estava sempre disposto a explicar novamente algum conceito mal
compreendido? Existe algum ponto positivo e/ou negativo no professor?
4) O aluno: Você freqüenta as aulas assiduamente? Você faz os exercícios/estuda em casa? Você presta atenção
na explicação do professor? Você se considera um aluno agitado/disperso? Você conseguiu aprender os
principais conceitos da disciplina? Você tentou tirar suas dúvidas com o professor?
5) Livre: Que sugestões, ou críticas, você gostaria de fornecer para a melhoria do processo?
6) Nota: Dê uma nota para a disciplina (MD3), de 0 (muito insatisfeito) a 10 (muito satisfeito): ______
Muito obrigado. Desejo a todos muito sucesso profissional e boas férias; Sem radicalismos!
“Teu coração é livre.
Tenha coragem para segui-lo!”
Brave Heart

- França.pro.br

Transcrição

Documentos relacionados

PMR2440 – Programação para Automação

Fluxograma

Laboratório IF43B TOO Prof. Tacla Conversor Celsius para

DIAGRAMA DE ESTADOS - Compra de e

Diagramas de Contexto - PM Tech Capacitação em Projetos

Shell Spirax S3 ATF MD3

Engenharia de Software Orientada a Objetos

UML2 - Diagrama de Sequencia

ATA DA SÉTIMA REUNIÃO DO CONSELHO DE

bula