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

[email protected]

http://www.franca.pro.br/prof


Esta pgina foi deixada propositadamente em branco.


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!


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


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.


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.


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.


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.


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.


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


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


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,


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


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.


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


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


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


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.


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


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.


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.


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)


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).


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


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.


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.


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.


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 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.


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.


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 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.


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)


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


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.


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.


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


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.


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.


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.


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.


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.


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

ap_md3_2012_faetec

Documents