AP_MD3_2012_FAETEC
description
Transcript of AP_MD3_2012_FAETEC
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 1
FUNDAO DE APOIO ESCOLA TCNICA
DO ESTADO DO RIO DE JANEIRO - FAETEC
Nome da Disciplina Perodo Carga Horria
MODELAGEM DE DADOS 3 MD3 2 2 aulas/semana
Notas de Aula v1.0
Fevereiro de 2012
Professor M. Frana
http://www.franca.pro.br/prof
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 2
Esta pgina foi deixada propositadamente em branco.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 3
O Autor
Marcelo Frana tcnico em Processamento de Dados, tecnlogo em Processamento de Dados,
analista de sistemas ps-graduado pela PUC-Rio, bacharel em Administrao de Sistemas de Informao,
licenciado em Informtica pelo Instituto Superior de Educao do Rio de Janeiro ISERJ,
mestre em Informtica pela Universidade Federal do Estado do Rio de Janeiro UNIRIO,
aluno do MBA em gerenciamento de projetos da Fundao Getlio Vargas,
certificado MCAD pela Microsoft, certificado SCJA pela Sun,
certificado RAD Associate pela IBM, certificado OCJP 6 (SCJP) pela Oracle,
professor de Informtica da FAETEC e da Faculdade de Informtica Lemos de Castro,
e especialista de sistemas da IBM Brasil.
Estuda Informtica desde 1990 e trabalha com Informtica desde 1994.
Dedicatria
Dedico este trabalho a todos os meus alunos e ex-alunos.
Desejo a todos vocs muito sucesso profissional.
Que seus objetivos sejam alcanados e que vocs sempre perseverem, mantendo o foco!
Agradecimentos
Agradeo a Deus pela iluminao e por ter sido to feliz na escolha desta profisso.
Obrigado, Senhor!
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 4
Esta pgina foi deixada propositadamente em branco.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 5
ndice 1. Introduo ao Paradigma OO ..................................................................................... 7
Motivao.................................................................................................................... 7
Tcnicas de Programao Tradicionais ............................................................................ 9
Histrico da Orientao a Objetos................................................................................. 10
Princpios Bsicos ....................................................................................................... 13
Introduo UML ....................................................................................................... 19
Exerccios .................................................................................................................. 20
2. Diagrama de Casos de Uso ...................................................................................... 23
Introduo ................................................................................................................ 23
O que so atores, cenrios e casos de uso? ................................................................... 25
Como identificar atores e casos de uso? ........................................................................ 28
Aplicao de UML: diagramas de casos de uso ............................................................... 37
Relacionamentos entre Casos de Uso ............................................................................ 38
Sugestes de ferramentas de Modelagem: .................................................................... 41
Exerccios .................................................................................................................. 42
3. Diagrama de Classes ............................................................................................... 45
Diagrama de Classes .................................................................................................. 45
Associaes ............................................................................................................... 47
Agregao e Composio ............................................................................................ 49
Generalizaes ........................................................................................................... 50
Dependncias e Refinamentos ..................................................................................... 51
Exerccios .................................................................................................................. 52
4. Diagrama de Atividades e de Sequncia .................................................................... 53
Diagrama de Atividades .............................................................................................. 53
Diagramas de Sequncia ............................................................................................. 60
Exerccios .................................................................................................................. 70
6. Apndice A Questionrio de Avaliao do Curso ....................................................... 77
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 6
Esta pgina foi deixada propositadamente em branco.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 7
1. Introduo ao Paradigma OO
Motivao
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 rpido crescimento da demanda por software, da complexidade dos problemas a serem resolvidos e
da inexistncia de tcnicas estabelecidas para o desenvolvimento de sistemas que funcionassem
adequadamente ou pudessem ser validados.
A noo da crise do software emergiu no final dos anos 60. Uma das primeiras e mais
conhecidas referncias ao termo foi feita por Edsger Dijkstra, na apresentao feita em 1972 na
Association for Computing Machinery Turing Award, intitulada "The Humble Programmer" (EWD340),
publicada no peridico Communications of the ACM.
Logo que o desenvolvimento de software comeou a caminhar com o advento das linguagens
estruturadas e modulares, uma situao tornou-se clara diante de todos: a indstria de software
estava falhando repetidamente na entrega de resultados dentro dos prazos, quase sempre estourando
os oramentos e apresentando um grau de qualidade duvidoso ou insatisfatrio.
Em um relatrio de 1969 [Naur, 1969], esse problema j havia sido reconhecido. Conforme foi
observado, cerca de 50 a 80% dos projetos nunca foram concludos ou estavam to longe de seus
objetivos que foram considerados fracassados. Dos sistemas que foram finalizados, 90% haviam
terminado 150 a 400% acima do oramento 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 no se limitavam a "sistemas que no funcionam corretamente",
mas envolviam tambm dvidas 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 tcnicas e medidas
pobres aplicadas sobre o processo e o produto, alm dos poucos critrios de qualidade estabelecidos
at ento [Pressman, 2004].
A palavra crise j tem sido discutida por no descrever exatamente o problema em questo.
Uma definio mais precisa talvez seja aflio crnica, pelas caractersticas de continuidade e
intermitncia dos sintomas [Pressman, 2004].
Todos esses fatores exigiram respostas e mtodos que foram sendo aprimorados e
documentados, dando incio rea de Engenharia de Software. A busca por eficincia e competncia
revelou oportunidades, desafios e perigos que guiaram as tecnologias e apontaram novos rumos para
as pesquisas.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 8
A Crise do Software e a Idade Mdia Para compreender melhor as origens da Crise de Software, podemos fazer uma comparao
muito interessante com a histria das outras indstrias. Por exemplo, antes da revoluo 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 obteno da matria prima at o produto
final.
As semelhanas com a indstria de software comeam logo a. Primeiro, porque as tcnicas de
desenvolvimento de software ainda no esto totalmente maduras e consolidadas. Afinal, a variedade
de tcnicas que surgiram nas ltimas dcadas enorme.
Em segundo lugar, existe uma tendncia muito forte em desenvolver software sem aproveitar o
material produzido no passado. E para piorar, alm de entreg-lo quase sempre mal documentado, a
maior parte do conhecimento envolvido na sua construo permanece apenas na cabea dos
desenvolvedores, o que deixa a situao muito parecida com a do sapateiro do exemplo.
Causas da Crise do Software
As causas da crise do software esto ligadas a complexidade do processo de software e a
relativa imaturidade da engenharia de software como profisso:
As estimativas de prazo e de custo frequentemente so imprecisas;
No dedicamos tempo para coletar dados sobre o processo de desenvolvimento de software;
Com poucos dados histricos como guia, as estimativas tem sido a olho, com resultados
notadamente ruins;
A produtividade das pessoas da rea de software no tem acompanhado a demanda por
seus servios;
Os projetos de desenvolvimento de software normalmente so efetuados apenas com um
vago indcio das exigncias do cliente;
A qualidade de software s vezes menos que adequada e s recentemente comeam a
surgir conceitos quantitativos slidos de garantia de qualidade de software;
O software existente muito difcil de manter e a tarefa de manuteno devora o oramento
destinado ao software; e a facilidade de manuteno no foi enfatizada como um critrio
importante.
A crise se manifesta de varias formas:
Projetos estourando o oramento;
Projetos estourando o prazo;
Software de baixa qualidade;
Software muitas vezes no atinge os requisitos;
Projetos no gerenciveis (escopo e prazo estourados) e o cdigo difcil de manter.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 9
A maior parte dos projetos, hoje, continua com estes problemas. Assim, pode se dizer que a
crise continua vigente ainda na atualidade.
As possveis solues para a crise de software:
O uso de melhores tcnicas, mtodos e ferramentas;
Mais treinamento e educao: Atualmente no se investe o suficiente;
A mudana de paradigma sobre o que desenvolver software e como deveria ser feito.
Tcnicas de Programao Tradicionais
Introduo
As tcnicas de programao tradicionais, como por exemplo a decomposio funcional, leva o
desenvolvedor a decompor o sistema em partes menores (funes), criando um emaranhado de
inmeras funes que chamam umas s outras.
Geralmente no h separao de conceitos e responsabilidades, causando dependncias
enormes no sistema, dificultando futuras manutenes no cdigo do programa.
No existe muito reaproveitamento de cdigo, ao contrrio, muitas vezes se tem muito cdigo
duplicado (mesmo trabalhando-se com tecnologia OO).
Programao Orientada a Eventos
Uma linguagem pode ser OO e no ser OE (Pascal), bem como pode ser OE (Visual Basic 6,
Javascript) e no 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 programao orientada a eventos Microsoft Visual Studio, por
exemplo.
bom salientar que o fato de uma linguagem ser considerada OO, no implica em que a mesma
no seja (tambm) uma linguagem estruturada suportando as instrues bsicas de seqncia,
repetio e seleo.
Em suma, a programao orientada a eventos, somada a componentizao (ferramentas
baseadas em componentes como text box, combo, button, form, etc., que agilizavam o
desenvolvimento de interfaces), tornou a programao para Windows uma tarefa relativamente fcil. A
gerao anterior de programadores trabalhava com linguagens como o Clipper, essencialmente
orientadas ao console/texto. Com o advento do Windows, surgiu um novo padro de interface com o
usurio. E a componentizao (Delphi e Visual Basic 5) e o conceito do RAD (Rapid Application
Development) proporcionaram que aplicaes inteiras fossem escritas em um tempo bastante
reduzido, em comparao com a gerao 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.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 10
Histrico da Orientao a Objetos Origens
A Programao Orientada ao Objeto (Object-Oriented Programming) pode ser considerada como
uma extenso quase natural da Programao Modular; entretanto a sigla OOP tem causado um certo
"frisson" na comunidade de computao, nos ltimos anos.
Na verdade, isto no deveria acontecer, uma vez que a OOP foi concebida h muito tempo atrs
(no inicio da dcada de 70). A sua origem vem da linguagem Simula (Simula Language), concebida na
Noruega no incio da dcada de 60, e como o nome indica, foi criada para fazer simulaes. Entretanto,
seu uso alavancou um conceito que at ento passava "despercebido" pela maioria dos projetistas: a
similaridade com o mundo real.
A primeira linguagem de programao 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 verses 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, poderosssima, que implementa todos os conceitos de OO, o que no acontece com as chamadas
linguagens OO hbridas que implementam apenas alguns conceitos de orientao ao objeto.
Com o aparecimento da famosa "crise do software", o emprego da OOP foi a sada
protagonizada pelos desenvolvedores para minimizar os custos dos sistemas, em particular os custos
relativos s manutenes corretivas, uma vez que cerca de 75% dos custos dos programas referem-se
ao indesejvel expediente de alterar e/ou remendar cdigos dos sistemas j implantados e em
operao. notrio que um dos grandes benefcios da OO a reutilizao (reuso de cdigo/classes),
alm do que, um bom projeto OO resulta em classes com alta coeso e baixo acoplamento o que
facilita a manuteno.
Basicamente, a OOP utiliza os mesmos princpios da engenharia de hardware que projeta novos
equipamentos usando os mesmos componentes bsicos como transistores, resistores, fusveis, diodos,
chips, etc. Os "objetos" j existentes so utilizados para produzir novos "objetos", tornando essa
metodologia mais poderosa que as metodologias tradicionais de desenvolvimento de sistemas.
Se consideramos a Orientao ao Objeto como um novo paradigma de desenho de software,
devemos considerar, tambm, uma nova maneira de pensar, porque apesar de a escrita do cdigo
continuar sendo procedural, alguns conceitos mudam radicalmente: a estruturao e o modelo
computacional. Fundamentalmente o que se deseja com esta metodologia so basicamente duas
caractersticas: reutilizao de cdigo e modularidade de escrita; e nisto a OOP imbatvel 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 memria e dispositivos de I/O para processar, armazenar
e exibir as informaes, a OOP emprega um conceito mais real, mais concreto, que o de Objeto.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 11
O que Orientao a Objetos? um paradigma para o desenvolvimento de software que baseia-se na utilizao de
componentes individuais (objetos) que colaboram para construir sistemas mais complexos. A
colaborao entre os objetos feita atravs 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 reutilizao de cdigo;
Os modelos refletem o mundo real de maneira mais aproximada: Descrevem de maneira
mais precisa os dados; A decomposio baseada em um particionamento natural; e so
mais fceis de entender e manter;
Pequenas mudanas nos requisitos no implicam em alteraes massivas no sistema em
desenvolvimento;
Implementao de tipos abstratos de dados (tipos que no sero implementados, mas
que servem ao projeto, pensando-se em herana).
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 so chamadas
OBJETOS criados a partir de CLASSES.
Uma classe a descrio de um grupo de objetos com propriedades similares (atributos),
comportamento comum (operaes), relacionamentos com outros objetos e semnticas idnticas. Todo
objeto instncia 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 esto relacionados.
Uma classe define a estrutura e o comportamento de qualquer objeto da classe, atuando como um
padro para a construo de objetos. Objetos podem ser agrupados em classes.
A definio da classe consiste na definio dos atributos e operaes dos objetos desta classe;
Um atributo uma caracterstica de uma classe. Atributos no apresentam comportamento, eles
definem a estrutura da classe; Operaes caracterizam o comportamento de um objeto, e so o nico
meio de acessar, manipular e modificar os atributos de um objeto.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 12
Exemplo: Programao Estruturada vs. OO
Vamos considerar o mesmo problema sendo resolvido, usando-se pseudo-cdigo, primeiro na
programao estruturada, e depois na programao orientada a objetos.
Ler 2 nmeros e exibir sua soma (Como?):
PROGRAMA SOMA
VARIVEIS
N1, N2: REAL
INCIO
ESCREVA ENTRE COM DOIS NMEROS:
LEIA N1, N2
ESCREVA A SOMA :, N1+N2
FIM
Note que a nfase neste caso est nas operaes que devem ser desempenhadas para a soluo
do problema. Neste caso a soluo fica muito presa ao problema, sendo mais difcil podermos
aproveitar este cdigo num outro cenrio. Alguns poderiam afirmar que este cdigo poderia ser
utilizado atravs do famoso Copy & Paste. Porm, esta tcnica no deve ser considerada quando
falamos de reuso, pois pode levar situaes de redundncia (o que dificulta e encarece a manuteno
do cdigo), bem como a situaes de inconsistncia (no caso de uma alterao ser necessria mas nem
todas as ocorrncias do cdigo foram atualizadas, logo, o cdigo ter cpias atualizadas e outras no
Find & Replace). Por fim, note que foram necessrias apenas 8 linhas de cdigo para a soluo no
paradigma estruturado (seqncia, seleo e repetio).
LOC = 8
Figura 1: relao entre classe e objeto
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 13
Ler 2 nmeros e exibir sua soma (Com o qu?):
CLASSE CALCULADORA
ATRIBUTOS
N1, N2: REAL
MTODOS
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
PROGRAMA SOMA
VARIVEIS
C: CALCULADORA
N: REAL
INCIO
C NOVO CALCULADORA
ESCREVA ENTRE COM DOIS NMEROS:
LEIA N
C.INFORMAR_N1(N)
LEIA N
C.INFORMAR_N2(N)
ESCREVA A SOMA :, C.RETORNAR_SOMA()
FIM
Princpios Bsicos
Abstrao
Informalmente um objeto representa uma entidade, tanto fsica quanto conceitual ou de
software. Exemplos:
Entidade Fsica: caminho, carro, bicicleta, etc.
Entidade Conceitual: processo qumico, matrcula, etc
Entidade de Software: lista encadeada, arquivo, etc.
Podemos afirmar que um objeto um conceito, abstrao, ou entidade com limites bem
definidos e um significado para a aplicao. Quando modelamos um objeto (classe), s consideramos o
LOC = 27
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 14
que for relevante. O time de futebol do corao pode no ser um atributo relevante para um sistema
de informao escolar, por exemplo.
Abstrao considerada como a habilidade de modelar caractersticas 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 fcil lidar com uma
linguagem que oferea recursos em que ele possa criar algo chamado "Cliente" ao invs de recorrer
estruturas de dados tipo array ou record.
Nesse contexto a abstrao 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 anlise e as
variveis e constantes que compem esse universo, desprezando os dados que no nos interessa na
anlise.
Podemos demonstrar o uso de abstrao facilmente, quando fechamos os olhos e pensamos em
uma mesa; esta mesa imaginria provavelmente no vai ser igual uma outra imaginada por outras
pessoas, mas o que importa que todos as pessoas que imaginaram uma mesa, colocaram nessa as
informaes que para elas so necessrias para a sua funo (de ser uma mesa). No importa se a
mesa de trs ps ou quatro, ou se o tampo de vidro, madeira ou mrmore; o que importa que a
imagem que idealizamos em nossa cabea de uma mesa e tenha as informaes necessrias para
cumprir sua funo.
Encapsulamento
Information Hiding: segurana, simplicidade, coeso.
Esconder os detalhes da implementao de um objeto chamado encapsulamento. A
capacidade de um objeto possuir uma parte privada, acessvel somente atravs dos mtodos definidos
na sua interface pblica; No se deve permitir acesso direto aos atributos de uma classe;
Benefcios: O cdigo cliente pode usar apenas a interface para a operao; A implementao do
objeto pode mudar, para corrigir erros, aumentar performance, etc. sem que seja necessrio modificar
o cdigo do cliente; A manuteno mais fcil e menos custosa; e cria um programa legvel e bem
estruturado. Na prtica, tendemos a diminuir o acoplamento, a dependncia externa (de outras
classes).
Normalmente, para respeitarmos o princpio do encapsulamento, todos os atributos de uma
classe devem ser private ou, no mximo, protected.
Observao: A linguagem Java no respeita totalmente o conceito do encapsulamento posto
que o escopo protected em Java permite que outras classes, que no filhas, consigam acessar o item
(atributo ou mtodo), apenas por fazer parte do mesmo pacote.
Encapsulamento a base de toda a abordagem da Programao Orientada ao Objeto; isto
porque contribui fundamentalmente para diminuir os malefcios causados pela interferncia externa
sobre os dados. Partindo desse princpio, toda e qualquer transao feita com esses dados s pode ser
feita atravs de procedimentos colocados "dentro" desse objeto, pelo envio de mensagens. Desta
maneira, dizemos que um dado est encapsulado quando envolvido por cdigo de forma que s
visvel na rotina onde foi criado; o mesmo acontece com uma rotina, que sendo encapsulada, suas
operaes internas so invisveis s outras rotinas. E at mesmo em linguagens consideradas no OO,
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 15
como no caso do Clipper 5.xx, segundo FERREIRA & JARABECK, pode-se observar um certo
encapsulamento nas rotinas em que as variveis so declaradas como LOCAL. Nesses casos tais
variveis so visveis somente dentro dessas rotinas aonde foram declaradas, o que permite ao
programador certa segurana quanto aos acessos indevidos por parte de outras rotinas, o que no
acontece com variveis PRIVATE ou PUBLIC, no contexto dessa linguagem.
Podemos visualizar a utilidade do encapsulamento pensando em um dvd, onde temos os botes
de liga-desliga, para frente, para traz, etc. Estes botes executam uma srie de operaes existentes
no aparelho, onde so executadas pelos componentes existentes dentro do aparelho (transistores,
cabos, motores, etc.) No interessa ao operador saber como o funcionamento interno do
equipamento; esta informao s relevante para os projetistas do aparelho (Encapsulamento =
Simplicidade). As informaes pertinentes ao usurio do equipamento so as existentes no meio
externo (botes, controle remoto) que ativam as operaes internas do equipamento. Desta maneira o
aparelho de dvd pode evoluir com os avanos tecnolgicos, 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 compatveis. Isto ocorre porque a
esses programas no interessa saber como o funcionamento interno da classe e sim sua funo, para
que ele possa executar, conforme ela evolui, novas funes colocadas sua disposio. A nica coisa
que interessa aos consumidores a API da classe (operaes pblicas).
Herana
Herana um mecanismo que, se for bem empregado, permite altos graus de reutilizao de
cdigo. Do ponto de vista prtico, pode ser entendido como sendo um conjunto de instncias criadas a
partir de um outro conjunto de instncias com caractersticas semelhantes, e os elementos desse
subconjunto herdam todas as caractersticas (se aplica a atributos e mtodos.) 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 + mtodos) da classe-me (ou super classe); isto torna o mecanismo de
herana uma tcnica muito eficiente para construir, organizar e reutilizar cdigo. Por isso, nas
linguagens que no suportam esse mecanismo, as classes so criadas como unidades independentes:
cada uma com seus membros concebidos do zero (sem vnculo direto com outras classes), o que torna
o processo mais demorado e com cdigos, s vezes, redundantes.
Um exemplo de linguagem que no implementa herana na sua forma clssica o Visual Basic
(at a atual verso desktop 6.0); neste caso o desenvolvedor tem que simular esse mecanismo,
usando a criatividade. A herana possibilita a criao de uma nova classe de modo que essa classe
(denominada subclasse, classe-filha ou classe derivada) herda TODAS as caractersticas da classe-me
(denominada superclasse, classe base ou classe primitiva); podendo ainda, a classe-filha, possuir
propriedades e mtodos prprios.
No processo de herana podemos imaginar um ser humano, que nasce com todas as
caractersticas de um ser humano sadio; agora, coloquemos nele uma roupa e um relgio. A roupa e o
relgio no faz parte do ser humano, mas quando "pegamos" este ser, vestido e com um relgio, e
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 16
realizamos o processo de herana gerada uma copia idntica da matriz. Se colocarmos um sapato
preto no ser humano original a sua copia tambm ficar calada, e se trocarmos a camisa do ser
humano original a sua cpia tambm vai receber a nova camisa; isto demonstra que a copia continua
vinculada matriz de origem. Podemos tirar quantas cpias que desejarmos da matriz original e todas
estas cpias mantero o seu vnculo. Podemos, at, tirar cpias das cpias, mas o processo de
modificarmos a matriz original implicar numa mudana em todas as outras que esto abaixo dela.
Nunca uma modificao feita nas copias altera a matriz de origem, e nunca podemos remover um item
que tenha sido recebido por intermdio da herana, isto que dizer que nenhuma das cpias (humanas)
poder se dar ao luxo de no ter o relgio.
Polimorfismo
O termo polimorfismo, etimologicamente, quer dizer "vrias formas"; todavia, na Informtica, e
em particular no universo da OOP, definido como sendo um cdigo que possui "vrios
comportamentos" ou que produz "vrios comportamentos"; em outras palavras, um cdigo que pode
ser aplicado vrias classes de objetos (se aplica a mtodos). De maneira prtica isto quer dizer que a
operao em questo mantm seu comportamento transparente para quaisquer tipos de argumentos;
isto , a mesma mensagem enviada a objetos de classes distintas e eles podero reagir de maneiras
diferentes.
Um mtodo polimrfico aquele que pode ser aplicado vrias classes de objetos sem que haja
qualquer inconveniente. o caso por exemplo, do mtodo Clear em Delphi, que pode ser aplicado
tanto classe TEdit como classe TListBox; nas duas situaes o contedo desse objetos so limpos,
mesmo pertencendo, ambos, classes distintas, LEITE.
Segundo FERREIRA & JARABECK, um exemplo bem didtico para o polimorfismo dado por um
simples moedor de carne. Esse equipamento tem a funo de moer carne, produzindo carne moda
para fazer bolinhos. Desse modo, no importa o tipo (classe) de carne alimentada; o resultado ser
sempre carne moda, no importa se de boi, de frango ou de qualquer outro tipo. As restries
impostas pelo processo esto no prprio objeto, definidas pelo seu fabricante e no pelo usurio do
produto.
comum a definio de que, para haver polimorfismo, preciso primeiro haver herana.
Polimorfismo se refere a mtodos, e nunca a atributos. Um mtodo herdado pode ser sobrescrito na
classe-filha, ou seja, apresentar um comportamento diferente do comportamento original da classe-
me. importante salientar que existe o chamado Polimorfismo de Interface, onde classes diferentes
(de hierarquias diferentes) implementam um mesmo conjunto de mtodos, cada qual sua maneira.
Classicamente isto no deve ser considerado polimorfismo posto que no existe herana, nem ligao
hierrquica neste caso.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 17
Binding Dinmico O acoplamento (binding) uma associao feita pelo compilador (interpretador) entre um
atributo e uma entidade. Exemplo: acoplamento entre tipos e variveis. O acoplamento pode ser:
Esttico: se ocorre antes do tempo de execuo e permanece inalterado durante a
execuo do programa. Exemplo: quando voc declara em Pascal que uma varivel do
tipo integer;
Dinmico ou Atrasado: se ocorre durante o tempo de execuo ou muda durante a
execuo do programa. Normalmente associado linguagens orientadas a objetos;
Exemplo (Java):
1 Elipse e;
2 Circulo c;
3 e := c;
4 e.calcularArea( );
A atribuio da linha 3 dinamicamente acoplada, pois acopla o objeto e a um tipo diferente de
seu tipo originalmente declarado. Em princpio, seria uma violao atribuir um objeto de um tipo
diferente do tipo da varivel e, no entanto, como c (Circulo) subclasse de e (Elipse) essa atribuio
vlida.
Qual o mtodo executado? O de Crculo ou de Elipse? Note que executamos o mtodo da
instncia e no da referncia. A operao executada a de Circulo, porque o compilador em tempo de
execuo verifica que a varivel aponta para um objeto desta classe.
Em algumas linguagens o programador deve pedir explicitamente o acoplamento dinmico para
uma mensagem em particular. Por exemplo, em C++ a operao deve ser declarada virtual na
superclasse e redefinida na subclasse.
Importante: Todas as operaes sobrescritas na classe derivada devem proporcionar
semanticamente os mesmos servios oferecidos pela superclasse.
Classes Abstratas
Uma classe abstrata uma classe que no tem instncias diretas. Uma classe concreta uma
classe que pode ter instncias. Em outras palavras se X uma classe abstrata o cdigo a seguir no
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 (Reutilizao).
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.
Alm disso, uma classe abstrata pode definir um protocolo para uma operao sem definir a
implementao do mtodo.
public abstract class Figure { // inicio da class Figure
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 18
public abstract double area();
public abstract double perimetro();
}// fim da class Figure
Assim, voc pode declarar mtodos abstratos em uma classe abstrata apenas para especificar
um protocolo comum de operaes. Toda subclasse concreta da classe abstrata deve fornecer uma
implementao para TODOS os mtodos 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 no implementa todos os mtodos abstratos ento ela
tambm abstrata; e Uma classe abstrata tambm pode ter mtodos concretos. Frequentemente, faz
sentido mover o mximo de funcionalidade possvel para uma superclasse, seja ela abstrata ou no.
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
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 19
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) pblica de uma classe, ou a interface de uma classe o
conjunto de todos os mtodos pblicos da classe.
Introduo UML
Motivao
O grande problema do desenvolvimento de novos sistemas utilizando a orientao a objetos nas
fases de anlise de requisitos, anlise de sistemas e design que no existe (ou existia) uma notao
padronizada e realmente eficaz que abranja qualquer tipo de aplicao que se deseje. Cada simbologia
existente possui seus prprios conceitos, grficos e terminologias, resultando numa grande confuso,
especialmente para aqueles que querem utilizar a orientao a objetos no 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 lanada, muitos desenvolvedores da rea da
orientao a objetos ficaram entusiasmados j que essa padronizao proposta pela UML era o tipo de
fora que eles sempre esperaram.
A UML muito mais que a padronizao de uma notao. tambm o desenvolvimento de
novos conceitos no normalmente usados. Por isso e muitas outras razes, o bom entendimento da
UML no apenas aprender a simbologia e o seu significado, mas tambm significa aprender a modelar
orientado a objetos no estado da arte.
UML foi desenvolvida por Grady Booch, James Rumbaugh, e Ivar Jacobson que so conhecidos
como "os trs amigos". Eles possuem um extenso conhecimento na rea de modelagem orientado a
objetos j que as trs mais conceituadas metodologias de modelagem orientada a objetos foram
desenvolvidas por eles, e a UML a juno do que havia de melhor nestas trs metodologias
adicionado novos conceitos e vises da linguagem.
Veremos como a UML aborda o carter esttico e dinmico do sistema a ser analisado levando
em considerao, j no perodo de modelagem, todas as futuras caractersticas do sistema em relao
utilizao de "packages" prprios da linguagem a ser utilizada, utilizao do banco de dados bem
como as diversas especificaes do sistema a ser desenvolvido de acordo com as mtricas finais do
sistema.
A verso atual da (especificao) UML pode ser conferida no site
http://www.omg.org/spec/UML/. No momento da preparao desta apostila, a verso 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
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 20
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.
Exerccios
Responda
Baseado no texto o que seria necessrio aplicar para evitar a Crise do Software?
Em sua opinio, estamos ainda em uma Crise de Software? Comente sua resposta.
Em sua opinio, a comparao entre a fabricao 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 construo, de
certa forma, artesanal? Comente sua resposta.
Em sua opinio, existem outras possveis solues para a crise de software alm das
descritas neste artigo?
Exerccio de Modelagem
O exerccio (modelo de funcionrios) a seguir tem por objetivo criar um sistema para gerenciar
os funcionrios do Banco.
1) Modele um funcionrio. Ele deve ter o nome do funcionrio, o departamento onde trabalha,
seu salrio (double), a data de entrada no banco (String), seu RG (String) e um valor booleano que
indique se o funcionrio ainda est ativo na empresa ou se j foi mandado embora.
Voc deve criar alguns mtodos de acordo com sua necessidade. Alm deles, crie um mtodo
bonifica que aumenta o salrio do funcionrio de acordo com o parmetro passado como argumento.
Crie, tambm, um mtodo demite, que no recebe parmetro algum, s modifica o valor booleano
indicando que o funcionrio no trabalha mais aqui.
A ideia aqui apenas modelar, isto , s identifique que informaes so importantes e o que
um funcionrio faz. Desenhe no papel tudo o que um Funcionario tem e tudo que ele faz.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 21
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 funcionrio chamada Funcionario, e a classe de teste voc
pode nomear como quiser. A de teste deve possuir o mtodo main.
Um esboo da classe:
class Funcionario {
double salario;
// seus outros atributos e mtodos
void bonifica(double aumento) {
// o que fazer aqui dentro?
}
void demite() {
// o que fazer aqui dentro?
}
}
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 compilao de uma vez s. Crie a classe
Funcionario, coloque seus atributos e, antes de colocar qualquer mtodo, compile o arquivo java.
Funcionario.class ser gerado, no podemos execut-la pois no h um main, mas assim verificamos
que nossa classe Funcionario j est tomando forma.
Esse um processo incremental. Procure desenvolver assim seus exerccios, para no descobrir
s no fim do caminho que algo estava muito errado. Um esboo 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. Faa outros testes, imprima outros atributos e invoque os mtodos que
voc criou a mais.
Lembre-se de seguir a conveno java, isso importantssimo. Isto , nomeDeAtributo,
nomeDeMetodo, nomeDeVariavel, NomeDeClasse, etc... (Camel case).
Figura 2: classe
Funcionario
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 22
Exerccios Tericos 1) Relacione os termos classe, objeto e instncia.
2) Defina os princpios/conceitos do paradigma OO.
3) Defina a estrutura de uma classe.
4) Qual a diferena entre programao orientada a eventos e programao orientada a
objetos?
5) Defina a classe Java Pessoa com os atributos nome e idade, e seus respectivos mtodos
getters e setters.
6) Faa um programa que instancie duas Pessoas: Joo e Maria. O programa deve exibir os
dados de ambos os objetos.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 23
2. Diagrama de Casos de Uso
Introduo Um caso de uso uma tcnica de modelagem usada para descrever o que um novo sistema
deve fazer. Ele construdo atravs de um processo interativo no qual as discusses entre o cliente e
os desenvolvedores do sistema conduzem a uma especificao do sistema da qual todos esto de
acordo.
Um caso de uso descreve as operaes que o sistema deve cumprir para cada usurio. Ele vai
ajudar a formalizar as funes que o sistema precisa fazer. Um caso de uso se apresenta como uma
lista completa das interaes entre um usurio e o sistema para cumprir uma tarefa. Lista completa
significa que o caso de uso descreve as interaes desde o incio da tarefa, at o fim.
Casos de uso tm que ser compreensveis por usurios porque s eles sabem o que o sistema
precisa fazer. Os casos de uso permitem verificar se o analista e o usurio 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 usurios e a equipe de desenvolvimento.
Casos de uso so 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 vrios artefatos subseqentes.
Objetivo Decidir e descrever os requisitos funcionais do sistema;
Fornecer uma descrio clara e consistente do que o sistema deve fazer;
Permitir descobrir os requisitos funcionais das classes e operaes do sistema (Casos de
uso NO so requisitos, mas ajudam a identific-los).
Componentes
Podemos dizer que os componentes de um modelo de casos de uso so:
Ator - um papel (role) que tipicamente estimula/solicita aes/eventos do sistema e
recebe reaes. Cada ator pode participar de vrios casos de uso;
Casos de uso - documento narrativo que descreve a seqncia de aes feitas por um
ator no uso do sistema;
Sistema - o sistema a ser modelado.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 24
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 grficos que representam atores, casos
de uso e sistema so mostrados abaixo:
Elementos
Os elementos principais do diagrama so 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 sentena, mas a UML recomenda usar uma frase
ativa curta (verbo + substantivo), por exemplo: comprar itens, efetuar venda, etc..
Figura 3: casos de uso (UML)
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 25
Exemplo
Informalmente, casos de uso so 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 so 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 no so diagramas, so textos. Enfocar os diagramas de caso de uso
UML, de valor secundrio, 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 usurio, ou seja, casos de uso (caso de utilizao). No se
trata de uma idia difcil, embora possa ser difcil descobrir o que necessrio e escrev-lo de forma
coerente.
O que so atores, cenrios e casos de uso?
Introduo
Primeiro, daremos algumas definies informais: um ator algo com comportamento, tal como
uma pessoa (identificada por seu papel), um sistema de computador ou uma organizao; por
exemplo, um caixa.
Um cenrio uma seqncia especfica de aes e interaes entre atores e o sistema;
tambm chamado de instncia de caso de uso. uma histria particular de uso de um sistema ou um
caminho atravs do caso de uso; por exemplo, o cenrio de efetuar com sucesso a compra de itens em
dinheiro, ou o cenrio de no consumar a compra de itens por causa da recusa de uma autorizao de
crdito.
Em termos informais, ento, um caso de uso uma coleo de cenrios 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 cenrios
alternativos:
Tratar Devolues
Cenrio 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...
Cenrios alternativos:
Se o cliente pagou a crdito e a transao de reembolso para estorno em sua conta de
crdito rejeitada, informe o cliente e o reembolse com dinheiro.
Se o identificador do item no for encontrado no sistema, este notifica o caixa e sugere
que entre manualmente o cdigo do produto (talvez ele esteja corrompido).
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 26
Se o sistema detecta uma falha para se comunicar com o sistema externo de
contabilidade...
Agora que cenrios (instncias de casos de uso) esto definidos, uma definio alternativa,
porm similar, de caso de uso fornecida pelo RUP (Rational Unified Process) vai fazer mais sentido:
Um conjunto de instncias de casos de uso, no qual cada instncia uma sequencia de aes
que um sistema executa e que fornece um resultado observvel 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 so documentos de texto e no diagramas. Portanto, a modelagem de caso de uso
essencialmente uma ao de redigir texto e no de desenhar diagramas.
O Modelo de Casos de Uso no o nico artefato de requisitos no PU. Existem tambm:
Especificao Suplementar, Glossrio, Viso e Regras de Negcio. So todos teis para anlise de
requisitos, mas secundrios 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 tambm um modo rpido de listar os casos de
uso por nome.
No h nada orientado a objetos em casos de uso; no estamos fazendo anlise OO quando os
escrevemos. Isso no problema casos de uso so amplamente aplicveis, o que aumenta sua
utilidade. Dito isso, casos de uso so considerados uma entrada de requisitos chave para a A/POO
clssica.
Motivao: por que casos de uso?
Ns temos objetivos e desejamos que os computadores nos ajudem a atingi-los. Os objetivos
vo desde o registro de vendas at o uso de jogos e programas para estimar o fluxo de petrleo de
futuros poos. Analistas experientes inventaram muitos modos de descobrir objetivos, mas os melhores
so simples e familiares. Por qu? Isso torna mais fcil especialmente para clientes contribuir para
sua definio e reviso. Isso diminui o risco de perder a referncia. Este pode parecer um comentrio
inoportuno, mas importante. Pesquisadores apresentaram mtodos complexos de anlise que eles
entendem, mas que levam uma pessoa de negcios a entrar em coma! Falta de envolvimento do
usurio em projetos de software est perto do topo da lista de razes para fracassos de projetos
[Larman 03], assim, qualquer coisa que ajude a mant-los envolvidos realmente desejvel.
Casos de uso so uma boa maneira de manter a coisa simples e de tornar possvel a
especialistas no domnio 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 usurio;
formulamos a questo quem est usando o sistema, quais so seus tpicos cenrios de uso e quais so
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 27
os seus objetivos? Essa uma nfase mais centrada no usurio, comparada a simplesmente solicitar
uma lista de caractersticas 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 sofisticao ou supercomplicao.
Geralmente, possvel encontrar um modelador de casos de uso novato (ou um analista srio tipo A)
que se preocupa em excesso com problemas secundrios, 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 sofisticao e formalidade.
Guia Sugerido para Preparar Casos de Uso
Nome do Caso de Uso (Comear com um verbo.)
Descrio do caso de uso (um pargrafo). Escopo (O sistema em projeto.).
Atores
Ator principal chama o sistema para fornecer os servios.
Lista dos nomes dos atores com descrio curta.
Prioridade
Este caso de uso muito importante no projeto ou acessrio?
Pr-Condies
Lista de condies que tm que ser verificadas antes que o caso de uso comea.
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 extenses.
Ps-Condies (garantias de sucesso)
Lista de condies que tm que ser verificadas depois do fim do caso de uso.
Pontos de extenso
Lista dos pontos de extenso no caso de uso.
Casos de uso includos
Lista dos nomes dos casos de usos includos.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 28
Como identificar atores e casos de uso?
Introduo
Nos primeiros contatos com os modelos de casos de uso surgem com frequncia perguntas para
as quais no existe uma resposta absoluta. So elas: Como identificar atores? Como identificar casos
de uso?
Para identificar os atores que vo participar do modelo devemos perguntar:
Quem usa o sistema? Quem inicia o sistema? Quem fornece os dados? Quem usa as informaes?
Descrio de Atores
Geralmente descreve atores usando:
Nome do caso de uso;
Tipo de uso (frequente, ocasional , etc.); Descrio de seu papel no sistema.
Tipos de Atores
Um ator qualquer coisa com um comportamento, inclusive o prprio sistema em discusso
quando invoca os servios de outros sistemas. Atores principais e de suporte aparecero nos passos de
ao do texto do caso de uso. Atores no so somente papis desempenhados por pessoas, mas
tambm por organizaes, software e mquinas. H trs tipos de atores externos em relao ao
sistema:
Ator Principal (Primary) tem objetivos de usurio satisfeitos por meio do uso dos servios do sistema. Por exemplo, o caixa.
o Por que identificar? Para encontrar objetivos de usurio, que guiam os casos de uso. Ator de Suporte (Supporting) fornece um servio (por exemplo, informaes) para o
sistema. O servio automatizado de autorizao de pagamento um exemplo. Frequentemente um sistema de computador, mas pode ser uma organizao 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 no um ator principal ou de suporte; por exemplo, um rgo governamental responsvel por impostos.
o Por que identificar? Para garantir que todos os interesses necessrios estejam identificados e satisfeitos. Os interesses de atores de bastidor so, s vezes, sutis ou de fcil esquecimento, a menos que esses atores sejam explicitamente nomeados.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 29
Formatos Comuns de Casos de Uso
Casos de uso podem ser escritos em diferentes formatos e nveis de formalidade:
Resumido (brief) resumo sucinto de um pargrafo, geralmente o cenrio de sucesso principal. O exemplo precedente Processar Venda foi resumido.
o Quando? Durante a anlise de requisitos inicial, para obter uma rpida ideia do assunto e escopo. Pode levar apenas alguns minutos para criar.
Informal (casual) formato informal de pargrafos. Mltiplos pargrafos que cobrem vrios cenrios. O exemplo precedente Tratar Devolues foi informal.
o Quando? Como acima. Completo (fully dressed) Todos os passos e variantes so escritos em detalhe, e h sees
de suporte, como pr-condies e garantias de sucesso. o Quando? Depois que muitos casos de uso tiverem sido identificados e escritos em
formato resumido, ento durante o primeiro workshop de requisitos, alguns (como por exemplo, 10%) dos casos de uso arquiteturalmente significativos e de alto valor, so 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.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 30
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.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 31
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 cant 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.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 32
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 dont 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.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 33
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.
. . .
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 34
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 no 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 so interaes entre os atores e o sistema. Temos ento aes do ator e aes
do sistema, sendo que os atores sempre iniciam a ao.
Casos de uso so definidos para satisfazer aos objetivos dos atores principais. Assim, o
procedimento bsico :
1. Escolher a fronteira do sistema. Ele somente uma aplicao de software, o hardware e a aplicao como uma unidade, isso e mais uma pessoa usando o sistema, ou toda uma organizao?
2. Identificar os atores principais aqueles que tm objetivos satisfeitos por meio do uso dos servios do sistema.
3. Identificar os objetivos para cada ator principal. 4. Definir casos de uso que satisfaam os objetivos dos usurios; nomeie-os de acordo com o
objetivo. Geralmente, os casos de uso no nvel de objetivo do usurio estaro em uma relao de um-para-um com os objetivos dos usurios, mas existe pelo menos uma exceo que ser examinada.
Certamente, em um desenvolvimento iterativo e evolutivo, nem todos os objetivos ou casos de
uso vo estar total ou corretamente identificados logo no incio. Trata-se de uma descoberta evolutiva.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 35
Recomendaes
Nomeie um caso de uso comeando 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 descrio da sequncia de
um caso de uso usando o seguinte esquema: Este caso de uso comea quando o ...
Exemplo: Este caso de uso comea quando um cliente chega com vrios itens para efetuar uma
compra.
Vamos a outro exemplo: Suponha que voc tenha um almoxarifado de peas onde clientes
faam pedidos e onde um operador receba tarefas do sistema para buscar peas para os pedidos dos
clientes e distribuir peas do setor de compras para o almoxarifado.
Como poderamos identificar os atores e os casos de uso para este exemplo?
Vamos identificar os atores. Eles so: Cliente, Operador, Sistema e Setor de Compras. Certo?
No, errado! No exemplo acima Sistema no pode ser um ator pois ele no 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 no faz parte do sistema.
Ento, no lugar de Sistema, poderamos sugerir um administrador ou gerente. Ento 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 peas (ator Cliente) entrega peas (ator Compras) buscar pedidos (ator operador) distribuir pedidos (ator operador) cadastrar Tarefas (administrador)
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 36
Certo? Errado! No caso do ator operador, ele no atua sobre o sistema nos casos de uso buscar
pedidos e distribuir pedidos. Ele atua sobre o sistema realizando Tarefa. Ento o correto seria:
solicita peas (ator Cliente) entrega peas (ator Compras) realiza Tarefa (ator operador)
cadastrar Tarefas (administrador)
O caixa ou o cliente o ator principal?
Por que o caixa, e no 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
servio de concluso da venda (checkout) como um sistema agregado, o cliente um ator
principal, com o objetivo de obter bens ou servios e ir embora.
Figura 4: atores e fronteira do sistema
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 37
Aplicao de UML: diagramas de casos de uso
Introduo
A UML fornece a notao 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).
Um sinal tpico de modeladores de casos de uso iniciantes (ou acadmicos) a preocupao
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, no se preocupam
com os diagramas de casos de uso e seus relacionamentos, concentrando-se, em vez disso, em sua
redao. 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 comunicao 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.
Figura 5: diagrama parcial de contexto dos casos de uso.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 38
Diretriz: diagramao
A figura 6 oferece algumas sugestes sobre o diagrama. Note a caixa de ator com o smbolo
ator. Este smbolo usado para as palavras-chave e esteretipos UML e incluem aspas horizontais
guillemets colchetes especiais de um nico caractere (ator e no ), mais comumente
usados na tipografia francesa para indicar uma citao.
Para maior clareza, alguns preferem destacar os atores externos ao sistema de computador com
uma notao alternativa, como mostrado na figura 7.
Relacionamentos entre Casos de Uso
Introduo
A partir do diagrama de casos de uso preliminar, muitas vezes temos que definir casos de usos
adicionais, separadamente, pois as operaes se encontram duplicadas em outros casos de uso ou so
complexas e longas e a separao nos ajuda a compreend-las.
Os relacionamentos possveis so: Incluso, Extenso e Generalizao.
Figura 6: Sugesto de notao.
Figura 7: Notao alternativa para ator.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 39
Incluso
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
incluso PagarComDinheiro.
O relacionamento de incluso em UML ilustrado com uma linha de generalizao com o rtulo
include.
Ento, para o exemplo do cliente, com o use case Solicitar Pedidos de peas, teramos como
propriedades bsicas da incluso:
Realizar uma decomposio funcional;
Reduzir a complexidade de um caso de uso;
O caso de uso bsico no pode executar sem a incluso.
Comportamento comum.
Extenso
Define pontos de extenso (opcionais) que adicionam comportamento a um caso de uso base,
descrevendo uma variao do comportamento normal. O caso de uso base pode ser executado mesmo
sem a extenso.
Figura 8: Inclui
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 40
Exemplo: O caso de uso Comprar Produto pode apresentar a extenso Compra por um Cliente
Regular. Os pontos de extenso so indicados na linha entre os casos de uso do sistema. Abaixo temos
diagramas UML exemplificando estes conceitos.
Dica: note que a seta sempre aponta para o ido (estendido, ou includo).
Generalizao
Indica um caso de base que possui diferentes especializaes, e inclui comportamento ou
sobrescreve o caso de uso base.
O caso de uso Pagar fatura apresenta as especializaes: Pagamento com carto e Pagamento
com Cheque, conforme o diagrama a seguir:
Figura 9: Estende
Figura 10: Relacionamento de incluso e extenso.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 41
Alm disto temos tambm 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 funcionrio:
Sugestes de ferramentas de Modelagem:
Introduo
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. Porm, ele no considerado uma
ferramenta especfica para UML ao contrrio do Visual Paradigm, por exemplo.
Figura 11: generalizao do caso de uso.
Figura 12: generalizao de atores.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 42
Exerccios
Faa os diagramas de caso de uso
Fazer Pedido - verso 1
Cenrio informal
O caso de uso comea quando o cliente seleciona "fazer pedido". O cliente fornece seu nome e
endereo. Se o cliente fornece apenas o CEP, o sistema coloca automaticamente a cidade e o estado. O
cliente fornece os cdigos do produto. O sistema devolve as descries e o preo de cada produto. O
sistema calcular os valores totais para cada produto fornecido. O cliente fornece as informaes sobre
carto de crdito. Em seguida, ele submete os dados ao sistema. O sistema verifica as informaes
fornecidas, marca o pedido como "pendente" e envia as informaes de pagamento para o sistema de
contabilidade e pagamento. Quando o pagamento confirmado, o pedido marcado como
"confirmado" e o nmero de pedido (NP) dado ao cliente.
Desenhe o caso de uso
Cenrio: Jos resolveu desenvolver uma aplicao para controlar as ligaes telefnicas de sua
casa, a fim de checar se o valor que paga mensalmente est correto. Assim, sempre que desejar
poder listar as ligaes efetuadas num determinado perodo, contabilizando o valor a pagar.
Para que isso seja possvel, toda ligao ser feita pelo computador. A cada solicitao de
ligao, a aplicao dever registrar: a data da ligao, a hora da ligao, quantidade de minutos
gastos (que deve ser registrado no momento que a ligao for encerrada), o nmero de pulsos (que
deve ser calculado pela aplicao) e o telefone para onde se discou.
A aplicao permitir o controle de uma agenda de telefones, com nmero do telefone e nome
da pessoa de contato. O usurio poder escolher no momento da ligao, se deseja um dos registros
da agenda ou se digitar diretamente o nmero do telefone.
A forma de clculo dos pulsos considera os seguintes critrios:
- A ligao ao ser completada j conta um pulso. A partir da, a cada quatro minutos de
conversao concluda, cobra-se mais um pulso.
- Cada pulso custa R$ 0,08 para ligaes locais.
Exemplo:
Ligao de 2 minutos - 1 pulso
Ligao de 4m30s - 2 pulsos
Ligao de 8 minutos - 3 pulsos
- Os finais de semana possuem uma promoo. Cada ligao contabiliza somente um pulso,
independente do nmero de minutos de conversao.
Desenhe o diagrama de casos de uso
Carlos aposta toda semana na Loteria, em jogos como quina, megasena, fotomania, etc. So
vrios cartes por semana. Na hora de conferir uma loucura. Certa vez, quase que ele confere o
carto errado.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 43
Para resolver isso, ele quer desenvolver uma aplicao que cadastre os cartes apostados e o
resultado de um concurso, apresentando o relatrio final com os nmeros acertados por carto e o
valor do prmio, se houver.
Exerccio (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 so registrados no sistema, no qual
tambm esto registrados os livros e as revistas.
A biblioteca controla a compra de novos ttulos. De ttulos populares compra-se vrias cpias.
Livros antigos e revistas so removidos quando esto ultrapassados ou deteriorados.
Bibliotecrio um funcionrio da biblioteca que interage com os clientes e seu trabalho
auxiliado pelo sistema.
Um cliente pode reservar um livro ou revista que no est disponvel 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 atravs de um processo exclusivo de
cancelamento.
A biblioteca pode facilmente criar, atualizar, e apagar informaes sobre seus ttulos, clientes,
emprstimos, e reservas no sistema.
O sistema pode rodar em todos os ambientes populares (UNIX, Linux, windows, etc) e tem uma
interface grfica (GUI) moderna.
O sistema deve ser facilmente estendido com novas funcionalidades
O sistema deve lidar com a mensagem que enviada ao cliente quando um ttulo reservado
torna-se disponvel, e precisa checar se um determinado ttulo est ultrapassado ou deteriorado.
Exerccio (Coca-Cola) Identifique os atores e elabore o diagrama de casos de uso para um sistema de controle de uma
mquina que vende Coca-Cola, descrito a seguir:
um sistema de venda de Coca-cola em mquina 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 Tcnico, bem como o recolhimento do dinheiro da
mquina.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 44
Esta pgina foi deixada propositadamente em branco.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 45
3. Diagrama de Classes
Diagrama de Classes
Introduo
O diagrama de classes demonstra a estrutura esttica das classes de um sistema onde estas
representam as "coisas" que so gerenciadas pela aplicao modelada. Classes podem se relacionar
com outras atravs de diversas maneiras: associao (conectadas entre si), dependncia (uma classe
depende ou usa outra classe), especializao (uma classe uma especializao de outra classe), ou em
pacotes (classes agrupadas por caractersticas similares).
Todos estes relacionamentos so mostrados no diagrama de classes juntamente com as suas
estruturas internas, que so os atributos e operaes. O diagrama de classes considerado esttico j
que a estrutura descrita sempre vlida em qualquer ponto do ciclo de vida do sistema.
Um sistema normalmente possui alguns diagramas de classes, j que no so todas as classes
que esto inseridas em um nico diagrama e uma certa classes pode participar de vrios diagramas de
classes.
Escopo ou Visibilidade
+, -, # (protected), ~ (friend/pacote). Visibilidade do elemento.
Em UML as classes so representadas por um retngulo dividido em trs compartimentos: o
compartimento de nome, que conter apenas o nome da classe modelada, o de atributos, que possuir
a relao de atributos que a classe possui em sua estrutura interna, e o compartimento de operaes,
que sero o mtodos de manipulao de dados e de comunicao de uma classe com outras do
sistema. A sintaxe usada em cada um destes compartimentos independente de qualquer linguagem
de programao, embora pode ser usadas outras sintaxes como a do C++, Java, e etc.
Figura 3.1: diagrama de classes.
-
FAETEC 2012 - Notas de Aula de MD3 Prof. M. Frana Pgina: 46
Pacotes
Pacote um mecanismo de agrupamento, onde
todos os modelos de elementos podem ser agrupados.
Em UML, um pacote definido como: "Um mecanismo
de propsito geral para organizar elementos
semanticamente relacionados em grupos." Todos os
modelos de elementos que so ligados ou
referenciados por um pacote so chamados de
"Contedo do pacote". Um pacote possui vrios
modelos de elementos, e isto significa que estes no
podem ser includos em outros pacotes.
Pacotes podem importar modelos de elementos
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 no possuam semnticas